5

For some time now our Scrum teams have experienced recurring impediments caused by external factors to the team. The teams have discussed the impediments in their retrospectives and also brought it up on "Scrum of Scrums". It seems that the impediments may require involvement by management as it requires some rather significant changes in that way we do things and the way our technical environments have been configured. In a small setting these kind of issues would probably have been easy to deal with because the team would have more control, but in this setting there are multiple teams, stakeholders and parties. I’d like to hear your experience in making waste and costs visible. Do you simply estimate the hours wasted on the recurring impediments (such as, “we waste 10 hours every sprint waiting on the build server) or do you have a more systematic way of gathering and showing the waste?

I would like to collect waste based on Six Sigma (and Lean Software Development) and estimate the waste cost in terms of story points. E.g. at every retrospective highlight the waste in seven categories with the number of story points wasted in each category. The seven categories would be: Partially Done work, Extra Features, Relearning, Handoffs, Task Switching, Delays, and Defects.

In the end of the Retrospective, there would then be a clear indication of the cost of external impediments that management would easily be able to act on. What do you think?

Allan Lykke Christensen
  • 151
  • 5
  • IME 'estimating' is PITA at all ends. I'd add new opportunities for this frustration engine only if had realistic gain as balance. Isn't just learning from mistakes and trying to be better enough without struggling to quantify waste? Aren't vague figures 'big' and 'small' enough for practice of prioritizing? – Balog Pal Jun 02 '13 at 16:13
  • If the impediments were within the teams control I would totally agree with you. The problem in my case is that the impediments are external factors that the teams have very little influence over. For example, if the teams use a build server managed by another department or external service provided and the server yields sporadic errors. Replacing the server may be a project in it self and would require management support. Quantifying the waste would make it faster to act upon. – Allan Lykke Christensen Jun 02 '13 at 18:17
  • 1
    Ah, that is really somewhat different. Though this even less asks for estimating, but actual bookkeeping of the lost time just as it happens. If you book time/effort already, create an 'External risks' item and make everyone book there. If the isn't you can make a rule of 'bookkeep or shut up', IOW whoever failed to make the note immediately loses grumbling rights. Then you just sum evidence. Rather than try to recover it. – Balog Pal Jun 02 '13 at 18:31
  • Don't forget to count the costs of the bookkeeping required for this exercise in the "impediments" column. – Blrfl Jun 03 '13 at 10:47
  • @Blrfl You've got a good point. It's important that the bookkeeping doesn't become an impediment by itself. It's important that tracking the cost is uncomplicated. – Allan Lykke Christensen Jun 04 '13 at 17:36

1 Answers1

1

Perhaps you'd get more buy-in from management if you completely turned your problem around and presented it like this; "If we fix this problem, what can we gain?". Approach the problem from the positive side, and in my experience you'll get a better response all round. So, rather than highlighting problems (which we can all do until we're blue in the face), point out solutions, and benefits to change.

You could make a list of the things your team sees as impediments, and make yourselves a separate 'improvements' backlog. Estimate each item as you would any other user story. Then in your planning meeting with your stakeholders, you can present your varous proposals with a clear cost-benefit to them.

"So Gary, if we include this 'fix the build server' story in this weeks sprint, which we have estimated as having 6 points, we think that in the future, we will be able to improve velocity by around 4 points per sprint."

A couple of extra notes on this approach;

1) these stories are effectively crud that need to happen (I've completely forgotten the 'scrummy' term for this); and the story points shouldn't contribute to your sprint velocity, as they are a cost, and do not in themselves progress the real project

2) if you succeed with a small impediment story first, you might get more buy in for the bigger items on your impediments list

RJ Lohan
  • 465
  • 3
  • 8
  • Thanks! I agree with the positive presentation of the problem and will certainly use that. Our major hurdle is that the teams have very little influence on the impediments as they are closely tied to monetary and strategic investments. Management is certainly willing to change course, but first we need to figure out how much to gain from course correcting. – Allan Lykke Christensen Jun 04 '13 at 17:41