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?


Establishing Work Item Types

Understanding your demand and capability is a key part of Kanban, we can then use work-in-progress limits (WIP) to control the flow of work. But first, we truly have to understand the type of work our system is doing. Not all work is created equal! Not everything is a story, let alone the same size.

So we understand the different types of work the service does to enable us to analyse what type of work is getting done, how much is getting done, and how long that takes us. Service teams have many different priorities and it is important to keep the balance of all the different types.

So first we have to establish the type of work you do. The good news is you already have this information in your head or your online tool.

Once we have identified your work items, we want to align the meaning of these terms:

Work Item TypeDefinition
EpicBig User Story
StoryShort, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system (*taken from Mike Cohns website)
Escaped IssueA problem that has been identified in the live environment or with a customer
BugA problem that has been identified as the service team goes about their work
Technical DebtLess-than-optimal approach to speed up a piece of functionality or a project, which then later needs to be reworked.
SpikeA timeboxed investigation
SupportSupport from the wider business
ExpediteEmergency tickets that must be completed ASAP
Unplanned WorkWork that should have been planned, but slipped through the net
Examples only – You need to define these for yourselves

There might be more and that is fine. In some organisations I have worked at, we have aligned these across all service teams and not just one in isolation. This gives the benefit of everyone using the same terminology and you can see interesting trends across the data.

Most online tools will allow you to add your own work item types and so I would do an exercise to align the queue and the work that is in flight to these new definitions.

We need to allow work to be completed before we can start analysing the results. You need very little in reality, somewhere between 7-15 tickets to be completed.

Delivery Rate

Screenshots taken from Power BI, and other tools are available!

So the first thing we can look at is the delivery rate of work. Simply this means, how much of this work item type are we getting done. I would typically have a chart for each different type. From this you can now take action e.g do we have a quality issue or is there too much-unplanned work coming our way. If we can reduce the unplanned and spend less time on bugs, then the work you do on stories will increase.

Now we have this data, we can start being smart in terms of planning. If we have an 85% capacity of the service team for work, we can now shape the demand allocation and say 10% on tech debt, 10% on unplanned and so 65% available for stories. No team works on 100% stories and so why are we often naive and plan to do this? Don’t like the numbers you are spending not on stories, then what can we do to improve and shift the balance?

Things like unplanned work and expedites have a negative effect on the system as it distracts us. So maybe we need to introduce a WIP limit for expedites and an explicit policy to define what it means to be an expedite. If you are a team that gets hit by a lot of expedites, maybe you are a service support team, then at least we can understand the levels and plan accordingly.

The great thing about having data like this is that we can see the changes over time and the impacts of the process improvements you put in place.

Over time you might start to notice patterns in the demand. Maybe you get lots of requests at a certain point of the year. Knowing this means we can be prepared and ready.

How Long Work Takes

We can also start to build up a picture of how long each of these work items takes to get completed, the stability of that, and the trend. The chart below is from a service support team.

So I can see stories are being delivered with 85% confidence in 14 days or less. This has been reduced over the last three months because the team is taking action to break down work, better-manage dependencies, and limit their work in progress to really focus on getting work done.

This particular team can use these numbers to set service-level expectations (SLE) with their customers. Note, we would do this differently if you are working on a large outcome/project.

In this particular client, I have also noticed we effectively have small, medium, and large stories. The difference between small and large can be vast and so can impact the figures. So we now have a concept of an SLE for S, M, and L story work types.

It’s fair to say if you have Kanban systems to manage your portfolio boards, projects, features, and epics. We can also get the same information, just at a higher level.

Conclusion

By breaking into work items types we can start to use the data to understand and make decisions. We also take the feeling we are ‘not getting much done’ to something a bit more evidence-based. Naturally, the data is only as good as the input and so we have to improve that. But over time you will have nailed the process part and can really start to use your data to make decisions.

So maybe today is the day that you start thinking about your work item types?


Your First Day, Week or Month!

Happy New Year everyone and apologies for not blogging in such a long time. I don’t know about you, but I have no idea where 2018 went!  It seemed to speed past so quickly..

I have been busy with a relatively new client and was due to be there a couple of days the other week when ‘The Boss’ called up proclaiming  ‘man flu’, and wanted me to support him on his Certified ScrumMaster Class. Now, I don’t really buy into ‘man flu’ but he was a pitiful sight to behold, and so went along to do some of the heavy lifting. It’s been a good few months since I last trained Scrum, but it all came flooding back to me Smile  It was while there that I got the inspiration for this blog. I met a man who was literally starting as a ScrumMaster 9am the day after the course, and he wanted to know what needed to be done in his first few days and weeks.   So I reeled off a few things for him to consider and then wrote him a nice poster with all the details on to take away. 

Things to think about

I have not heard from him since the class, but I am hoping everything has worked out for him!

I thought other people might be interested in this and so here I am blogging about it.  I have taken the liberty to expand on some of the points. I was going to make a mind map, but all the ones I tried would not let you export an image for free Sad smile 

Stage 1 (First few days and weeks)

    • Meet the team and get to know them and what they want to achieve. Agree regular 121’s to keep the conversations flowing.
    • If the team is already up and running, spend some time observing.
    • Organise a team building event. Encourage team members to get involved in the organisation.
    • Has the Team used Scrum or Kanban before? Do they need to have some sort of training?
    • Meet the Product Owner. Get to know them, their history and what they want to achieve. Discuss both of your roles and what you expect from each other. Discuss what to do if you do not agree with each other.
    • Discuss the product with the Product Owner. Understand the Vision, roadmap, commitments, issues and risks.
    • Review the Product Backlog. If it does not exist, we need to help facilitate creating one. Do we need to complete user story mapping?
    • Set up regular sessions with the PO to keep collaborating. Encourage them to sit with the team.
    • Does the team sit together? If not organise this. Ensure that the team has either a TV or visual board.
    • Create an initial board to start putting work on. This can be refactored as you get the team up and running.
    • How does the team store information? If some form of wiki, SharePoint or other doesn’t exist. Think about creating one (after discussion with the team)
    • Facilitate getting a team Definition of Done.
    • Set up Sprint or Cadence structure in diaries. Plan for more refinement sessions if the team has to create the backlog from scratch.
    • Set up a holiday chart and make visible in the team space.

Stage 2 (Coming weeks and months)

    • Understand ‘other’ teams, people or third parties we might have dependencies with. Meet these people and agree ways of working.
    • Create a stakeholder map and plot all of the key people on. Plan how you can meet all of these people.
    • Understand Staff Liquidity. Implement knowledge share as needed.
    • If using Scrum, think about creating calibration stories for referring to in estimation sessions.
    • Set up team metrics (CFD, Burnup, Burndown, Lead time Distribution, Defect ratio, Waste, Work in progress, Net flow, Live status, Bugs, time to deploy, % automation, % fails of automation, build times, ticket age, throughput rates.
    • Consider if we need to create ‘End of sprint one page’ report for stakeholders.
    • Refactor the Board. Think about how to visualise: Blockers, Avatars, waiting, dependencies, issues and risks, different types of work, expedites, defects, WIP limits, capacity allocations, abandoned work, external teams collaborating with you (to name a few)
    • What engineering practices do we need to consider and implement? Understand what is done now and work with the team to define where we want to be.
    • Understand what the release process is, and the frequency of this. If people are involved outside of the team. Become their friend!
    • Understand current state of play for : Tooling, environments, levels of automation, CI/CD strategy, testing strategy, Source control, coding standards, online tool such as VSTS or JIRA.
    • Work with the Product Owner to create a Release Plan and any metrics they need to help manage flow of stories, value and delivery.

I am sure there are things missing and so feel free to leave comments for other people to get the benefit of your knowledge as well. I can then add them in for an AWESOME list!

I will try and not leave it as long next time.

To quote Jerry Springer ‘Look after yourself, and each other’

Helen

xxx


Guest Blog by Doug Idle: Awesome Aeronautical — Scaling Kanban with Lego!

I wanted to share with you a blog by my good friend Doug Idle. It is about a conference session that we created together for London Lean Kanban Days.  I was going to write a blog on this, but I thought his was already perfect. I am very pleased to share it with you. Enjoy x


I recently had the opportunity to attend a two-day course on Kanban (KMP2, for those in the know) taught by the fabulous Helen Meek (Accredited Kanban trainer and all-round Agile Coach). Knowing my love of all things Lego, Helen asked if I’d be interested in working together to find a way to demonstrate the scaling of Kanban and some of the KMP2 curriculum in 90 minutes rather than two days using bricks. We targeted presenting at the London Lean Kanban day in April.

We knew that we couldn’t teach the entire curriculum in 90 minutes (there’s a reason it’s a two-day course) so we decided to concentrate on six of the seven cadences in the session. We wouldn’t cover the Strategy review because it was just to big to fit in to the session and isn’t covered in KMP2 either. What we would cover would be:

  • The three delivery cadences — the daily standup, queue replenishment and delivery planning
  • The three improvement cadences — the operations review, service delivery review and risk review

… and we’d do it all with Lego!

We asked the group or 30 to self organise into teams. One member of each team would be the Service Delivery Manager who would be responsible for:

  • Facilitating key meetings
  • Supporting collaborative decision making
  • Sequencing and scheduling work
  • Helping the service understand its performance
  • Working to improve the overall service
  • Collecting data using the supplied lead time chart template

Each team would be responsible for constructing one part of a plane — either the fuselage, undercarriage, wing or tail. Each team was provided with the exact set of parts they needed to build all of their components, Lego style step-by-step instructions, a Kanban board and a set of laminated order cards.

After the teams had been setup and the SDM was ready to go, we kicked off by giving them a one-minute Daily Standup (the first cadence) and then building us one red, one blue and two black planes in four minutes. After the first run and a short retrospective we gave the teams their first opportunity to scale out by introducing dependencies between them. To reflect the dependencies, we gave them a new Kanban board to use.

At this point, we introduced the second cadence: Queue Replenishment. In this cadence, teams decide what to select from the pool of options. By moving work to the ‘Ready’ state they are making a commitment to complete it. Under normal circumstances, the meeting is no more than 30 minutes in length and would include key decision makers and stakeholders. Most teams will run a scheduled queue replenishment meeting — although on demand replenishment is desirable, it is often hard to coordinate. We gave our teams three minutes to run their queue replenishment and coordinate with each other.

After giving the teams another set of orders, we started them on their second run (a daily standup and some building) along with a retrospective afterwards. After the second iteration, it was time to introduce the third cadence — the Service Delivery Review. In this cadence, we look at whether or not we are delivering according to customer expectations. We look at a single Kanban system and include key people from each activity (dev, test, analysis etc.). The group compares current capabilities against fitness criteria metrics and seeks to balance demand and risk. The session is typically 30 minutes in length. After conducting a short Service Delivery Review, we asked the teams to scale out again — this time with all five teams forming a single service. On this occasion we didn’t provide a board since testing of the game had shown that the teams had outgrown anything other than a full scale whiteboard and we weren’t able to carry one around for the session.

During each scaling out session, we asked the teams to consider their policies, review their work in progress (WIP) limits, working together agreements and delivery lead times.

The Delivery Planning meeting was the fourth cadence we introduced. Here, we plan what can be delivered and form a commitment to our customers. Issues about delivery are raised in this session, solved and/or taken to the Risk Review cadence. Key attendees will include anyone who accepts the deliveries or is involved in the logistics of delivery. Specialists are present for their technical knowledge and risk-assessment capabilities. This is a decision making meeting and could be 1–2 hours. We conducted a five-minute delivery planning meeting where we asked the teams to estimate their percentage confidence in the third iteration orders we’d just given them.

For the third iteration, we introduced two new classes of service — a plane which had to be expedited and another which had to be completed by the end of the iteration as well as a fixed date plane, which had to be delivered by the end of the fourth iteration. Once more, the teams had five minutes to build the planes including a one-minute daily standup.

At this point, we introduced the fifth cadence, the Risk Review. In this, we look at problems that put our delivery capability at risk. Anyone with information, experience of recent blockers or managers from dependent services may be in attendance at this meeting. As a result of the session we may review the assigned Class of Service and/or explicit policies. Techniques such as blocker clustering can be used to analyse the work. Sessions can be 1–2 hours in duration.

We then kicked off the fourth and final iteration, asking the teams to build us 12 planes — four of each colour.

After the last iteration, we introduced the Operations Review. This is a ‘Systems of Systems’ level review and would be facilitated by a senior leadership team member. Here, we review the demand and capability for each system with a particular focus on dependencies. Improvement suggestions, actions, decisions or required changes to strategy with designated owners are the key outcomes of this meeting. The duration can vary depending on the number of services. With a large number of attendees, it could last up to two hours.

Although it is no substitute for the KMP2 course, the 90 minute session does give a really good look at six of the seven cadences, as well as giving attendees the opportunity to put them into practice.

After our successful outings at the Kanban Coaching Exchange and the London Lean Kanban Days, Helen and I are looking for opportunities to run the session again — so hit me us if you’re interested.

Doug Idle is a Senior Agile Delivery Manager. When he’s not delivering awesomeness he spends his time listening to Guns ’N’ Roses and rocking stages with his Velvet Revolver tribute band.


Kanban – Taking it back to the basics

Last week I was fortunate to go to Sapanca in Turkey with the Lean Kanban University (LKU) for the Train the Trainer (TTT) course. It was a little daunting to work with 7 other candidates that I didn’t know from all over the world; however we soon bonded as a community in a shared goal.

Class of Sapanca July 2013

classphoto (2)

It was great to finally meet David and some of his team who came with him (Mike, Dragos, Janice, Agnes and Mihaela) and to hear the journey they have been on with Kanban. The stories and learning they shared were extremely valuable and really helped me to understand how others across the globe had gone about their adoption and the roots of Kanban.

The course also highlighted that no matter how much we think we know as coaches, there is so much more out there to learn. Whilst it was a challenging week, I definitely believe I have grown in my Kanban knowledge and feel confident to co-train my first course next week. I am actually excited about the opportunity to share my knowledge and passion for Kanban as a newly Accredited Kanban Trainer (wooooo!)

Back to the Basics

I love the fact that Kanban (like other methods) has Values, Principles and Practices and this is something that I use and quote regularly to keep me true to what I am practicing. As practitioners & coaches we need to keep these close to our hearts and make them part of our everyday life.  You would not believe how many situations I find myself in day dreaming about flow optimisation. I can’t even go to Mc Donald’s now after Kanban Dan ruined it for me with his drive through flow scenario Smile

Lets take a minute to remind ourselves what they are:

The Values

  1. Understanding
  2. Agreement
  3. Respect
  4. Leadership
  5. Flow
  6. Customer Focus
  7. Transparency
  8. Balance
  9. Collaboration.

There is an awesome blog by Mike Burrows in this area.

The Principles

  1. Start with what you do now
  2. Agree to pursue incremental, evolutionary change
  3. Initially, respect current roles, responsibilities & job titles
  4. Encourage acts of leadership at all levels from individual contributor to senior management

The Core Practices

  1. Visualize
  2. Limit Work-in-Progress
  3. Manage Flow
  4. Make Policies Explicit
  5. Implement feedback Loops
  6. Improve Collaboratively (using safe to fail experiments)

I challenge you on your perceived knowledge of Kanban . There are so many misconceptions out there that it’s just about visual management, but it is so much more.  Kanban is an evolutionary method that uses scientific theory to enhance the flow of work in the system. There is also a misconception out there that Kanban can only be used in manufacturing, but this is not true. It can be used in software delivery, but also any knowledge work.

Kanban doesn’t imply that it is the end to end solution and recognizes that we pull from many different tool boxes in its application.

Part of the TTT course was based around the AKTs bringing case studies for how we have  implemented it in the organisations we work for and so I have not only experienced this first hand for myself, but seen other organisations deliver great results also.

Final Thoughts

What beliefs have you formed about Kanban or any method without really understanding what is at the heart of them.  We are often dismissive on little facts or one negative experience. Like learning to drive, maturity comes over time and with practice. Chances are that we may have a prang or maybe even a write off, but we still continue to drive and learn from the experience.

Consider getting yourself on a course and see how an AKT can open your mind.


Growing ScrumMasters for the Future

It’s been a pretty interesting couple of weeks with my adventures taking me to Kingston for a new client (note don’t get on slow train!), holding the Agile Coaching Exchange with Liz Keogh, and waving good bye to a client I have spent the last 15 months with.

For those that couldn’t make the exchange this month you missed Liz talking about complexity theory, and I have admit she managed what two others couldn’t do and that was to really help me to understand what Cynefin is. I think the breaking point was the inclusion of an exercise that made it seem real to me, and working in groups that helped to reconfirm the learning. I am not sure I am ready to write a blog about Cynefin yet, so I have included a few photos of the event and a link to Liz’s blog who covers it a whole lot better than I would. Thank you Liz!

highres_249766162600_249773612

Next week I am pretty excited to be attending the David Anderson Train the Trainer Class as part of the Lean Kanban University. It will be the first time I have met David and I am hoping to extend my knowledge further to really support driving good Kanban in organisations. It doesn’t hurt either that it’s in Turkey. I am sure I am going to have loads of good stuff to blog about on my return.

Photo of actual place of learning (wooooooooo!)

14

So my topic of the week is something that my colleague Mark Summers and I presented recently at both Scrum Gathering Las Vegas and XP2013 Vienna. It is also something that we both are very passionate about Growing ScrumMasters for the Future.

The challenge we faced was an organisation that was growing vastly in size and with an enormous intake of new ScrumMasters, who had a varied degree of experience and knowledge. We wanted to be able to support them in their knowledge and create a safe learning environment for them to put key skills into practice. From that point forward the ScrumMaster Education Programme was created.

Over the 6 month period that we ran the programme I put together an experience report of what we did and learned. I wanted to share with you that report so you can read and see the success that we had. Building this programme and watching our ScrumMasters grow was something that I took great enjoyment from and something that I am pretty proud of.

 

Click here for the ScrumMaster Education Programme Experience Report

Click here for the ScrumMaster Competency Framework

 

Even though I am leaving this client, I am happy in the knowledge that we have built a strong community of practice, and that they will continue to educate themselves without me. I have no doubt that we have been nurturing the Agile Coaches of the future.

Good bye guys, I am going to miss you all.

Final Thoughts

Learning is often something that gets pushed to one side when all hell breaks loose in the office. We practice Continuous Improvement in our teams, so why do we fail at doing this personally?

My mission for you is to learn something new this week.