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:

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.

Book Review: Management 3.0 by Jurgen Appelo


There are really a lot of books in the orbit of Agile project management out there. And various sources state similar – or completely opposed – views on how to “manage” Agile after all. I read a lot of them. Then I grabbed “Management 3.0″ by Jurgen Appelo.

It rocks!

Why?

Because it made me think lot. And it helped me to understand observations in my work environment. And I found verification for ideas and approaches I’m following. So it’s finally a good mixture I think.

Moreover it is the most complete collection of scientific background information connecting (Agile) software development and complexity theory. You wonder why change feels so hard? Here you are! Lack of motivation? Got an idea! What about these useless managers? Well – they are more usefull than you ever thought! Why start thumb blondes suddenly selling self-written books with great success? Can tell you! Your book backlog runs out of items? Just turn to the end of the book!

Aside nobody can impute a lack of humor on Jurgen. Want a sample?

“I’ve seen ‘Agile’ tools that were less agile than Kim Jong-il stuck in a glacier.”

So what does this mean in sum? The book gets my unlimited reading recommendation. But assure that the right people read it, though. Remember: it’s called “Management 3.0″.

The best evidence I’m not wrong may be the foreword by Uncle Bob (Martin):

“I hate management books. [...] They sit on my shelves. I sometimes read them in the John.”

But anyhow he wrote a foreword for this one. Find out why – just start reading! And once again: be sure the right people get hold of it :)