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

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