Dealing With Unplanned but Urgent Work Through DevOps

3) Maintenance and Evolution:
To keep a product alive, we choose backlog stories that will bring value, and do them one after the other.
But... as support of the application may take a huge part the work. And when the problem is critical, there is nothing you can do but stop what you do and fix it. This can blow any estimation.
How do you deal with firefighting in a #NoProjects world?
And techniques to avoid it.
How does #NoProject and DevOps work together?

Let me take the last part of this question first. Operations have never been plagued by the project model the way development has. When does a SysAdmin ever say "The project is finished so I'm not going to restart the server?"

DevOps (aka Continuous Delivery) and Continuous Digital are a natural fit. The team is responsible and accountable: writing the code, deploying it and supporting it there after: "You built it, you operate it" as DevOps people like to say.

Of course the team needs to contain all the skills needed to service this approach. That might mean having an individual specialist on the team or it might mean that team members have multiple skills. A Continuous team is not just a DevOps team, it is also a Business-Technology team - or #BizTech to coin a hashtag. (This week I heard such a team called a BizDevOps team. That is one portmanteau too far for me.)

Which brings us quite nicely to the first part of this question: how do you manage - and perhaps even plan for: unplanned work?

What I would like to happen when unplanned work appears is that it is written on a card and placed in the backlog. It then takes its place with all the other possible work. But... as the questioner states: this work can't wait, it is urgent.

Unplanned but urgent simply needs to be done. Quite possibly other work, less valuable work or work which is not time critical may even be interrupted.

At this point I was about to refer readers to an old blog post about Yellow Cards. But it turns out that I never wrote that post. Despite talking about Yellow cards for years I've never blogged about them. I wrote about them in Xanpan but for some reason or another I never wrote the blog... so here you go...

When a team is mid-sprint and unplanned work appears the team should:

• First, ask, "Can this work wait?" If so, then write it on a regular card and put it in the backlog.
• If not, then ask, is this more valuable than work we are doing now? If not, then someone needs to find the source of the request and explain why it isn't going to get done.
• Assuming it is urgent, it gets written on a Yellow card.
• If it is really, really urgent, then someone drops what they are doing and works on the yellow card immediately.
• If it can wait a little while, then the next person who finishes their current work picks up the card and does it.
• Once the yellow card is done, mark it as done as with any other card and work continues as before.

Accepting unplanned work into a sprint impacts the other work the team is doing. I'm not a big fan of the commitment protocol so to me it is no big deal if this work displaces something else. But if your team are expected to hold fast to hard commitments while dealing with unplanned work then you have a problem, call me, we need to talk more.

At the end of the iteration, we can look at the cards and reason about them. Now we can see the work we can manage it and decide what to do about it.

I count up the yellow cards and all the planned work cards. That allows me to calculate a ratio of planned versus unplanned work. (Sometimes teams put a retrospective points estimate on a yellow, but doing a card count is often sufficient.)

This can be tracked over time — graph it, make it visible again. Now we can look at the work and the pattern of work, reason about it, maybe do some root-cause analysis. Perhaps:

• Perhaps much of the urgent work isn't really so urgent, perhaps the team should push back more. Maybe the team, or one of the team leaders, needs to the authority to say No.
• Perhaps most of the unplanned work comes from a particular person. Maybe this person doesn't realize the impact of their unplanned requests, or maybe they need to be included in the planning process, or a million other reasons.
• Perhaps the unplanned work is coming from the same sub-system, maybe some remedial work on that sub-system could reduce the amount of unexpected work.
• Perhaps the unplanned work is just the nature of the business and being responsive is valuable.

Looked at this way, we can think about reducing the amount of unplanned work. But also, we can plan for unplanned work.

It is likely that over time a pattern will emerge. One team I know found that 20% to 25% of their work in any sprint was unplanned. They simply planned for 20% less work. They now had the capacity to cope with unplanned work. At the least, they could expectation manage stakeholders.

One team found that each sprint they were doing about 20% IT support tasks (new PCs, Word problems, etc.) so they hired a support technician.

Another team who agonized about unplanned work found that actually they only had about one unplanned card a week. Their problem was not excessive unplanned work but the fact that unplanned work tended to have a very high profile in the company.

Teams which find they have very high levels of unplanned work on a regular basis (e.g. over 50% of work for several months) may well decide to adopt a full Kanban system. Indeed, Kanban folk probably recognise my description as a very simple example of quality-of-service and policies.

I say more about Yellow Cards for unplanned but urgent in Xanpan, so you might like to continue reading there.

This is the third question carried over from the #NoEstimates/#NoProjects August workshop in Zurich.