Skip to main content

How much do you let a new team self organize?

I have a team of 11 developers and 3 Product Owners. Their ideas about how to organize the team are all over the place. Some want to do 1 week sprints. Others want one month sprints. And we pull in resources people so we can get the right velocity to meet our deadlines. This seems like a mess. How much should I let my beginning team self-organize? -- recently asked on a Scrum Discussion Forum.    
Modifying a complex technique before you have mastered it is a failure pattern. So when you are just getting started, try to get as close to Scrum by the book as you can, without obsessing over it... much. I call this Pretty Good Scrum(tm). ;-)

Yes the team self-organizes... and the Scrum Master is charged with teaching the team and helping them improve. When the team is just getting started, it should follow the lead the of Scrum Master, and the Scrum Master should stay close to the book. As they get better, they'll be better able to inspect and adapt themselves.

Successful teams learn quickly. How do you learn quickly? Short answer: Do short sprints. More in a moment.

Remember, never hit anyone with the book! The rules of Scrum are there to help you, not to threaten or punish people. Be sure you can answer why the rule of Scrum is a good answer. Treat everything as an experiment or learning exercise, so they have the security of knowing they can change things later. That's what retrospectives are for.

It will probably take you three or four sprints to get to Pretty Good Scrum. That's why I recommend one week sprints to start. Why learn in four months what you can learn in 4 weeks?

If I were confronted with the situation above, I would ask five questions and help the team(s) and PO(s) find answers that stay within the constraints defined by Scrum.

1. How big is a Scrum team? 7+/-2. To stay in those bounds, you need two teams. Ask your teams how they want divide themselves, respecting that constraint. By giving them the problem, they become responsible for the solution, so they won't come to you anymore with "yes, but..."! If they talk about limited specialists, ask them how to resolve the problem.

2. How many Product Owners does a Scrum Team have? One, though you might also have a Chief Product Owner role in the case of multiple teams. Ask your product owners how they want to split up their work. And yes, the PO is responsible for the Vision. Do they have one, can they communicate it? Is it shared and supported by the Team and other stakeholders?

3. How long is the Sprint? Normally this is negotiated between PO and Team. And... as Scrum Master you are responsible for the process, which gives you the right to intervene to improve the team. Shorter sprints accelerate learning. So I would suggest starting with a couple of one week sprints. Be sure to get your team to agree to this. I have also had great experiences doing 2 or 3 sprints at 59 minutes each (ask me more about this if you're interested).

4. Who estimates and decides how much work can be accomplished in a sprint? The team. Not the math, not the PO, not the stakeholders and not management. Have them estimate the work, and don't let them take on more than they can chew. Think of highways at rush hour if you want to know why this is a good idea.

5. Whose job is it to make sure that wish and reality are in harmony with each other? The Product Owner. If the desired scope does not match up with the team's reasonable forecast of what they can accomplish by the desired release date (aka deadline), whose job is it to fix the problem? The PO. Given your context, conversations about reducing scope and the impact of product-level multitasking on ROI might be quite fruitful!

Back to the original question: "How much do you let a new team self organize?" The answer is "quite a lot!" The trick is setting constraints that cause people to come up with right answers.


IanJ said…
I'll bite :-)

Tell me more about 59 minute sprints. Is that including the relevant pro-rata'd meetings ?

I guess this is not dissimilar to the sprint duration of a CSM course, but they are 2 hour long ?

Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Money for Nothing, Changes for Free

“Money for Nothing, Changes for Free” encourages both customers and suppliers to focus on value.

A key advantage of Scrum projects is that at least once per sprint you have something that could be shipped and no work in progress. You can change direction every sprint, and you can reevaluate whether the project is a good investment or if your money could be better spent elsewhere. Abrupt cancellation is risky for the supplier.

While the concept of an early-exit penalty is not new, Jeff Sutherland gave it a unique allure with his allusion to the Dire Straits hit.
Desired Benefit Incentivize both customers and suppliers to focus on functionality that provides genuine value.
Structure This works with Agile software projects because there is little or no work in progress. After each Sprint, functionality is either complete or not started. Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budge…