Why the ScrumMuster should sit right next to his team

A ScrumMaster should sit next to her/his team. That’s the suggestion of literature, practicioners and wisdom of the crowd. But in reality most ScrumMasters I know serve two teams.  At least in enterprise-size companies, where the number of teams is big enough. Furthermore they are often busy with organization-wide agility and collaboration stuff. This seems to be the favored setup in many big companies.

But this is just a compromise – and not even a good one. Assume that we have teams that didn’t already reache the state of hyper-productive, high performant, self reflective Agile-evangelistic developers.

So – what does a busy ScrumMaster miss, if s/he can’t look at only one team?

  • Developers try to solve problems on their own for a long time, trapped by their ego, instead of asking for help.
  • People don’t ask the experienced guys for help.
  • Discussions between team members are unproductive.
  • Impediments will be accepted as they are instead of solving them.
  • Questions will not be clarified together with the PO.

There may be more such things – common for all: they hinder optimum performance. And the question emerges: “Why does this take so long in this team? Is this normal?” Maybe it isn’t (depends on what is normal). But surely there is room for improvement. If the chances are recognized.

So the advice “one team per ScrumMaster” has its clear right to exist. If this is not possible the challenge is to organize your work as ScrumMaster to achieve best possible results. Maybe you are able to sit one sprint next to one of your teams and the next sprint next to the other. And maybe you can manage it to stay with your team at least a complete day per sprint to observe how the work together. But don’t miss the chance to get deeper insight into their work.

Tracking Impact of Unplanned Work

In an ideal world a development team would spend 100% of its time working on planned stories during a sprint. In reality this may rarely be the case. Most teams are interrupted by some unplanned work during a sprint. May it be a critical life bug, a urgent research or some production issues. An interesting question is how to measure the impact of this unplanned work. How does it affect the team’s velocity? How much more could be done without these interruptions?

Tonio Lucca created a nice prezi on that, with some impressive math foo, wich I may warmly recommend:

Tracking unplanned items in Scrum Sprints on Prezi

How To Deal With Maintenance Work

How do you deal with maintenance work, additional to product development, in an iteration-based environment?

Here are some possible approaches:

1. A certain, fixed, amount of time per iteration will be reserved for maintenance work, let’s say 10%.

Pro: At a first glance it looks reasonable – and above all “easy to schedule” from a classic management perspective.

Contra: At a second glance this approach leads to the need for task switching during a sprint. And as we know multitasking has a remarkably negative impact on productivity. This problem potentiates if you got a “maintenance batch” that is too large to fit into the 10% budget. So you would need to discontinue the maintenance work until the next sprint – or you simply may get into trouble delivering the promised product increment.

2. A variable maintenance time budget, negotiated for every sprint.

Pro: You earn higher flexibility to deal with variable complexity of maintenance work what should lead to higher predictability for your product development.

Contra: You still run into task switching issues and the maintenance work may affect your product development work.

3. Doing pure maintenance iterations.

Pro: You clearly separate maintenance work from new product development. People can focus on one theme at a time.

Contra: What if urgent maintenance has to be done during a product development sprint?

4. Have a maintenance team for a longer period of time. Rotate it afterwards to spread knowledge and avoid potential demotivation with the maintenance guys.

Pro: No task switching, no product development interference (you may be able to negotiate the time for the team rotation).

Contra: Need for all necessary domain and technical knowledge in the maintenance team. But this should build up if you use the approach for longer.

 

But a more fundamental question should be: what exactly is maintenance work for you? Bugfixes? Improvements? Because from the answer new aspects may open up – e.g. to think about a “zero defects” strategy or your application lifecycle management.