Archives: May 21, 2024

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?