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

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…

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…

10 Warning Signs, that your team is not self-organizing

How do you know that self-organization is working? The Bern Chapter of Scrum Breakfast Club looked into this questions, and identified the following warning signs (which I have taken the liberty of translating).

The team reports to the Scrum Master at the Daily ScrumPeople wait for instructions from the Scrum MasterTeam members don't hold each other responsible [for their commitments]The same impediment comes up twice"That's the way it is" => resignation"I" instead of "We"Flip charts are lonelyCulture of conflict-avoidanceDecisions processes are unclear, nor are they discussedPersonal goals are more important than team goals
To this list I would add my a couple of my favorites:
you don't see a triangle on the task board (not working according prioritization of stories)after the daily Scrum, people return directly to their desks (no collaboration)there are a least as many stories in progress as team members (no pairing)
P.S. You can join the …