I’ve just had an article published on Agile Journal about Kanban System Design in which I look at Kanban from a Systems Thinking perspective, and how various aspects of Kanban can provide leverage points to improve our product development outcomes.
The Lean Software and Systems Consortium US-based community conference will be May 3-6 next year, in Long Beach California. The Call for Papers and Registration are now open. The CfP Deadline is Dec 19th and will not be extended.
May 3rd is LeanSSC Technical Advisory Board meeting and pre-conference tutorials. If you intend to attend those you should plan on arriving in Long Beach on May 2nd. The full conference starts on May 4th.
The Lean Software and Systems Conference is the Kanban conference for North and South America in 2011. This is where the community gathers and is where you will get the first chance to see and hear the best new material.
We will also be awarding the Brickell Key Award for outstanding achievement, leadership and community contribution for the 2nd year. A Call for Nominations will be made within the next week. Please consider who you’d like to nominate for the award. Last year’s worthy winners were David Joyce and Alisson Vale. This year they, together with David Anderson, Alan Shalloway, Donald Reinertsen and I, make up the selection committee. The Award banquet will be held on Thursday May 5th in Long Beach. Be sure to select the banquet as part of your registration if you would like to be part of ceremony and festivities.
I was invited to the Scrum Gathering in Amsterdam this week to give a Deep Dive on Kanban. My Kanban Exploration slides can be downloaded from slideshare. Inspired by an email discussion with Jean Tabaka and Eric Willeke, to introduce the session, and to try and reinforce the concepts of Flow, Value and Capability, I tried a variation of the Ball Point Game that is commonly used in Scrum training.
Here’s a couple of links (Kane Mar) (Declan Whelan) if you’re not familiar with the game. In a nutshell it involves a group working as a team to pass balls between themselves, constrained by some rules. The idea is to pass as many balls in a 2 minute time box. The team has to self organise and inspect and adapt in order to improve its velocity (throughput of balls).
For my variation I wanted to remove the time-box to emphasise flow more, and demonstrate a different way of understanding the capability of a system. In the game, the team are designing a system to meet the purpose of flowing balls quickly between themselves.
The changes I made were to ask the team to pass 20 balls as quickly as possible. I put a unique number (1 – 20) on each ball in case it was useful and also asked the team to time how long it took for each ball to pass through the system. I took the data that was captured and entered it into a spreadsheet to create a control chart. We ran two rounds of the game twice, with the respective charts below.
In Round 1, the team didn’t capture all the data, and some problems were had towards the end, but that the average time for each ball was 13 seconds. The system could also be said to be ‘in control’ as all the data points were with the control limits which were calculated as AVERAGE +/- (3 * STDEV). The last measured ball was completed at 3 minutes and 35 seconds.
In round 2, the team improved their data capture process and overall flow. The average time per ball dropped to 12 seconds and the variability also reduced. The Upper Control Limit dropped from 01:10 to 00:18. The last measured ball was completed at 2 minutes and 22 seconds.
What this demonstrates is that even with variability (which we don’t want to eliminate completely in software product development), by understanding the capability of the system over time, we are able to reliably communicate what might and might not be possible. For example, using the round 2 data, there is a 50% chance we’ll complete a ball in 12 seconds and a 99% chance we’ll complete a ball in 18 seconds.
We could also calculate and chart the throughput of balls completed over a cadence of 30 seconds to similarly understand the capability from that perspective also. For Round 2 those throughputs would have been 3, 4, 4, 5, 4.
There are a few areas I’d change next time I try this.
- The measurement took a long time and was clearly the significant bottleneck. I made measurement part of the system to add some additional complexity, but in hindsight it was probably too much. Most of the improvements were in measuring the system rather than the performance of the system.
- I allowed more time than I probably should have for improvement discussions. With the time-boxed version its easier to start the clock for a round and that usually that kicks the team into action. Similarly, when the measurement fell apart we stopped and restarted a couple of times. I wouldn’t do that next time, although by removing measurement from the system, it might be less of a problem.
- It took time to enter the data into the spreadsheet. I need to find a better way! The spreadsheet can be found here. It’s very simplistic. Please let me know if you use it and improve it!
This post is a high level overview of the model I use when I think about Kanban Systems. As the saying goes, “all models are wrong, some are useful”. This is what I currently find useful based on working with teams and organisations in recent years.
At the heart of the model is Systems Thinking. Without looking at what we do as part of a system, with a purpose to be met by outcomes, we risk focusing too heavily on the activities and practices we perform. Having a clear understanding of a systems purpose, from a customers perspective, helps us to design a method which serves that purpose.
The model then has three foundational building blocks which underpin an effective process; Flow, Value and Capability.
- Flow – Keeping the work progressing and avoiding delays by focusing more on the movement of the work, and less on the movement of the worker.
- Value – Ensuring that the work serves the system’s purpose, satisfying customers and stakeholders and resulting in successful organisations.
- Capability – Creating knowledge of how well the work serves the system’s purpose in order to maintain and improve the system’s effectiveness over time.
In other words, we want to flow value through capability teams.
Finally, the model has five aspects, from which we can look at a process to help us understand and improve it; Workflow, Visualisation, Work in Process, Cadence and Learning.
- Workflow – how does the work progress through the system? Understanding workflow helps improve how the work moves from concept to consumption.
- Visualisation – where is the work in the system? Understanding visualisation helps create a common mental model of the current state of the work.
- Work in Process – what work is in the system? Understanding Work In Process helps identify bottlenecks and impediments to improving flow.
- Cadence – when does the work in the system happen? Understanding Cadence helps with co-coordinating the work and improving system reliability.
- Learning – how does the system continuously improve? Understanding further models with which to view and explore the system ensures the system gets better at serving its purpose.
While this is only a model, and contains no specific practices, I believe that it can be useful in describing why some techniques work in some circumstances, and provide context for applying the right tool to the right job.
At Agile2010 I was chatting with George Dinwiddie about general process related stuff (probably with some reference to Kanban!) and I mentioned an idea I had submitted to a couple of conferences which had never got accepted. George suggested we try it as a Open Jam session, so we did!
The idea is to run a root cause analysis of various agile practices to drill down into why they work and what the benefits to be realised are. So rather than using a 5 whys approach to solve problems, it is used to understand solutions. For example, why do unit test? To minimise defects? Why do we want to minimise defects? To create less rework? Why do we want less rework? etc. The session tied in nicely with another Open Jam run by David Hussman on Dude’s Law, which also emphasised focusing on why rather than how.
Here are the outputs from the 3 practices we picked; Unit Testing, Iterations (Time Boxes) and Limiting WIP. Click to view the album with bigger pictures.
As a general exercise, I found it really useful and interesting. Definitely something to try submitting to future conferences again. The discussion and debate we had, and the surprising tangents we went on, was rewarding and enlightening. I was particularly fascinated by the comparison between Time Boxing and Limiting WIP and the way that creativity came out in both of them through different paths. I hope that by understanding why practice work in more detail, we can avoid following them dogmatically, and be in a better position to solve problems based on context. When a particular practice is not suitable we can draw on other practices which can provide the same benefits.
This is definitely something I want to explore further – hopefully with workshops at future conferences. If you try it out as well, blog your outputs and let me know!
I ran a workshop on “Exploring the Kanban Universe” at Agile2010 with Xavier Quesada Allue. The premise was to setup an example case study and lead participants through visualising different aspects of a project – the different multiverses – over a number of iterations. Below are pictures of the final boards from the different teams. We encouraged people to think ‘outside the box’ and try and move away from traditional rows and columns approaches.
The highlight for me was the circular design that one of the teams came up with. I thought it was a great solution to the challenge of avoiding kanban boards appearing to show a linear process. With a circular design, a work item can loop round the circle multiple times, with the distance from the centre indicating closeness to completion, and different quadrants indicating the primary focus of work such as analysis, dev, test etc. This was the nicest example of a board as a ‘map’ as opposed to a ‘relational’ representation.
One thing that was reinforced for me was that a Kanban Board should not try to visualise absolutely everything. Its should have just enough information to signal where the issues are, and where the team should look to find out more. In other words it should be able to “point to the gemba”. Thanks to Harada Kiro to reminding me of this after the session. In future runs of the workshop we’d like to try starting with a blank canvas each iteration to avoid teams feeling constrained by trying to show too much and having to build upon previous designs.
I also gave a talk on the subject at the Lean & Kanban Conference in Belgium last week after which Mary Poppendieck pointed out that I’d slipped into referring to some visual management designs as kanban boards when they strictly weren’t because they didn’t limit WIP. Visual Management is a large part of a Kanban System, but not every Visual Management board is a Kanban board.
Tickets for LESS2010 are selling well, but we’d really like it to be a sell out. If you’re not already coming, please take a look, sign up and bring your friends and colleagues!
The website is http://less2010.leanssc.org/ and the full program and details are now available at http://less2010.leanssc.org/program/. There is also an executive day if you know anyone who you think would be interested in that. http://less2010.leanssc.org/program/executives/. If you book a group of 5 or more, we can also offer a discounted rate – let me know if you’re interested in that option.
We have a couple of flyers for helping with promotion:
If I were to pick 3 main reasons for attending the conference, they would be:
- The Beyond Budgeting track and links with that community
- The Academic content and links with that community
- The great line-up of speakers 🙂
I hope I see you there!
At Agile2010, as at Agile2009, I went along to help the volunteer bag packing, and use it as an exercise in experimenting with Lean and Kanban ideas. Once again it was a huge success. We completed packing all the bags in (anecdotally) record time, and had great fun in the process.
The video above was put together by Luiz Parzianello and really gives a sense of the energy and enjoyment everyone had. You can also see the “Y” shaped line we put in place and how people moved around and self-organised to keep the materials flowing.
Below are the outputs of the team retrospective, but first, here are my highlights and overall impressions.
- Even though bag packing is not software development, there was still creativity on the way we solved the problem.
- Being able to design a successful process in context, whatever the nature of the work, is an important skill.
- Even with relatively repetitive work, people are motivated when they are involved in designing the work.
- Clear visibility of bottlenecks (by limiting work in progress) enabled people to move around to keep the flow of material.
- Measuring throughput in bags per minute (but not setting targets) was a motivator and a predictor of when we would finish.
- Given the right space, it would be perfectly feasible to pack bags on-demand during registration without needing to pack them up front.
Here are the retrospective notes:
What Worked – Do Again
- 1 person floating around all stations (extra capacity)
- Y Config
- Everyone really trying to help
- Continuity of event planning – better every year – Elastic
- WIP limits – 4 stacks backlog meant stop & wait
- 18 people in am / 15 people in pm
- People taking metrics – live, visible metrics – without warning
- Paper picking – each one goes under prev
- Largest on bottom
- Table splits
- Everything organised & stacked with one example on table of each item
- Handing a stack directly to a person instead of putting on table
- Continuity & ownership between am/pm – (better)
- People got to be creative & solve problems
- Stacking by size
- Arrange table so no one had to walk
- Video taping!!!
What Did Not Work – Do Better
- Tables too short, materials too low
- Bad sizing on poster
- Folders came flat, needed to fold
- Sticker falling out of flyer
- Bags less than ideal – keeping open – cut hands
- Started later, slow beginning
- Still found missing items
- List still was not accurate, items hard to match
- Process for matching items to list not efficient
- Did not have all the bags
- Table with small things moved too fast
- Slowing down to obey WIP made it hard to speed up
What To Do Differently – Try
- Packing on the vendor room – closer to end point
- Planning on process over email before hand
- Someone owns planning process early
- Something to hold bags by handle and open like a rod
- Big visible labels on boxes – even big colour stickies
- Do prework on Saturday
- Insert kanban tokens into inventory so when a signal is found in stack, then supplies can be identified.
I’ve noticed a pattern that I’ve found myself using recently when I’ve worked with new teams that makes use of both Scrum and Kanban ideas. I’ve already said that I believe the two are complimentary, and this should help show how.
- I’ll often begin with a “Canonical Scrum” implementation. This gives a relatively simple introduction due to the ubiquitous language, standard training and often client demand. I also find that its a very good way of quickly exposing the real underlying workflow. Stressing a team by introducing a new way of working soon makes the current way of working apparent.
- After a few Sprints,once the team understands both what the desired outcome is and the current context is, I’ll ease back into what many people might call “ScrumBut”. Rather than continuing to highlight and struggle against impediments and constraints which are out of the teams control, I will apply kanban aspects to help the team acknowledge, but deal with their context without feeling dogmatic.
- Finally I’ll help both the team and the organisation improve, by seeing where the issues are, whilst continuing to be able to deliver. Sometimes the current workflow is appropriate for the team and it is smaller batches and queues that are needed. Sometimes the current workflow is a symptom of silos and poor collaboration.
So I find Scrum to be a good way of showing teams what could be possible, and finding out where I can help make improvements. Then I find Kanban a good way of enabling a smoother transition for those improvements in a way which is appropriate for the teams’ contexts.
I have a few announcements so I thought I’d group them together into a single post.
- Firstly, I’m really excited that I’m going to be joining the Rally team in the UK. I’ve had a good couple of years with Conchango / EMC Consulting, but its time to move on, and I believe Rally are doing some great things in the Lean and Kanban space, especially with the recent acquisition of AgileZen. I’m really looking forward to working with Ryan Martens, Jean Tabaka and the rest of the Agile Coaching team.
- Next, I’m going to be at Agile2010 and will be running a workshop Exploring the Kanban Multiverse with Xavier Quesada Allue. Its an evolution of Xavier’s Visual Management workshop from last year’s conference, with some updates that have been used at XP Day London and the Orlando Scrum Gathering. I’m also going to helping out with the bag packing on the Sunday before the conference. This is a repeat of something we did last year where we applied Lean and Kanban thinking to bag packing process and learned a load and had lots of fun in the process. If you’re around the hotel, come and find us and join in!
- Finally, the LeanSSC 2010 UK conference was a success and the materials and videos can be found on the Limited WIP Society.