The development teams can't deliver successful sprints

Question

We have 2 (50% distributed) scrum teams, that have been doing scrum for just over a year. Since almost the whole time, the teams' painful point is environments instability, from all perspectives: smoke tests failing and need to be looked at, things break and need to invest time into fixing them, things are deployed from other teams (we work in a global project) that broke our code and so on. All these are not the teams' problems, though they intermittently impede our teams. Otherwise, the teams state that are very happy and constantly improve.

So, despite our velocity been estimated correctly (say 50), and if everything goes well we can deliver that, we are often called to fix our environments, do investigation, do root cause analysis etc. Therefore we end up not delivering successful sprints. We cannot gauge this downtime since sometimes takes up 1 person - 1 hour, sometimes 4 persons - 2 days to investigate and fix. This is completely random.

This problem keeps being raised in retrospectives, the management is aware, and the response is that "we are aware of these and agreement has been made to improve on such and such...", and that "we are moving towards improving the whole process by doing X,Y,Z". In discussions between the scrum master and the development manager, the development manager almost refuses that these problems are the reason why the team is not delivering successful sprints, and that given good coordination, the team should still be delivering anything that they committed to. Committing to less might mean that the team is delivering everything and runs out of things to do in the sprint, whereas over-committing might end up not delivering everything. Also, under-committing has been proved to raise the manager's eyebrow as "the team must always have things to do", and "under-committing" is not the solution.

What do you think are possibles fixes to this process so that the team can effectively commit and deliver within this environment?

Answer 1

"the team must always have things to do"

This, I think, is the crux of your problem. Look into (and have your Development Manager look into) the 100% Utilization Fallacy.

What would solve your problem is integrating slack time into your estimates. You under-commit, with the now-extra time being made into slack time. Whenever things go smoothly, the slack time is used for non-scheduled, side-tasks. Researching. Spikes. Cleaning Technical Debt. Writing that documentation everyone keeps forgetting about. Any number of things.

And when things don't go smoothly and you have these "environments instability" problems crop up, you spend your slack time fixing them. No slack (or less slack) that sprint, but you still get done what you actually committed to.

Answer 2

Pull the Andon chord. Stop the line and fix the issues. Don't fix the symptoms, but the root causes of the unpredictability. 5 why your way down into the actual cause(s) of the interrupt work and fix it. Make it the goal for your upcoming iteration. Your team will know what needs done to fix the problems and I guarantee they'd be happy to do the work if it saves them some future pain.

No, you won't deliver any new features, but it is a worthwhile investment.

There is always going to be unpredictable interrupt work. The trick is to ruthlessly minimize it. Be sure to take good measurements of before & after to make sure you've actually solved the problem.

Answer 3

We cannot gauge this downtime since sometimes takes up 1 person - 1 hour, sometimes 4 persons - 2 days to investigate and fix. This is completely random.

Have you tracked it and/or can you reconstruct it over the past 6 mo or so? If you aren't already tracking it, start now.

As a PM, you know that this is a risk. Your team knows that it is a risk. So plan for the risk. Assign points to it. You can't predict it because it is random, but look back over what it has been and pick a median value.

This isn't the same as undercommitting. It is mitigating a known risk: you're allocating points against the likelihood that some of the sprint effort will have to be spent on this recurring problem.

If you think it will make your management feel better, you can also identify an equal number of points worth of features that are designated to be worked last if nothing goes wrong. I wouldn't do that the first time, tho; I'd only do it if I was pushed.

In response to pressure on undercommitting, I would resist this with a broken record "It's not undercommitting; it's risk mitigation. Look at the data. This is a known risk, so we are planning for it."

The other thing this does for you is to put on your management's radar, every time, "We can't assume that everything will work because it too frequently doesn't. We are mitigating this known risk (that you have repeatedly said would be dealt with. See how much more work we would be able to get done if you would actually fix it?)."

Answer 4

Have your team commit to less work, but have a number of items at the top of the backlog ready to be brought in to the sprint if all goes well.

That way you set up the behaviour of consistently meeting your sprint goal and often exceeding expectations.

Answer 5

Similar to other answers, I suggest the team commit to fewer points. The different approach I'd suggest would be to include technical debt issues within the sprint.

• If there are any external defects, etc, you will have your slack.

• If all goes well, and there is no overhead, then the team can resolve technical debt issues which will help a lot in future sprints.

The trick here is; issues don't have points assigned to them, so if the team is not able to complete them by the end of the sprint, there won't be any change in velocity.

As long as resolved technical debt stories improve overall workload for the team, they will be pretty motivated to complete them.

Answer 6

When I was in this position, I quit... unfortunately when the problems are outside the team, all that happens is the team complains to the scrum master, the scrum master complains to the manager, and nothing changes. When higher ups don't want to improve the system as a whole, it is outside of a single teams control.

While building slack into the system as others suggested will at least the team can "succeed" at sprints, it won't help reduce their frustrations at the crappy working environment.

Anecdotally, the product that I left that was having this issue reduced their dev team from approximately 80 to a single scrum team of 8 to survive. It wouldn't have surprised me if that single team output more than the previous 10 teams did - it was that bad!

Answer 7

The situation here is an indication of lack of trust. Yes, the sprints should be delivered but the management has to ensure that the team is not distracted which is usually Scrum master's responsibility.

I often feel that agile is pretty much a buzzword. A lot of people say they are agile but in reality they ignore core values of agile.

This situation could have also arisen because of lack risk management plan. Regardless how Agile your organization is, procurement needs to be considered and proper plans in place. Clearly the risks were not identified early and the scrum team is being often distracted. Development is where rubber meets the road, your management should identify risks and actively monitor & control risks with workarounds without affecting the development. If it is crucial then this needs to be considered in sprint.

Answer 8

Since Development Manager is refusing to acknowledge that integration might be the problem and yet, you're working in Scrum, perhaps it's time to introduce him/her to Nexus?

Nexus from Scrum.org

It's framework built on top of Scrum to scale it and it's by far scaling framework that focuses mostly on dependencies and integration. Framework can help you holding your ground and defending that this is unavoidable and necessary investment. It might also uncover some additional underlying issues with dependencies (late integration, poor requirements and architecture, etc.).

Immediate next steps in your case

Get familiar with Nexus, discuss it with your Dev Manager. Having industry experts behind you and your opinion that integration is painful should help you. I wouldn't be surprised if discussion would be enough to acknowledge problem.

When/If you'll establish Nexus with it's Nexus Integration Team you'll have true bandwidth and focus on working through your environment stability and resolving dependencies. It will also become evident that you won't get environment stability and integration issues resolved for free.