How to facilitate a Team with high variability

Two things come to mind:

Emergencies: Root Cause?
What is causing these emergencies and is it within your control to minimize or eliminate them. Are they bugs or similar that are making their way into the product? You can't not fix critical issues and they will disrupt your strategic sprint goals, but you can work towards seriously mitigating the severity and number coming out of your sprints. This might mean experimenting with new skills, techniques or tools. They key is don't facilitate them into being part of the normal process, but facilitate the team towards getting past them.

Threating to cancel contracts
This smells of a bad relationship to me. One which doesn't sound mutually respectful. If the relationship is wrought with past critical bugs that are related to the above, solving those will go a long way. In the end, what kinds of things can you do to improve that relationship? Could you bring them in to understand what you are doing to meet their needs? This isn't always easy or short term.

The cause of these emergencies is that in the past they’ve released shitty software into production with zero quality and tests. Because of this, so once in a while (like today) blocking issues occurs. I’m not talking about maintenance kind of bugs that can wait, but about it-needs-to-be-fixed-right-now kind of issues. These blocking issues usually has nothing to do with the current project, but were the results of bad deliverables in the past. Because the team is quite small (3 developers) when an blocking issue occurs, the team will lose at least 1 developer.

It’s also hard to reserve a x amount of time, because we never know when and how big these issues can be. Therefore very hard to commit to the Stories that are discussed during the Planning Meetings.

The only thing we can do now is do the Sprint Planning Meeting. Come up with an estimation (based on relative complexity), do our Sprint (which is 2 weeks) and see how much distractions we will be facing. But from a planning management perspective it really sucks…

In my experience there are three basic scenarios to this reactive type of management, each of which requires a different treatment. These are:

1) The Product Owner is the one "doing the disturbing". In other words, the PO has reprioritised the work mid-sprint, instead of introducing it in a future planning session. In this situation you need to make sure that the team are willing and capable of accepting the work, and you need to determine the impact on the sprint goal. Only the development team can accept work into their sprint backlog; such changes cannot be imposed on them, and the PO may need to be educated about this.

2) A senior manager, but not the PO, is the one "doing the disturbing". This is by far and away the trickier situation. The canonical Scrum approach is to get the manager to work with the PO on prioritisation (see 1 above) but this is far easier said than done. What if the senior manager has hiring & firing power over the dev team? In that situation the team are likely to jump when the manager says so, and all your exhortations for applying best practices will fall on deaf ears.

My "solution" to this (if it can be called one) is firstly to make sure the work is tracked and made visible. Tickets should be raised and put on the scrum board for the work, even though it has no bearing on the sprint goal. These should be sized with the actuals that it takes to do them. Next, I'd raise an immediate impediment ("andon" flag) to show that the sprint has gone into exception. This is the trigger for the PO to go through his or her own escalation process. As a ScrumMaster I'd work with the PO closely on that and give them all the support they need. I'll pay close attention to the "Cost of Delay" principle if I get involved in any subsequent bun fights, since it is important to maintain a neutral (and as far as possible, a non-political) position.

3) A third party is the one "doing the disturbing". It could be a customer who (perhaps for historical reasons) has a hotline of sorts to the developers and thinks they can use it to set their priorities. If you are the Scrum Master, then it's your problem to fix. You need to shield the team against this behaviour. Generally I tell my devs to forward any such requests to me, and I'll work with the PO on educating the customer appropriately.

Hope this helps.

Hi Ian,
Thanks for sharing your experience.
Unfortunately its none of the 3 given scenarios.
Let me provide you with some context: my company develops IT solutions which are used by a numerous of companies. These companies can either be our direct customers or wholesalers who buy our solutions and sell it to their customers.
Since I’m a strong believer of Agile Software Development I introduced Scrum within the Development department. We currently have 1 Scrum team which consists of 4 developers. While the Scrum team is focussing on delivering new products, we still get a lot of blocking issues in production. Mostly these blocking issues needs to be fixed right away because those are usually our direct customers. A paying customers (company) use our product, notice a blocking issue and calls our helpdesk. Our helpdesk creates a ticket and if it’s really a blocking issue someone within the Scrum team NEEDS to solve this.

So the customer isn’t the PO, manager nor customer with direct hotline. The developers don’t have direct contact with the clients. They are the paying customers that will cancel their contract if it isn’t fixed within e.g. 1 hour. (yes we’re building critical real time solutions, absolutely no or little room for errors) It’s impossible for me to shield the team from the helpdesk because we’re not talking about minor bugs that about “it-needs-to-be-fixed-within-1hr blocking issues because otherwise the customer will lose business.

I forgot to mention, most of the blocking issues that comes in aren't even related to the current project. It's related to a module that has been build years and years ago.

Hi P,

Are you sure that Scrum is right for you in this situation? If the availability of team members are totally unpredictable sprint planning and forecasting what can be completed is a futile effort.

Is it possible to setup a separate team that handles these critical issues, that are not part of the scrum team?
Add testing to the areas where the bugs appear to prevent them from surfacing again. If this is a big, old legacy system this may not be worthwhile.
See what you can do to increase code quality that will prevent this from happening in the future. This will be a big investement that will slow you down.

Our dev. team are handling support issues, but this works does not vary much between sprints so it can be planned for. One developer per week act as a goalkeeper and takes care of any support issues, protecting the other team members from being disturbed. This has worked fine for us so far.

Good luck!
Fredrik

Hi Fredrik,

Thanks for your response.

I also think that Scrum is probably not the best methodology for this company currently, but on the other hand I can’t imagine that other companies aren’t facing these kind of problems as well. To me it sounds like a very common problem that occurs at all small companies right? Team A worked on product A (ad-hoc development without testing etc.) , released it to live, start working on a product B (Scrum) and while they are Scrumming, customers that are using product A ran into blocking issues that weren’t tested and needs to be fixed immediately.

If it were like major/ minor problems that can wait till next iteration, I could include them in our team (or create a maintenance Kan Ban team) and plan it. But these are business critical issues that needs to be fixed immediately because it affects our customers because they will be losing money/clients because of these issues.

I know this problem can’t be solved on project level, but it needs to be solved on organisational level. My company wants to do that, but we have a major resourcing/ budget problem. Me as Agile Coach have gave them some advice etc., but unfortunately these kind of changes doesn’t happen that fast…
So my goal of this post is to brainstorm with you guys and see what the possible options are…

I disagree 100%. Scrum is surfacing signals about your world. Scrum does not exist to make planning easier or more accurate. Scrum exists to make you aware of the problems or ineffective parts of your system so you can try new ways of working and solve those problems.

By leaving Scrum you simply ignore those problems.

My suggestion if I were on your team:

1. Allocate some time to fix the product that is causing the problems to surface
2. Don't fill the sprint 100% with planned work... leave slack time for fixing the problems or have someone fully available for fixing problems.

Don't build a process that sustains the disrupts... fix them!

Hi P

Where is the Product Owner? What is he or she doing to prioritise the backlog of work and to otherwise represent the product to your team? Do you actually have a PO?

Ryan: Scrum may have helped hilight problems, but does that automatically make it the right tool for solving them? If it's not possible to create a team that can work relatively undisturbed in sprints you have a problem. If you can create such a team (see my suggestions above) and solve the other issues, fine, go ahead. If not, maybe you should consider not using Scrum.

Fredrik,

No tool will solve the problem. You and your team(s) must do that. Scrum will continue to show you how effective your attempts are though.

If it's not possible to create a team that can work relatively undisturbed in sprints

You will never have a fully planned sprint. No one will. It's well understand and the oft cited Cone of Uncertainty describes it well. Scrum is meant for this world of unknowns.

Kanban will do nothing to predict the future more accurately, but if you feel it will psychologically make it easier to adjust based on knew knowledge - that might be the symptom you focus on instead.

Hi Ryan!

You will never have a fully planned sprint. No one will. It's well understand and the oft cited Cone of Uncertainty describes it well. Scrum is meant for this world of unknowns.

Noone ever mentioned a fully planned sprint. That's not what this is about. If I understand this situation correctly this team is constantly interrupted in a major way, every sprint, all the time. If you cannot fix this and protect the team, which is the responsibility of the SM, you are letting your team down.

Just my 2 cents.

Hi Ian,

We do have a dedicated PO and he is prioritizing our Product Backlog which is based on Business Value. Unfortunately, we can’t predict these kind of blocking issues as they occur suddenly.
We do have a list of bugs and improvements that the team can do, but these can be planned.

And even if the PO prioritize the Product Backlog, when a blocking issue occurs ALL attention needs to be focus on solving that issue. So the PO as full authority over our project, but not over issues that affects the organisation directly.

Hi Ryan,

Thanks for your response.

About your suggestions:

Allocate some time to fix the product that is causing the problems to surface

This is quite difficult, because:
1. I’m talking about OLD legacy systems where the previous developers aren’t even working for the company anymore.
2. It’s hard to pinpoint the exact problem because the product/platform (which is huge) is currently working, and we only know there’s a problem when it occurs. (unpredictable) Plus our platform is integrated with other systems that are not developed in-house, so usually it takes a lot of time to figure out WHY this problem is happening, and then WHERE…

Don't fill the sprint 100% with planned work... leave slack time for fixing the problems or have someone fully available for fixing problems.

We usually don’t fill our Sprint with 100% planned work, due to these kind of issues. We have a list of bugs that needs to be fixed as well, but those are more “it can wait till the next release” bugs and these can wait and planned. But the blocking ones that occurs can (if it’s a major one, luckily it doesn’t always happen) be so huge that it takes up the entire Sprint to track it, fixed it, test it.
I’m not saying that Scrum isn’t working, because I do understand that Scrum shows the weaknesses of a company, but in some cases the companies budget/resources limits your possibilities.
Yes, it is sometime that needs to be fixed, I totally I agree with you, but currently it’s not possible. So I’m trying to find a temp. solution not to SOLVE it but to manage it.

Hi Fredrik,

I totally agree if the problems are solvable by the SM and he/she doesn’t do it, then the SM is indeed letting the team down. For example: if the PO or other stakeholders of the project consistently interrupts the team with new requirements and the SM doesn’t do anything then yes… he/she isn’t doing the job well.

But if blocking issues occurs that needs to be fixed right away, let’s say major bug in production (even if it means that you can’t finished the committed Stories) it’s something the SM can’t fix, so is the SM really letting his/her team down?

Hi P. Ross,

Sorry for not replying sooner.
My point is that if you don't see any chance of being able to protect the team maybe Scrum is not your best option. If this disturbance can be managed in some way (by assigning a goalkeeper or creating a separate team to handle the critical issues etc.) then go ahead. For the same reasons I would not introduce Scrum if I cannot assign a PO/SM, Can not setup a dev. team that is willing to try Scrum, can not get commitment from management etc.

regards
Fredrik

Posted By Ryan Cromwell on 15 Feb 2013 08:50 AM

You will never have a fully planned sprint. No one will. It's well understand and the oft cited Cone of Uncertainty describes it well. Scrum is meant for this world of unknowns.

The Cone of Uncertainty comes from the inherent uncertain nature of software development, NOT form being disturbed by a 3rd party. The Cone, in general circumstance, is about 20%. Adding a 3rd party in there will increase the cone to 50% or beyond, making Velocity a moot point and planning useless.

If these kinds of disturbances happen and the Scrum Master allows them, you're not doing Scrum. You get all the downsides of Scrum without either the added Velocity or Predictability.

These intrusions are a problem. And as my trainer said so succinctly: Fix it! It cannot happen. The Development team needs to be able to run without outside interference.

How to fix it? Maybe remove one person from the Scrum team and dedicate him to fixing these problems. He'll be idle for most of his time but that can't be helped. The company created the bad situation and will now have to pay for it.

The Cone of Uncertainty comes from the inherent uncertain nature of software development, NOT form being disturbed by a 3rd party.

I can accept that. I'll have to reread the paper which I'm unlikely to do, but I accept this as being a good thing.

The Cone, in general circumstance, is about 20%. Adding a 3rd party in there will increase the cone to 50% or beyond

A bit arbitrary - they don't align with PMI or Boehm's numbers. Where are you getting 20% and 50%. Yes, unpredictability focus makes planning difficult. Not useless.

You get all the downsides of Scrum without either the added Velocity or Predictability.

Would you mind clearing that one up? What you see as the downsides that are worth the cost if you can go faster.