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?

  • Sadly, this is all too often a reality. Managers, directors, chiefs, etc. do not truly embrace the agile philosophy nor understand Scrum. Within the Scrum framework, "The Development Team works to forecast the functionality that will be developed during the Sprint."1 Forecast not commit. The cause has been identified and things are not improving. Continue to attempt to educate the management, and so called leadership, until improvements are reality or it is clear that nothing will change and it is time to part ways. Best wishes. Apr 20, 2017 at 0:26

8 Answers 8


"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.

  • Albeit I know slack time is truth, it doesn't sell well to senior management :)
    – dqm
    Mar 6, 2017 at 15:58
  • 2
    Find a way to sell it to mgmt @dqm. You seem to be searching for some magical answer to the problem. Magic doesn't exist.
    – RubberDuck
    Mar 6, 2017 at 22:37
  • I see you @RubberDuck and I raise you a "I'm not there to sell scrum, I'm there because they want to implement scrum". If management resists, I'm not there to force it down their necks, right?
    – dqm
    Mar 7, 2017 at 14:51
  • 2
    @dqm No, but it does give you an answer for when you are asked "Why was this not done?" At which point they will likely question you, and you'll find yourself selling anyway. Have them pull the sell out of you, don't push it into them.
    – Sarov
    Mar 7, 2017 at 18:33
  • @DQM this may sound harsh but developers are paid to manage the code pipeline. You are paid to manage the relationship and managerial pipeline. So manage it and manage your stakeholders. Apr 25, 2017 at 14:22

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.

  • Thanks for your reply, I'm with you on that. However, I am talking about an organization of 20k employees, whereas environments setup and process setup is out of our control. We are EU based, and these "decisions" are taken on a C or SVP level in headquarters in US. We just adopt what's been decided. Therefore, if no decision is made to increase quality and stability, it won't happen and there's nothing we can do but keep highlighting it.
    – dqm
    Mar 6, 2017 at 11:29
  • 2
    In most organizations, the Andon Cord is attached to a resignation letter.
    – MCW
    Mar 6, 2017 at 12:18
  • I call BS. It should not be very difficult to make the case for making your development teams more efficient.
    – RubberDuck
    Mar 6, 2017 at 12:20
  • A more productive response: Make the interrupts as big and visible as possible. Show the powers at be how much more efficient and reliable you could be if the teams were allowed to fix these root causes. Show them the numbers; make your business case.
    – RubberDuck
    Mar 6, 2017 at 12:23
  • The senior management is fully aware of these, and these are the issues that "we already know about", and the proposed workaround is to "commit less because we know that things always pop up". We can't just fix the root cause, because it's a huge software and defective in many ways. Therefore, 50% of the times an error comes because of bad development that we need to trace and fix.
    – dqm
    Mar 6, 2017 at 14:32

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?)."

  • Management is aware that there are issues and they are indeed tracked for the lat 6 months. I think the key is to under-commit and explain as you correctly said, we "mitigate risk".
    – dqm
    Mar 8, 2017 at 14:55
  • Just a note that some schools of thought say you shouldn't assign points to these things because points represent (in a very ambiguous, indirect way) value delivered. +1
    – RubberDuck
    Mar 8, 2017 at 17:10

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.

  • I'd say it'd be better for OP's team to spend any slack time paying off technical debt rather than pull in extra feature work.
    – RubberDuck
    Mar 6, 2017 at 10:13
  • The caveat to this is that developers might commit to delivering less work and then sit back and relax as per Parkinson's law (en.wikipedia.org/wiki/Parkinson's_law). I know though this gives rise to other questions such as "do you trust your team?".
    – dqm
    Mar 6, 2017 at 11:33

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.


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!


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.


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.

  • 1
    Hi Piotr, I noticed you suggested the 'Nexus' tag, but the OP doesn't mention they're using this methodology - feel free to ask the OP in a comment to confirm whether that's the case or not (which doesn't seems to be, as you're suggesting him to do so)
    – Tiago Cardoso
    Mar 12, 2017 at 23:12
  • You're right OP is not mentioning it. I thought it might be relevant if someone is looking for questions tagged with Nexus and my answer features it. Mar 12, 2017 at 23:14
  • In this sense, from other Nexus users' perspective, your answer would be the correct... right? Not sure if that's fair, sounds like leaving a trail of bread crumbs into your answer. Anyways, better keep using the tags when it helps understand the question being asked, rather than underlying, not direct relationships. Cheers
    – Tiago Cardoso
    Mar 12, 2017 at 23:19
  • Why downvotes? Can someone elaborate? Thx :) Mar 14, 2017 at 7:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.