All posts by Helen Meek

Kanban For Dating

6 years ago I met the man of my dreams. I didn’t know it at the time as we embarked on a bit of jovial fun. We were organising the first ever UK scrum coaching retreat and so ended up spending quite a bit of time together. I also learned that he was single and wanted to get back onto the dating scene. As we collaborated on the retreat it dawned on me that we should Kanbanize his dating. Kanban can be literally used for anything, and so why not this?

We drew up an initial Kanban system that looked a little something like this.

You can see this style of board is more of a higher level visualisation. Sometimes we call this a level 3 Initiative or strategy board. It means that you can truly see the end-to-end process. But the work moving through this board is going to be much slower. In reality, each of these different workflow states e.g. casual dating would have its own lower level Kanban system to show the more granular parts of the process.

Now, we didn’t want him to go too wild and so we agreed a Work in progress limit (WIP), though I have to admit we did change the meaning to ‘Women in progress’. We agreed three people in casual dating was more than ample. We also agreed some explicit policies about what would get the person to the next stage or abandoned. I am sorry to say there were a few ladies abandoned.

As we explored his explicit policies, he found an article called ’33 questions to fall in love’. As a long term singleton I scoffed at this quiz, and didn’t think it would be possible. But he wanted to set it as part of his policies and I told him.. let’s try out some of these question!

Trying out those questions and the time we spent together, changed the game. We had a new expedite in the system!

In Kanban we have this concept of a commitment point. On my system you could argue that the commitment point is from when we first became exclusive. But typically this is at the point of work getting started. There is also a second commitment point as you make the choice to go live. In my case that would be marriage.

6 years later, through covid times and life challenges, the Return On Investment is a gift that just keeps on giving. I never knew it was possible to love a person so much and be so loved in return. Many a time we have laughed about Kanban dating and said we should turn it into a blog one day. I often tell my classes about this story as my Kanban geekery has no bounds. We are a perfect match of me being the Kanban Queen and him being that Scrum Guy. We truly live our methods in our day to day life.

But there was one part of the system I never made it too…

We went to the Scrum Gathering in New Orleans. I had a fabulous time at the conference and met some wonderful people. New Orleans was an amazing place to visit and we saw so many things as we toured around wider Louisiana.

It was on the final day after the conference, it was also our 6 year anniversary. We were flying back that night and had a whole day to kill. He took me on a steam boat on the Mississippi and then to the aquarium. I love aquariums and seeing the fish.

As we walked through the shark tunnel he got down on one knee and made me the happiest person! I had finally made it into the ‘Ready for Marriage’ part of the system.

I said ‘Yes’ – After I checked he really meant it of course! Guess I am going to need a new Kanban system for the wedding.

So, Kanban can be used for anything and like me, it could help you get a happy ending. In work or life…

Special mention to John Barratt, the man of my dreams and his friend Rickard Jones who always campaigned for John to ask me out, even before we started organising the Scrum Retreat. We hate to say this, but Rickard you were right…


5 Patterns for the Team Kanban Meeting

Before we get started, let’s align on what we mean by the Team Kanban meeting.

The purpose of the Kanban meeting is to form a collaborative conversation about the work, any issues in the workflow and any general issues that come up. We then aim to define the actions to resolve. Generally this session is facilitated by a team lead, scrum master or delivery manager (Enter what you call them here!) But there is no reason why this session cannot be faciltated by anyone, as long as they are comfortable to do so.

At this level, the 15-20 minute session is something that is held daily at the same time and around a fully updated Kanban board with the team.

Now typically at this point I see teams do various styles of good and bad. There is nothing worse than hearing someone telling us what they did yesterday. Even the Scrum guide has got rid of that question!

It is important to remember one of our principles at this point.

We are interested in the status of the work and not the workload of individual people.

So I wanted to give you 5 patterns to try with your team to help keep it fresh and to solve different problems or challenges you might have.

Pattern 1 – Full Board Walk

You will likely be familiar with this pattern, but the purpose here is to talk about every single ticket on your board. The key things to remember are:

  • We walk the board from right to left. We do this because the work on the right is nearly done and we want to be able to release the value from that.
  • Each ticket is then discussed and the status is given. Note, that we focus on the tickets on the board and not ask each member of the group individually.
  • Team members should raise any issues, worries or potential risks to the work. If this can be discussed in the timebox, then great, if not then we might need to get people together afterwards.
  • Team members might also flag if they are going to be pulling more work soon and this is a great opportunity to discuss whether anyone needs any help first.
  • We will flag during this session any expedited or fixed date tickets that are coming in close proximity, because we might need to take some action upon that.

By the end of the session everyone will have a clear understanding of where we are on the work, what needs our focus or mitigating actions completed.

Pattern 2 – Item Age

One of my favourite reports is the Item Age report. This chart tells you how long work has been in play for, the ones that are about to exceed your service level agreement, and the ones that have well and truly passed it! As we settle into our kanban routine, understanding our lead times and service level agreements with our customers come more into play. We also want a level of predictability for our customers, and so having ageing work is going to impact your forecasts.

Before the Team Kanban meeting, I do some high level analysis of the tickets in play. I would then mark in the system the ones that have breached our service level agreement, and the ones that are in proximity.

I would then use the Daily Kanban meeting to highlight these with the team to understand the root cause and what we need to do to get these back on track. I would also want to discuss these at the retrospective because maybe there is something we can do to stop this from happening again in the future.

I trust the team will raise any other issues they might have that we need to discuss, otherwise, I would just get them to focus on this pattern and the resolutions we need to put in place.

Pattern 3 – Blockers, Waiting and On Hold

If you are a team that has a lot of these, maybe we need to have a regular conversation around about them. Similar to Item age, I could understand how long they have been blocked and starting with the oldest ones work backwards to understand what we need to do to get these out of the system.

You can use a technique called blocker clustering in a retrospective to really understand what you are seeing, how long it is costing you and what area to target first for improvements.

The name of the game is to have as minimal blocked, waiting or on-hold tickets as possible. These blocked tickets hurt us and so we will need to put process improvement in place.

For example

  • If we have lots of tickets missing information. Consider improving your ticket refinement or putting a triage in place.
  • If you are stuck waiting on third parties or other teams. Consider on alignment of priorities, how can we plan better together, how can we keep better informed and whether we need to understand their capability to only send them the work they know they can do. This might mean we change the order of our backlog based on this. There is no point starting work if you know it is going to get stuck.
  • If we are blocked on defects. Consider what we can do to improve our quality.

So, if you have lots of blocked, on hold or waiting pieces of work maybe you need to have this pattern to discuss and also implement some targeted sessions to understand how you can mitigate against them.

Pattern 4 – Third Parties or Other Teams Involved

Often teams have to collaborate with third parties or other teams to be able to complete their work. Ideally, you will make their work visible on your board or maybe you have a coordination-style board to help bring everything together. Ultimately you have to work together to deliver the ‘Thing’.

If you are working with just 1 or 2 extra people, the ideal would be to get them to attend your Daily Kanban Meeting. If this is not possible then you might consider a weekly version of this which focuses on maximising the relationship and the shared work we are doing.

Where multiple teams and many people are collaborating together you might consider implementing the Workflow Kanban Meeting. This session is typically held once a week ( can be every 2 weeks) and all teams are invited along to hear the conversation. So depending on the number of teams, you could have between 4-50 people in attendance. This session is facilitated by one person where they walkthrough a coordination board which brings everyone’s work together. Updates are solicited from the team and only one person will give that update. Everyone else is just listening. Now I know what you are thinking…jeeez this is an expensive meeting! But for me, the pattern of scrum of scrums never got implemented properly and no one ever brought any information back to the teams. So the idea here is, the cost of everyone coming together to hear, is cheaper than the cost of identifying a problem late in the day. This session is still 15-20 mins long and thinking about it, if you swapped out a Team Kanban with one of the Workflow Kanban meetings, the cost is the same. The value here is everyone then leaves this meeting with the same knowledge and understanding.

Pattern 5 – Delivery Planning Cadence

This cadence is actually its own thing, but I often choose to switch out a Daily Team Kanban with this session. I have actually already written a blog about this cadence and so I refer you to that for full details on how to do. You can find it here.

Conclusion

There are five patterns here and there are 5 days of the week. By covering these 5 patterns each day of the week you are hitting several key activities to ensure that your board keeps flowing and are on top of things.

When I started implementing these, I noticed that each day I found out something new about the same problem, but just hadn’t been brought up before. It is crazy and I wonder why my usual Kanban meeting didn’t highlight these things. But putting a different lens on this really helped those conversations. It also kept it fresh and people on their toes. We don’t want people to be robots in these sessions, we need good healthy team debates about how are we going to get work done.

So what patterns can you start using in your team tomorrow? Not currently a Kanban team? No worries, these patterns can be used in Scrum as well.

If you have anymore patterns, let me know!

Want to learn more about Kanban? Join me in one of my upcoming classes


Are Scrum Retrospectives And Kanban Retrospectives The Same?

Firstly, if you know anything about me, you’ll know that I LOVE retrospectives! 10 years ago I was busting out my Rocky, Top Gun and other 80’s & 90’s movies , music and game retrospectives with my teams. The more creative the better was my mantra. I want teams to be rewarded with something a little fun after their sprint, and to find new ways to be able to articulate sometimes the same problems and come up with new ways to improve.

The Scrum Guide says ‘The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.’

This is looking through the lens of individuals, interactions, processes, tools, and their Definition of Done. Ultimately we want to discuss the good, the bad and the ugly and come up with those creative ways to solve our issues and improve effectiveness.

It’s important to note that Scrum calls these meetings ‘events’.

Naturally, I have seen my fair share of terrible retrospectives, but it’s not my job today to help solve that one!

So how is Kanban different?

We like to call these meetings ‘Cadences’ and they form part of the 5th practice ‘Feedback Loops’

Since the introduction of the Kanban Maturity Model in 2018, how we articulate our retrospectives has changed. We look at them depending on the level of maturity you are at currently, and where you want to be. One of the benefits is that you can see the different levels of growth you need to make to make sure your service is fit for purpose. One of the negatives is that the names change as you evolve and it can get a little confusing. At the end of the day, you can call them what you want, it is the good practice that they introduce that is important.

Level 1 (Team focussed) – Team Retrospective

This can closely be compared to what we recognise in the scrum retrospective. Kanban describes it as a specific practice where teams reflect on how they work and which aspects of the process could be improved to get better outcomes.

At this level, it is very much focussed on the team.

Level 2 (Customer Driven) – Flow Review

From this point you will see that I start to use the word service. Kanban encourages you to take a service-oriented approach to understanding your organisation and how work flows through it. This service-oriented organisational paradigm is based on the idea that your organisation is an organic entity consisting of a network of services, each of them living and breathing, and evolving.

The Flow Review (FR) is to develop an initial understanding of the delivered service and use it to facilitate work planning and thereby improve predictability. At this stage of maturity, you would have introduced some data insights into the service such as:

  • The cumulative flow diagram (CFD)
  • Lead time distribution
  • Item age
  • Control Chart
  • Blockers
  • Levels of defects

We would use these with the services to sit down and have conversations. For example, we might identify that our lead time is currently 15 days. We could discuss what we could do to reduce this and then action. We could then revisit the data in an agreed period and see if what we have done, has helped us reduce the lead time and increased our delivery rate.

These types of retros require an upskill of understanding of the data, and psychological safety in the team so they do not feel judged or compared.

The key to think about here is, whether the service we provide to our customers is good enough, and improving. It’s an inward service conversation about what our customer thinks of how we get work done.

So for me this is where we start to see the difference. The Scrum guide does not mention the customer at this point. The customer perspective comes in for the Review event and that is more about the product, rather than how the work gets done and the expectations around this.

Level 3 (Fit For Purpose) – Service Delivery Review

The Service Delivery Review (SDR) is to examine and improve the effectiveness of a selected service. But this time it has more of a customer focus and will include delivery team(s), customers, and other external stakeholders. To be clear, at this point it might be a number of service teams that could come together to discuss collaboration, progress and issues.

Rather than just that inward view of the service, we now want to know explicitly what our customers think about our service. For example, they tell us we are ‘Too slow’ and we ask ‘ We deliver 85% of the time in 5 days or less, what would your desired be?’ We can then have a realistic conversations about whether their desire is even possible. It works both ways, we might have needs and expectations from them.

So we are closing the loop and bringing the service team(s) and customer(s) closer together. This close relationship and feedback loop is going to help build us a strong and adaptable end to end service.

Pick and Mix – Conclusion

In the UK we have this concept of pick and mix. It’s where they have rows of sweets and you can pick as many as you can fit into a tub for a set price. The beauty is you can just pick all your favourites.

I see the above as a pick and mix. You wouldn’t just do one of them, to get the best value you need to do them all at different points. You still need to make sure the team is happy, you still need to look at the data and you still need to make sure the customer is getting what they need.

So as a service you need to sit down and look at what that schedule is. This does not mean you pile in 4 new meetings, this means you potentially change the format of your existing 2 week retro to hit all the key needs.

Bringing it back to the original question. Both Scrum and Kanban are both looking to improve the way we do things. Kanban for more is a little clearer on expectations with the introduction of the different levels.

But why do I need to be Scrum or Kanban? Everything above can be applied in both methods and so don’t limit yourself. Take the best of both and adapt for your situation.

If you want to learn more about the Kanban Cadences you can join me on my next Kanban System Improvements Class.


Why Do I Need Buffers Anyway?

A question I encounter when people are pushing back about extra columns on the board!

Buffers are designed for a number of reasons. They can:

  1. Enable us to understand the flow through the system
  2. Help you to control a bottleneck situation
  3. Act as an input queue for work coming into the system.

Let’s break each one of these down.

Enable us to understand the flow through the system

The above diagram shows yellow buffers applied to each of the work flow states. We use these to help us be a flow/pull system. We typically buffer each of the ‘Doing’ states Eg Dev, Test and Review to help us understand where the build up of work is happening. For example, if we see large amounts of work frequently in the ‘Ready to Test’ column, then this signals that the balance across the Dev and Test functions is not working as desired. Ultimately the queue of work grows in ‘Ready for Test’ and the testers are over burdened and the developers potentially run out of work in progress limit space, to be able to pull in more work. This leads to an unhappy team. If a one off problem, you might take smaller mitigating actions such as Dev’s helping to test. But if a reoccurring problem, then we need to look at our numbers of people, work in progress limits and anything else we can do to solve.

The work in buffer columns is actually bad for you. Seeing them is good! but work in there is effectively waiting. Waiting increases your lead time and ultimately reduces your ability to deliver. We call this our delivery rate.

So where we have work waiting in these buffers, we want to be working out how we can stop so much work being in there. My top tip in this instance is to really look at your work in progress limits against the number of people you have in the team. So whilst these might cause more noise on the board, they are designed to be a mirror and tell us where issues are occurring.

I typically buffer out all of my states when I design a board, but then get rid of them if they are not used. Remember, your board changes as your system and knowledge evolves.

Another rule of thumb I have when designing boards is whether a process is slick or fraught with issues. A team might complete a pull request, and the process is slick and the work picked up and completed quickly. Then you probably don’t need it as a buffer and a explicit policy will do. But generally no one likes doing this work, they sit around for days and lots of issues. So in this instance, a buffer is really going to highlight there is a problem here. Which we can then discuss as part of the retrospective/Flow review.

Help you to control a bottleneck situation

Imagine the situation where in your team the review process is completed outside of your organisation. You do other types of work as well, but some of them need an external partner. For that work you have little control of the review process. So a symptom you might see is a bottleneck of work building up to be reviewed. In this instance I would potentially add in a buffer, which is actually a queue. If I left the board without the green section, my ‘Ready to Review’ in the test column will become very full, eat up my work in progress and everything grinds to a halt. By adding the additional green section then we have a place for work to queue up in an unlimited way.

But wait, is what I have just taught you a good thing?

No it’s not, but its a way to control your system and keep things moving. Remember you are only as fast as the slowest part of your system and so I would quite quickly be wanting to talk to the reviewers and understand how many they can do at any given time, effectively creating a work in progress limit. I would then know that any additional work of that type sent through the system will get delayed. So maybe a better a balance of types of work we do would be beneficial and we do some other piece of work instead. This stops the bottle neck getting worse. We are now controlling our work item type flow.

Once you have your system balanced, then I would get rid of the green section and use my usual buffers.

Sometimes I get asked, ‘Why don’t you just increase the work in progress limits?’. Well by doing this we are hiding the problem and I really want that work in progress limit across both the working and the waiting state to create that holistic flow.

Act as an input queue for work coming into the system.

The ‘Ready’ or ‘Up next’ (whatever you call it) is a form of a buffer/queue. The purpose of this is to ensure you have enough ready work to keep the team fulfilled. Running out of work here would be bad news and costly in terms of team financial burn. We have a work in progress limit on this column, but it is worked out in a different way. You want the front end of your system to match the back end. For example we have to understand the delivery rate of the system, let’s say 2 per day. We also have to understand how much is being abandoned, blocked or waiting. We also have to understand do we have generalists in terms of skills or do we have people that will only do certain types of work. The more of this you have, the more of a uplift you have to have of this number. This is why staff liquidity is important. Translated, that just means we want teams who can do all of the stuff needed and we need to know in the team who wants to learn and who can teach.

In Conclusion

Buffers are critical for understanding the flow and controlling the work. We might not always need them, but initially we might choose them to truly be able to see what is happening with our work. This then guides us in continuous improvement. Sometimes people get caught up with names, is it a buffer or a queue. It doesn’t really matter, the point is the thing you are trying to achieve.

Take a look at your board. What changes do you need to make?


Are Kanban Explicit Policies and the Scrum Definition of Done The Same?

 

This is a common assumption that I come across when running my Kanban System Design Class.

Scrum defines the definition of done as: A formal description of the state of the Increment when it meets the quality measures required for the product.

Kanban defines it as: How work is done at each step of the process, how it is visualized, how decisions are made, and what the appropriate relationships are, both within the service organisation and with its customers.

So there are similarities, they are both interested in delivering value to the customers and ensuring that the quality is high.

But for me, explicit policies just go that one step further. Rather than just being mindful of the ‘Done’ state, it also considers the journey and states that the work takes to get you there. We ultimately want to be able to optimise the flow of work to be able to get the work done in a fit for purpose way.

Benefits of Explicit Policies

  • Understanding of how work gets done – Promotes transparency
  • Expectations are understood
  • Improved quality of output
  • Ownership – The team/org owns and defines them and changes them
  • New people know how we operate, and what they should be thinking about when they join

Examples of Types of Policies

Policies on Waiting States

On our boards we have columns that might be waiting states. Waiting states effectively impact your ability to deliver and how long it takes. It’s not in our interest to have work hanging around for long periods of time. So we want a way to encourage the movement of this. One of the first waiting states you will come across, and everyone has, is the Product Backlog. I often work with organisations and I see hundreds of tickets waiting for many years to be delivered. Let’s be honest with ourself, if it’s been on there longer than 6 months…you are probably not going to get your work done! We need to keep our Product Backlog moving and so we want to be reviewing this regularly and discarding anything that is unlikely to happen. So I often have a policy here that says ‘If a item is older than 6 months, discard, discuss with the raiser and archive’.

Another example is your blocked, waiting or on hold column. These columns are bad! The name of the game is to get work done, and so realistically we need to work on our upstream scheduling to ensure we have dependencies or other teams lined up. Equally if we are missing information, then what could we do differently next time in terms of getting this ready before we start. So maybe we need explicit policies around the readiness of work or maybe we have a policy on what to do if something has been blocked for more than 1 week.

So have a look on your board at the waiting states, and see what policies the team might need to agree to, to get things moving and organised.

Policies on Expedites or Class of Services In General

Organisations might call these different things such as major incidents or P1’s. Ultimately they are bad for your system. Check out this blog where I tell you why. So we need to be really clear about the impact of these on our system, how many we can deal with, and what truly makes an expedite.

I often see teams get many expedites as stakeholders know this is the fast lane. Some of them are important, others are just trying to push their luck. So we need to get a handle on this.

Our policy here might be a definition of what is an acceptable expedite that a team would take in, and a work in progress limit (WIP) to say we can only work on one of these at a given time.

There are other classes of services you can do this with as well, such as the Intangibles. Think of these as improvements to the system. You might have a policy that says you will keep 15% of the teams capacity to work on improvements.

A policy on a fixed date class of service might be that there truly is an impact if this thing is not done. Impact here could be financial or other.

So you have lots of options. What would your expedite policy look like?

Policies on Types of Work or Different Customers

If you are a team that does lots of different services eg project, support, small change then you are going to have lots of different types of work that you need to juggle. Maybe you need an explicit policy to ensure that each of these types of work gets done. Sometimes we call these ‘Capacity Allocation’ and have these as work in progress limits on the horizontal swim lanes. Not many tools allow you to have limits on these, and so a agreement needs to be put in place verbally and recorded.

This would work the same if you have a team with many different customers. Maybe marketing can have a WIP of 2 and Finance can have a WIP of 5. That way, all customers get served.

Policies Between Column

So here we articulate what needs to be done as we move between the columns. Sometimes these are called ‘Entry’ or ‘Exit’ criteria. This is closer to the definition of done as it details the ‘Done’ needs. I suspect many of you have this already, but wanted to include here for completeness.

Policies On Ways of Working

It’s during the retrospective or problems that teams normally come up with these. So let’s capture these on a team ways of working board. It might be things such as ‘No laptops during planning’ or ‘Work has to be peer reviewed by 2 people’. You don’t want to forget these things, so capture them.

The World Is Your Oyster!!

In fact! there is even more types of explicit policies you can have. Below is an abstract taken from Kanban plus. It documents the different levels of organisational maturity and the types of policies to be thinking about at the different stages. Hopefully this image will give you even more inspiration.

A Word Of Warning

There is a temptation to write policies for everything, and they end up really big. What happens then?

No one will bother reading them as they are too large. There is a fine line between explicit, but not war and peace. You have to find the right balance. Document them and review them regularly, aka every 3 months or when the nature of your work changes.

In Conclusion

Scrum and Kanban are very different methods, but they are complimentary. Try some of the above with Scrum or Kanban implementations. Whatever you decide, now is the time to get people back together and refresh those policies.


Tickets Have To Be The Same Size, Right?

Long story short, it’s a myth…

You got time for the long story?

The key thing is your board needs to flow and the work on the board needs to be valuable to our customers. It is impossible to cut them down to all the same size without lots of extra work or by making them so small they are no longer valuable. Why waste this time?

First let’s accept that we have different work item types and understand what these are. You can read more about this in another one of my blogs.

From this we already know that we have different sized tickets moving through our boards. We would never want just one ticket type because it will be false in the lead times it takes. Breaking down ticket types and understanding each of their lead times means we can then use this to have conversations with our customers about Service Level Expectations. We know that this also changes over time and so something that we need to continue to monitor.

A great chart to look at is your Lead Time Tracker/Histogram to understand the size of your work. Most tools will have something similar to this in the system. The below is an example taken from PowerBi.

When talking to our customers if we give them a forecast with a spread of variation of between 5-8 days to delivery, are they going to be happy? I think I probably would be within that range. Spread of variation is just a fancy pants way of saying the difference between your first data point and your last.

But if I was told the spread of variation was between 0-150 days..then we do have a problem here, and maybe not all tickets are created equal, and so I could see the need to keep them on the smaller size. So it is easy to see where this myth comes from.

But then my little grey brain cells start thinking.. What causes us to have such a massive spread? The chances are this is caused by delays, blockers, third parties, not handing over for holidays etc.

So before I start forcing people to create tickets the same size, I need to understand why they took that time in the first place and that is a great piece of analysis and I imagine you will get lots of improvements out of that conversation.

Next, I take a closer look at my Story Lead Time Tracker. Let’s take a look at the one I showed you earlier.

Do you see where I added the arrows there is a bump? Well, this tells me that I might still have different work items listed as stories. Multiple peaks are the thing that gives us a clue. So again we have to analyse and break out work items types out further if required. Turns out with this team we have some small, medium and large stories they do and so that is the reason for this.

Now let us address flow…What does that even really mean?!? For me, it means work in and work out at roughly the same rate, and doesn’t hang around in buffers, blocked or waiting for long periods of time.

You want good flow in your stories and this is what keeps the data closer to the left-hand side. But if you see the data edging out to the right. You want to again do that analysis and understand why.

Cadences in Kanban such as Delivery planning, Daily Kanban and the Flow Review are great at keeping an eye on work moving across the board. Consider implementing these to help you.

The final factor for me is ironically story splitting. Whilst we don’t talk about this as much as Scrum does there is a sensible rule of thumb here. You don’t want a ticket that says ‘Deliver me payment methods’ as this is super huge, but more deliver me credit cards, PayPal and gift vouchers. Think about the smaller chunks that will give you value.

So all these factors need to come into consideration for why your work is taking longer than expected to go through the system. The analysis of all of this really gets me motivated to find out those root causes. This is the thing we need to do!

Remember, if I told the teams to make stories all 5 days in size. What value would that give me or the customer? The team would just spend precious time gaming the system. The better approach is to keep them flowing and tackle those issues that make them take longer.

So don’t waste your time making them all the same size…analyse and set new team policies. Look at your spread of variation and if it is wild..you know you need to do something! Process improve your way to a 5-day lead time, rather than faking it.


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.


Expedites Are Bad For Your System!

I play the ‘Get Kanban’ game a lot as part of my Kanban System Design Class and it never ceases to amaze me how reactive people are to expedite a ticket for whatever reason. This is also reflective of what I see in real life. The team are busy working away and then a ticket comes crashing in and everyone stops to jump on this, and no one batters an eyelid. Do we not know how bad expedites are for your system?

Let’s start the beginning…

What Is An Expedite?

It is highly likely that you call them something else, but I suspect they already exist in your system. You might know them as major Incidents or P1s. Whatever the name, they are tickets that have such importance that they have to be done immediately. Maybe your website can no longer take payment or your customers cannot access the reports they need.

The Kanban University describes it as ‘An archetype of a class of service that is applied to work items where the impact of delay is both high and immediate’. You can find this description and many more in their glossary.

They also use this image to describe that impact of delay.

It was changed not so long ago from ‘Cost of Delay’ to ‘Impact of Delay’. The reason being that not every expedite is a monetary thing. Either way, it describes the impact of not fixing this thing is costly and now.

Our First Mistake – Not Having a Explicit Policy

Just because an expedite has come in, it doesn’t mean we have to do it! Do we ever consider the impact of the expedite vs the cost of delaying other work? No, we don’t! Any expedite that comes in, someone says ‘Jump’ and we all say ‘How high?

A good practice would be to have an explicit policy that describes the conditions in which it would be true that we complete this work. E.G

  • The loss of systems or functionality resulting in significant financial loss or usability
  • The problem impacts the companies reputation

This would be best aligned across the organisation and so everyone has that same understanding.

We would also want to set a policy about how many of these can we take in at any time. Ideally just 1!

But the point is, we need to have something to validate this urgency against. We also need to consider the impact of delaying work that is already in flight. plus.. we must have the autonomy to say ‘Not yet’.

Our Second Mistake – Not Knowing How Many Impact You

Is an expedite something that happens once every 6 months or do you get 10 a week?

In my last blog I talked about understanding the demand for work item types. We also want to look at the frequency you get them. This information will determine our response.

Another factor you can look at is the impact of having 10 a week on your lead time. The punchline is that everything takes longer…. also if you have 10 a week, are they really an expedite?

This image shows expedites across an organisation. So you can do at team and organisational level. This image is taken from Power BI.

Our Third Mistake – Not Knowing The Cause Of The Expedite

If we have established that we are a team that gets expedites frequently, we need to do some analysis. What is causing these issues and how can we stop them from happening again in the future. Sounds like a great opportunity for a retrospective. The causes could be either inside or outside of our own system. Either way it’s our problem and we might have to collaborate with other teams to solve.

Patterns To Manage Expedites

If you get expedites very infrequently you can probably set some policies and this will be enough. Validate it is a true expedite and accept that is going to extend the lead time on other pieces of work you are doing. This can be managed easily between the team and product.

But…. If you get many and we cannot reduce that number through process improvement, we have to have a strategy to manage.

I would:

  • Understand that I get X expedites per week and the 85% lead time for each of those is X days.
  • Schedule a regular expedite retrospective to understand root cause analysis and mitigation
  • Consider adding an expedite swim lane or use colours to make it very visible (Shown below)
  • Allow capacity allocation for expedites (shown below). Out of a WIP of 9 I am accounting for 2 expedites and 7 outcomes.

If I apply a capacity allocation for expedites it means when they come in, I do not have to stop other work. Therefore, not increasing other tickets lead times or impacting the teams roadmap commitment.

If no expedites are in the system, this does not mean that this time is wasted. I would pair with other people to increase the team skills and share knowledge, thus increasing staff liquidity. Then when the expedite comes in, you leave your pair, and no harm is done.

Knowing the team’s true capacity to work on outcomes is key for planning. So in this instance I can say the team does x tickets per week and can plan to that amount. But in reality if we are thinking about wider work item types you have to allow time for process improvement, unplanned work and walk up questions. So, you can see how work item types and knowing your demand and capacity is fundamental to managing your planning, flow of work, lead times and delivery rate.

Remember, whilst we now have a strategy to manage we have to keep challenging if these expedites need to be done, but also why they are happening in the first place.

What other strategies or advice do you have for managing expedites?