Archives: September 20, 2023

Analyse Your Unplanned Work!

‘So much unplanned work just hits us and we have to deal with it! ‘

This is a phrase I often here from teams when discussing the flow of their work. This team just seemed to accept that this is part of life and crack on. But this was not an isolated incident, and as I talked to many teams they all had a similar story. It got me wondering, how much of this happens? and what is the root cause of that work? I had to find a way to separate the evidence from the inference. All I had right now was people think it is a problem.

We had already got issue types to cover expedite work and support work, but the team said this work was different and more impactful.

So I created ‘The Great Unplanned Work Experiment’. This involved 5 pilot teams who committed to understanding more about the unplanned work in their teams. We defined unplanned work as:

‘Last minute changes that needed to be made by other internal or 3rd party teams’

We created in Jira a work item type called ‘Unplanned Work’ and we asked the teams to categorise all the work that came in and they deemed to be unplanned for the next two weeks.

In this particular company we used power BI integrated with Jira to view our data. We broke it into a couple of views:

  • Across all teams – One Chart
  • Each Teams view – 5 Charts

So you could see from this first cut, that some teams had more unplanned work than others. The team in the top right was the most affected and so warranted some further investigation.

We gathered up all the unplanned tickets from the last three months and sat down with the team to start discussing what this work was. I had recently hosted a meet-up with Troy Magennis and took inspiration from some work he had done around clustering, so I adapted that technique for this exercise. You can watch his video here.

In summary we:

  • Listed all the unplanned pieces of work, and added roughly how much time we had spent on each. I just looked roughly from the time it spent in flight.
  • Discussed each and then created some themes around the work.
  • Added up the total amount of time spent on each theme.
  • Took the theme with the highest amount of time spent on it.
  • Plotted it to the grid to understand the frequency of this type of the work and the impact

Ultimately creating this grid gave us a view of the ones we need to tackle first e.g. Ones in H/H. The ones in L/L are annoying, but in reality it will probably cost us more time to solve these than just do them. So in reality little point in targeting.

We then created a whole heap of actions from this. Fast forward 3 months when we ran this exercise again, the unplanned was greatly reduced and so more effort can be completed on the project work.

That’s an important point, because the more unplanned work we do. It distracts us from the work we are meant to be doing. It can cause delay and we know there is a cost to context switching we well. Whilst this team didn’t manage to stop unplanned totally, they reduced it by a significant amount and now better equipped to know how to capture and analyse.

I was very excited from all the work the teams put in and what we found to fix. We replayed this to the leadership team and got agreement to roll out across all 32 teams and start looking for those improvements we could make. This is part of a report that the leadership team see on a monthly basis. They ask us about the levels and what support we need from them to keep unplanned low. I think it is fabulous they are so engaged with this.

As I wrote this blog today I had a look in the system to see what the levels are like.

You can see it is on the rise from the trend line. So it’s time we do some more analysis of this! It is an ongoing activity that you need to do and so you will want a process in place to review.

Overall because of the focus on unplanned work, I found that teams became more thoughtful of keeping other teams involved in work they might do. Adding a ticket onto another team’s board to say this piece of work is a 2 minute job. But makes a massive difference.

Too much unplanned work is bad for your system and a signal that you are not working as a truly cohesive system.

So, how much unplanned work do you do?


Is There A Goal In Kanban?

At least once a week I hear someone say something like ‘Our people like Scrum as it gives them a goal to drive towards, in Kanban there is no goal and they feel like they are on a hamster wheel’

What a load of rubbish!! There is absolutely no reason you cannot have a goal. When working on deliveries they are a great thing to have to keep the team driven and to understand if we are on track. They might not be applicable for all types of work that you do. But you can decide that!

There is also a cadence called Delivery Planning that can help us in this space.

The Delivery Planning cadence is to ‘Plan and monitor deliveries to customers’ In fact, this is actually my favourite cadence. I know, I am super geeky!

So if I was working on a new release of the company website, I might set a goal to say that by the end of the month, we will launch the new blog page and highlight all the work items that need to be completed to be able to meet the goal. We would use data, forecasts and the service team to tell us whether that is achievable.

I can then use the Delivery Planning cadence to:

  1. Understand how we are doing towards the goal, and the probability we are going to hit it
  2. Decide mitigating actions if goals are look unachievable
  3. Make decisions on what to release and when
  4. Change the class of service if something now needs to be expedited

In terms of execution of this cadence, I usually swap it out with a Daily Kanban. So once a week on a Wednesday I do this instead of a Daily Kanban for 30 mins. You can pick whatever day, frequency and duration you want. Really depends on your deadline, dependencies and the criticality of your work.

It is typically the Service Delivery Manager who facilitates this, but I like to empower everyone once they have seen me do it and feel comfortable to lead themselves.

I ask the service team(s) to look at our board and confirm the goal to them. This might be one team, or multiple including any external third parties. We have a short discussion about our throughput and our current lead times. I then give them some time to put on a probability of us completing that work in line with the goal. I use the percentages of:

The team will then map these onto the board:

If you use an electronic tool, adding them to the first part of the title is a good work around. You can also set up nice filters around the goals.

This then immediately gives me a view on where we are on the delivery. Items that are at 100% or 75% I probably don’t need to talk about in great detail, other than to understand when we hope to make live so we can tell the stakeholders and organise anything like outages (if you work in tech).

Items 50% or lower (shown in orange) will need a more detailed conversation.

We want to understand:

  1. What do we now know that is causing a delay to this?
  2. What can we do to get back on track?
  3. Will changing the Class of Service to Expedite help?
  4. Implications or risks to other things?
  5. Predicted delivery date if we cannot influence in any way

One of my best conversations with a client was when a team discovered that a work item was not going to be completed because the developer only worked 2 days a week! How did no one know that? and why did he not mention this?

By the end of the conversation, I am going to have a better view of what is possible and can talk to stakeholders about the items we are going to deliver and when. Sometimes called the Delivery Manifest in Kanban. We will also have a list of actions to get us back on track and/or the ability to be able to manage the customers expectations if something is going to be missed. We can then start talking about reducing scope for example.

I sometimes think ‘Well surely in the Daily Kanban we should pick up on these things?’ You would be surprised how much extra comes out in these conversation when you start asking service teams to look at probability or sometimes just gut instinct.

After this cadence and your conversations with all relevant parties, you will most likely end up updating the teams roadmap/plan. Oh yes, we can also have plans in Kanban!

So, you definitely can have goals in Kanban and we want to be reviewing our work against that on a regular basis. There is no reason you cannot start the above cadence today! You can even use it with Scrum.

Give it a go and let me know how you get on and what corkers you find!

We talk more about the Cadences in Kanban during the ‘Kanban System Improvements’ Class.


We Don’t Estimate In Kanban – Fact or Myth?

This is one of the great debates! But the answer is not always black or white in reality.

Let’s look at the value we get from an estimation process:

  1. Everyone understands the work at hand and any complexities
  2. We get an idea of any issues or risks that could impede this work
  3. We get an idea of dependencies required inside or outside of our system

For me, these three things are the most important pieces. The understanding, alignment and management of things that could impede us.

The fourth thing we get from estimation is the number…. It is natural that everything we do will have some need for a forecast, we cannot run our companies on hopes and prayers.

But there are different ways in which we can forecast.

In one of my previous blogs, we took a look at separating out different work item types. This is your first step to be able to understand how long pieces of work are taking to move through the system.

Now we have this view of different types of work, we can see how much variability there really is. For example, below is a control chart showing just user stories.

You can see that 85% of the time stories will be completed in 8.71 days. You can also see there are some real outliers around 20-35 days. This is a great signal to spend some time investigating and finding out what caused that to be much higher than the rest. The more of these you have, the more opportunity for process improvement. The 85th percentile is really just a confidence factor and you have a choice to change this number. But if I said you had a 85% chance of learning something from this article, you would probably be happy and keep reading.

I would have one of these charts for each work item type. You will soon realise if something crazy is going on and it will allow you to ask questions. For single piece flow we could also give our customers expectations of how long work is taking.

What this chart doesn’t show you is how this is changing over time. This is also important! Are we trending up or down?

So you can produce charts like the above to show this. In the same team you can see this has been trending down in the last 3 months. That could be for a number of reasons, the key is these charts don’t give you the answer, but it prompts you to ask the question and find out the story. You are looking for improvement and stability. If you can have both at the same time 🙂 There are also many views of this data in different charts to give you some forensics. I have just shown you two.

What I have shown you has very much been at team service level. Forecasting is not limited to just here. When we first create options in our companies we also need a rough view on size. In one company I partner with we have T-shirt sizes. So an XL is 16 weeks. A rough cut of size and will be refined all the way through the delivery. But it gives them something to hang the roadmaps on.

So back to my original question.

Myth…

We do understand the size of the work. But this is based upon historical data by work item type, and we accept that this is not perfect and changes as we and the system changes. We still have conversations about the work, but we might say ‘Can this work be done in 10 days or less’ using the data to determine that number.

We continually monitor to understand variations and causes for our trend line changing. This could result in process improvement inside or outside of the team.

But remember the first principle – Start with what you do now! I am not saying throw all current processes out on day one! But be aware there are other options, and maybe start looking at this stuff behind the scenes. That’s what I did and over time I stopped using the other ways.

You might have also heard of Monte Carlo modelling. Other people do a far better job than me at explaining this and so worth checking out this video from Sonya or Troy’s Website.

So next time you crack open your online tool, have a look and see what your data is telling you!

You will learn more about these charts on my Kanban System Design Course. Equally if you just want to have a chat. Reach out to me.