As I commented in the post, I believe this is a key point to having a committed team that is ready to do whatever it takes to improve things.

Not only does the team have a strong feeling of being responsible (they are!) for the way things are done in the team (i.e. if we don’t do it, nobody is going to) – but having the problem defined by the whole team and the solution agreed by the whole team increases highly the chances of successfully solving the original problem.

A basic, which I thought was important to stress again…

1. Agile and Iterative Development: A Manager’s Guide: This one gives you a high level overview of everything agile, including Scrum. Good to get a first basic understanding of agile principles and methodologies / practices around town.

2. Agile Project Management with Scrum: This is the reference book on Scrum written by Ken Schwaber. A must read for anyone who has already a pretty good idea of agile principles and is considering Scrum.

3. For the German speaking audience, Boris Gloger’s book “Scrum: Produkte schnell und zuverlässig entwickeln” provides excellent materials. For the record: I was lucky to have Boris as my trainer for my CSM training.

What would you recommend for someone willing to know more about agile software development?

Since UX is actually a core element of a product, how does it all fit with your definition of done? Do you usually wait to have all UX items delivered before starting the project? Is the designer also delivering incrementally? Either way, how does the development team cope with this?

In short, how do you do it and why?

Update: The discussion has started in the LinkedIn Scrum Practitioners group.

PMBOK = set of guidelines | Scrum = values + tools

First and foremost, the main misconception from those who don’t know about PMBOK, is that it is a methodology that should be strictly followed and involving never-ending documentation. It’s not. PMBOK is a set of guidelines, that have been identified as being critical for successful projects delivery. It is up to the project manager, together with the stakeholders, to define what processes should be used and to which degree.

Scrum on the other side, is a combination of a values and tools based on the Agile Manifesto aiming at delivering (mostly but not only) software projects. Scrum values and artifacts are clearly defined and not following them means you’re not doing Scrum.

How does Scrum fit in the PMBOK (or not)?

1. All the values and artifacts present in Scrum fit in the PMBOK Knowledge Areas (Integration, Scope, Time, Cost, Quality, Risk, Procurement, Human Resources, Communication): Sprint planning, Sprint review, Product Backlog, estimations, team building, PDCA wheel (continuous improvement), doing the risky stuff first, defining ‘done’, close customer relationships, measuring success, daily Scrum, iterative planning – it all fits in the PMBOK Knowledge Areas, only with a different vocabulary. Again, it’s up to the project manager, together with the stakeholders, to define how all these areas should play together.

2. Both are embracing change: Scrum embraces change by allowing features to come in and out of the Backlog. PMBOK has a slightly different approach: simply put, any change  request should be documented, reviewed by a defined set of people, added to the WBS if accepted and updating the various baselines (scope, cost, quality). Actually let me rephrase my point with Scrum: the Product Owner is responsible with what comes and goes in and out of the Product Backlog. Yes, that’s right, again Scrum fits in the PMBOK when it comes to change management.

3. Project values drive how the project will be managed: Scrum wouldn’t be what it is without the underlying values of the Agile Manifesto. When projects start with Scrum as basis, the direction is clear as to how the team should work together. When PMBOK is used as basis for projects, there is no pre-defined set of values to guide the team: it’s up to the project manager, together with other stakeholders, to define the project values and use the tools or define the processes that will be aligned with the projects values the various stakeholders committed to.

It’s all about people

This post is in no way exhaustive, however it illustrated how I see Scrum fit within the PMBOK. As a final word, I would say (actually repeat) that project are successful because of the people that make them. The project manager needs to understand this in order to define the project values, together with the team, that will drive how the project will be executed.

Looking forward to your comment and feedback!

Apart from a different scale, is it much different than to adopt Scrum in a small sized company? I tend to think the same organizational and systemic dynamics come into play: company culture, senior management support, communication channels, work environment etc.

Is it the scale of everything and how deep the company culture is rooted that might make things a lot tougher?

What do you think? Can Scrum survive in the world of fixed scope and date, top-down management, lengthy weekly email reports with hundreds of recipients in CC, big bang releases with multi-million € Marketing campaigns?

I would love to read your comments on that one!

Update: Point 1 from this comment pretty much nails my thoughts on Agile in the Enterprise. It can’t work if the leaders don’t change.

No related posts.

Problem description

Since I joined the team, I have always found our Daily Scrum meetings a little, well, boring. I have tried shaking things up a little but without success so far. However recently I had the feeling people come to the room because they must and not because they want to, entering the room as if they were going to be beaten up to death. As a result the actual communication is of no value whatsoever to anyone. That annoys the heck out of me and I don’t seem to know what I could do…

Work environment analysis

Here is a sumary of the team’s work environment, this should give some clues already on the root cause.

* We have several projects running at the same time – team members are usually split between these projects.
* Some team members are not fully dedicated to the team (they are shared with other teams).
* The backlog is managed virtually, same with the various Burndowns.
* Lack of meeting rooms generally make it hard to split things up.
* Lots of pressure and high priority work going on: we can’t take the time to talk about things!

Generally I think some guys don’t want to go into details because they either dont want to hold off others or actually think that others don’t care about what they are doing because they are focusing on other things. 14 people…

All that ain’t fun!

What can I do, as a Scrum Master, to sort things out?

I have to be creative to sort these problems while staying within the framework provided by the company. Here is a list of things, in no particular order, which come to my mind as I write this piece:

* Organize the Daily Scrum in projects: start with project A, the with project B etc. The expected result is more coherence in the communication flow instead of jumping from one project to the other.
* Do 1 Scrum per project instead of 1 big mammoth Scrum – split the team into smaller groups while keeping the lead developer in all these.
* Have a physical product backlog and burndowns in the project room in addition to the virtual one (thanks Dan).
* Change the time and location of the Daily Scrum meeting.
* Do one session to remind everyone of the purpose of these daily meetings.
* Work closer with management and stress again the importance of not working on several projects simultaneously.

That’s all that comes to my mind for now… Next step is do a thorough cost/benefit analysis and work together with the team to find a solution that everybody is committed to.

What would you do to break the routine in Daily Scrum meetings and make things fun for everybody? Have you ever experienced a similar scenario?

This time, I guess you got that, we talked about the data teams’ Sprint Burndowns should be based on. Should teams have their Sprint Burndown based on Story Points or on the sum of all remaining estimated tasks in hours?

To answer this question, it’s important to understand what the goal/role of a Sprint Burndown is. The Sprint Burndown is a tool that:

* shows the team’s progress of a running Sprint
* indicates the team’s performance during the Sprint
* should show whether a team is on a good way to meet its commitment or not
* shows where blocks in the development process may happen 

Let’s do a small comparison of 2 approaches…

1. Sprint burndown based on story points

* doesn’t require the team to estimate tasks
* might be considered as less overhead by the team
* may not explicitely show bottlenecks in the development process
* may have the tendency to create burndowns like this

2. Sprint burndown based on time

* requires initial tasks to be created and estimated at Sprint start
* may put negative pressure on the team by introducing another level of estimations (and measuring against these estimates)
* may be considered as too much overhead by the team
* may show bottlenecks/blocks more explicitely than with Story Points
* will have the tendency to create burndowns like this

In summary, the purpose alone of the Burndown should already give a good idea in which direction to go. The team/company’s culture and how deep you are in your implementation of Scrum may be 2 other aspects to take into account when making that decision.

Now Jeff Sutherland recently wrote “The best teams I work with burn down story points. They only burn down when a story is done.” (Source) - Are you there yet?

“For user story X, the team correctly identified that the work was at the database level. But when doing the actual estimation, they stepped back and left the expert database developer do the estimate. When the DB developer spoke out, I got some signals from the rest of the team that the estimation might have been inflated – still none of them said anything.”

I see 2 problems here:

1. Why isn’t the entire team estimating the user story *together*, even though it only involves DB work?
2. Why is the DB developer inflating the estimation?

In my experience, developers – as basic example – are not willing to estimate anything that isn’t related to their code, is a common pattern in teams starting Scrum. “How can I provide an accurate estimate in a field I am no expert in?” How have I solved it? Usually I try to insist on the fact that there are no *right* estimates and that the goal of all this is to generate a discussion that will help everyone to have a better idea of what the deliverables of a user story are. Estimates are not written in stone!

Inflating estimates is a little trickier… In this case, I know that the DB developer is actually part of another team which means he may already be overloaded with work from this other team. Inflating to avoid the burnout? Why not… How would I solve this? First thing that comes to my mind is to try to hire, which may not be solving the root cause. If that is not possible, I would suggest the team to inform themselves on the subject matter to become less dependent. Writing SQL queries is surely no rocket science when you can do .NET!

Questions to other Scrum or Agile practitioners: Did you encounter similar scenarios and how did you handle them? If not, how would you handle them if you did? Share your experience with us!

In our attempt to adopt Scrum in our organization, we found out that it was very challenging for us to maintain a unique Product Backlog. Not only are we working on a couple of projects simultaneously, but we are also responsible for maintaining the application. Imagine the headache for our Product Owner to prioritize a single Product Backlog containing all stories for all of our projects, bugs and smaller feature requests!

It’s only after several Sprints (and a flash of common sense) that we managed to solve this by having a Product Backlog for each running project. A picture is a worth a thousand words – so here is how things look like:

As you see, each project (A, B and C) has its own backlog. What does this mean concretely?

1. Each project has its own burndown and velocity.
2. The Product Owner can decide in the Sprint Planning on which project the accent should be put in the next Sprint, depending on changing priorities (Project A, Project B, urgent bug fixes on production sites etc.).
3. We go through each of the projects in order of priority during the Sprint Review.

There are definitely risks related to working on several projects during a Sprint: no common goal for the team, spreading resources puts projects in danger, breaking team cohesion etc. Being aware of these risks is important so you can act accordingly. I must say that so far, it has worked really well for us.