Kanban Thinking and the Kanban Method

When I first coined the term Kanban Thinking for the model of how I approach working with teams and organisations, I described how I wanted to encourage more definitions of kanban to lead to less dogma about what it is or isn’t. That’s still the case, but there is always the risk that multiple definitions leads to competition and a scarcity mindset. One of my favourite mantras is “feed the soil, not the plants”, and I prefer a mindset of abundance, so in this post I want  to map Kanban Thinking to the Kanban Method, with a goal of showing the relationship between the two, and how they are complementary rather than alternatives.

Here’s a recap of the elements of Kanban Thinking:

  • Systemic Thinking
  • Impacts
    • Flow
    • Value
    • Potential
  • Interventions
    • Study the Context
    • Share the Understanding
    • Stabilise the Work
    • Sense the Capability
    • Search the Landscape

(Eagle-eyed readers might notice that I have updated some of the language again – I need to blog about this soon!)

How do the elements of the Kanban Method relate to this? Note that this is a very simplistic  mapping – there are richer nuances which would come across is a deeper comparison.  I have included the recent Kanban agendas as part of the Kanban Method.

Agendas

The agendas relate primarily to the Kanban Thinking Impacts:

Sustainability primarily relates to Flow, in that an efficient and reliable process reduces the burden on people. Equally, it can also relate to Potential for the same reasons as Survivability (see below).

Service-Orientation relates to Value, in that an effective and valid product is the result of providing a good service.

Survivability relates to Potential in that an organisation with euphoric people who can be adaptable is more likely to have a longer lifespan.

Principles

Start with what you do now relates to Study the Context in order to get knowledge about where you are starting.

Agree to pursue incremental, evolutionary change relates Search the Landscape by running small, recoverable experiments on potential improvements.

Respect the current process, roles, responsibilities and titles also relates to Study the Context to understand all those aspects of the initial starting point.

Leadership at all levels has no direct relationship to Kanban Thinking. Tenuously it could relate to an impact on Potential in that having leadership at all levels should lead to greater future sucess.

Practices

Visualise relates to Share the Understanding which is the underlying intent of visualisation.

Limit WIP relates to Stabilise the Work by containing the amount of work in the system to balance demand with capability.

Manage Flow relates to Sense the Capability in terms of flow, and therefore also making an impact on Flow.

Make policies explicit also relates Stabilise the Work by creating clear standards of quality as a baseline for improvement.

Implement feedback loops relates to Sense the Capability by creating the mechanism through which performance can be understood.

Improve collaboratively, evolve experimentally (using models & the scientific method) relates to Search the Landscape by running small, recoverable experiments on potential improvements.

Kanban Thinking and Kenban Method

What does this tell us?

The key take away should be that there is a close mapping between the two and, and while there are some slight differences in emphasis, they are extremely compatible as mutual approaches. There is certainly no competition or need to choose one over the other! While we could start getting into some form of SWOT analysis of each, I’m not sure that would be worth the effort.

However, it is worth understanding how can they can be distinguished in a way that highlights how they are different and yet complementary. One of the things that is motivating this for me is to be able to put together a “Kanban Thinking” course/offering which would be appealing to anyone who’s been on an LKU approved Kanban Method training.

This is what I’ve come up with:

  • The Kanban Method is an approach to delivering service-oriented knowledge work in a sustainable and survivable way.
  • Kanban Thinking is a model with which to design and evolve a system which can implement the Kanban Method.

So in summary:

  • Kanban Thinking is a model which can be used implement the Kanban Method.
  • Equally, the Kanban Method can be implemented without using Kanban Thinking.
  • And Kanban Thinking can be used to create a kanban system without using the Kanban Method.
VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Kanban Thinking: The Canvas

Kanban CanvasLast week, at SparkConf, I announced a new website for Kanban Thinking, which is where I will add new material in a more structured way (I’ll continue to blog ideas here in an un-structured way!). The primary new piece is what I’m calling a Kanban Canvas – a sheet designed to be printed on A0 paper and used to collaboratively explore the model when designing a kanban system.

The canvas is built around the heuristics and related questions, with the goal being to co-create a design by exploring and answering the questions. You can see some more on this in the SparkConf slides below. Please visit the new site, download the canvas, and let me know your experiences.

And of course, let me know if you would like me to help facilitate your work!

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Kanban Thinking Questions

Question MarkQuestions

Kanban Thinking emerged from a realisation that “best practices” are not universal, and that sometimes, continuing to try harder, do better and have more discipline isn’t the right thing to do when those practices are not appropriate. As a result, the challenge became one of how to help people learn and discover their own solutions to the challenges they face when pre-packaged solutions don’t work. The result, Kanban Thinking, is a mental model that guides my thinking, and gives me a framework with which to ask questions when designing kanban systems. This post describes Kanban Thinking in terms of some basic questions.

The System

The starting point is to understand why we are designing a kanban system.

  • What systemic problem, difficulty or frustration are we trying to address?

Impacts

Next we consider how we will know whether the kanban system is doing its job.

Flow

Improving the progress of the work might be a positive impact.

  • How would investing in our process, its efficiency and reliability make a difference?

Value

Improving the product of the work might be a positive impact.

  • How would investing in our product, its effectiveness and validity make a difference?

Potential

Improving the sustainability of the work might be a positive impact.

  • How would investing in our people, their euphoria and humanity make a difference?

Heuristics

Then we evaluate what interventions we might make to begin evolving the kanban system.

Study

Studying the context allows a better understanding of the current situation.

  • What could be done to learn more about customer and stakeholder needs, the resultant demand, and how that demand is processed?

Share

Sharing the knowledge gives everyone a common understanding of the situation.

  • What information is important to share, and how can tokens, the inscriptions on them, and their placements, provide a single visual model?

Contain

Containing the work, with loose constraints, creates a stable, yet supple system.

  • What policies could help limit work in process, and remove unnecessary or unexpected delays or rework?

Sense

Sensing the current capability provides understanding of how well the system is performing.

  • What measures and meetings might create insights and guide decisions on the interventions required to have the desired impact?

Explore

Exploring possible interventions leads to discovery of the evolutionary potential of the system.

  • What small experiments could be run to safely learn the impact of different interventions?

Answers

There are not necessarily any right or wrong answers to these questions. The intent is that they should lead to dialogue and conversations, which themselves lead to awareness and ideas for how to go about change and improvement.

How do these questions help you? Let me know!

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)

Estimates as Sensors

Note: this is not an April Fool – honest!

I’ve been watching the #NoEstimates conversations with interest and decided its about time to pitch in with my own perspective. I don’t want to take any ‘side’ because like most things, the answer is not black or white. Estimates can be used for both good and evil. For me they are useful as a sensing mechanism. Put another way, by estimating, I can get a sense of how well I know my actual capability.

Lets take an example. I’m taking part in a 10K run this Sunday (*) and I am estimating that I will complete the distance in 55 minutes. This is based on an understanding of my capability from participating in regular 5K runs, and more general training runs over a 10K distance. I’ve never run an official 10K race, let alone this course, and I don’t know what the conditions will be like, but I’m aiming for 55 minutes. If I run quicker and do better than my estimate, then my actual 10K capability is better than I thought. If I run slower and do worse than my estimate, then my actual 10K capability is worse than I thought. Either way,  I will learn something about how well I know my 10K capability.

What helps even more with that learning is regular feedback! I use MayMyRun on my phone to track  progress and give me feedback every kilometre for total time, average pace and last split. This could be considered a distance-based cadence. I could probably also use a time-based cadence to give me equivalent feedback every few minutes. This feedback on a regular cadence helps me decided whether my estimate was way off, or if I should slow down because my pace is probably unsustainable, or speed up because I feel I can push harder.

How does this relate to product development? Well, we can use estimates in the same way to get a sense of a teams delivery capability, and use regular feedback to learn whether we’re making the progress we thought, and need to re-plan, slow down or speed up. Time-boxing, with Story Point estimates and Velocity can provide this time-based cadence and feedback. Alternatively, how long it takes to complete 10 User Stories can be used as a distance-based cadence and feedback.

To sum up, I recommend using estimates to sense capability and create feedback for yourself. I don’t recommend using them to make promises and give guarantees to others. Or maybe we could just call them sensors instead of estimates?

(*) Of course this post is primarily an excuse to invite readers to sponsor me. If you’re so inclined, or would like to show support for this post in a charitable and financial way, then please head over to my JustGiving page and do so there 🙂

Update: My final time was 49:23 based on the timing chip, or 49:30 from the starting gun. I’ve learned that I’m better than I thought I was, and next time I’ll be estimating 50 minutes!

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

The BBC Seeds Of Kanban Thinking

BAFTA

Back in 2002 I wrote an Experience Report for the XP/Agile Universe conference in Chicago – one of the precursors to the current Agile Alliance “Agile 200X” series. The title was “Agile Planning with a Multi-customer, Multi-project, Multi-discipline Team” and the abstract was as follows:

Most XP literature refers to teams which work on a single project, over a number of months, for a single customer using a narrow range of technical disciplines.  This paper describes the agile planning techniques used by a team which works on multiple projects, for multiple customers, using a wide range of multiple disciplines.  The techniques described were inspired by the agile practices of XP and Scrum.  A small case study of a project shows how the team is able to collaborate with their customers to deliver maximum value under tight conditions.

I often reflect back on those early years of my Agile journey with my team at the BBC Interactive TV department. We had some great successes (including winning the BAFTA pictured here for the Red Button Wimbledon Multistream service in 2001), and many of the things we did back then have shaped the way I approach my work as a coach now. In particular, and admittedly only with hindsight, I can see the first seeds of Kanban Thinking even though I didn’t have the knowledge to understand that yet. This post will try to map that out in some more detail – it will make a lot more sense if you have read the original paper!

Studying the Context

We did a very crude form of demand analysis in a couple of ways. Firstly, we realised that we worked on “a large number of very short projects, typically of a couple of weeks in length”. Thus we evolved to what  we would now call a Service Oriented Approach  to delivery by treating “all projects as a single ongoing project”. Secondly, we recognised that we had a variety of different response profiles for projects – what we would now probably call Classes of Service. In particular, there were those with “immovable delivery dates, such as a major sporting event like Wimbledon” and others with “unknown delivery dates, due to the nature of channel scheduling”. These unknown dates could be sprung on us at very short notice. In addition, something not mentioned in the paper is that roughly every quarter, one new service would be identified as one which we try to do something different and use as an investment in innovation.

While we didn’t make it as explicit as I now would, we did have a simple value stream, both up-stream and down-stream of the development team’s work. The upstream work happened as each project approached its planned build time and it was broken down into stories and estimated. The downstream work happened during extensive exploratory testing on each set-top-box, especially for Satellite services which required independent testing by the platform operator Sky.

Finally we understood that the specialist skills and disciplines within the team meant that we had an availability constraint for certain types of work. As well as using various practices to minimise the impact of this, we also ensured that we planned with this in mind, being very cognisant about which projects required which types of work so that we could balance the work accordingly, or allow for the fact that a particular area might be intentionally overloaded.

Sharing the Understanding

The fact that in the report only I only gave a passing mention to the fact that story cards were also “put up on the wall to highlight the current work, and to provide a  focus for regular stand-up meetings” says a lot about how much we have learned about the importance of visual management in the last 10 years. We used a very simple form of visualisation by hanging a sheet of plastic photograph holders on the wall. The sheet had a number of wallet slots into which photos were designed to slide, and which conveniently, index cards also slid into. Thus we displayed the weeks cards, and clearly marked them as they were completed so we could easily see progress during the week. This card-wall provided the focus for the week and as I recall, it helped us to talk about the progress work more clearly.

The Excel spreadsheet also provided a simple visualisation of the longer-term plan, and this we posted next to the card-wall. While we only printed it in A4 size, it would easily have scaled to be a form of A3, providing a clear picture of what the current thinking was for the next few months on a single sheet of paper. In addition the ‘provisional’ line gave a very crude indication of the value stream in that projects ‘above’ the provisional line were ones that we had fleshed out into stories with estimates. I have a vague recollection that we also added some form of visualisation of what work was in testing or ready for broadcast, but I don’t recall the details unfortunately. The use of colours on the spreadsheet was simply to help see the size and ‘shape’ of each projects. That is, how many weeks, and how many streams it was planned on taking. I used to think of this as “Tetris Planning”

Containing the Work

The Excel spreadsheet streams provided a very basic form of WIP limit in that it ensured that we never worked on more than three project-platforms at the same time. On other words, if we worked on 3 different projects, each would only be for a single platform (Satellite, Terrestrial or Cable). Generally, however, we would work on a single project across all three platforms, where each platform would be considered a single stream of work. In addition there was also often back-end content generation work, which would also take up a stream.

This way of containing the work could also be described as a form of investment allocation, although we didn’t measure the specific allocations precisely. The simple visualisation did give us a means of roughly seeing how much time (in weeks per stream) we were investing in each platform.

At the team and story level, the card slots described above also provided a very crude way of limiting WIP. Because the plastic sheet only had a finite number of slots we soon learned that once the sheet was full, then we had a strong indication that we had enough work for the week.

Sensing the Capability

The main metric we used was velocity as that was the most documented Agile metric at the time. However, we realised that by measuring velocity over a weekly cadence there was always going to be unavoidable variability. At the time we used a moving average, although I’d love to be able to go back and use other techniques to understand that data such as statistical process control and percentile coverage. I also wish we had better data on the number of stories completed each week. The estimations were very coarse-grained, and we were pretty close to using #noestimates, although without the more sophisticated analysis and forecasting that is around today. It would also have been incredibly valuable to have known about other metrics, in particular the various qualified lead times of the stories flowing through the process.

The two key cadences that we used were the weekly and quarterly ones. The weekly cadence was effectively a review and queue replenishment one, where we looked back on our progress the previous week, and re-planned the stories for the coming week. The quarterly cadence was more of a steering cadence, where we updated the Excel plan with our best guess at what projects would be coming next and what the key dates would be.

Exploring the Potential

This time period at the BBC was one of constant exploration, and it was this aspect, of breaking the “rules” and trying things out, that I probably learned the most from. I didn’t have all the knowledge of the all the models and theoretical underpinnings that I have now, so much of the exploration was intuitive rather than with scientific discipline, but it certainly encouraged me to always try things out for myself, and not just stick to what I had read or heard somewhere.

 

VN:F [1.9.22_1171]
Rating: 5.0/5 (3 votes cast)

To Method, Or Not To Method, That Is The Question

This post is a result of pondering on a couple of well know quotes in the Lean and Kanban communities, and the relationship, and potential paradox, between the two of them.

The first is from W. Edwards Deming:

By what method?

The second is from Taichi Ohno:

Do not codify method.

What’s going on here? Is ‘method’ something these two giants disagreed on? I don’t think so.

By What Method?

Deming would ask this in response to suggestions regarding improvement. His point was that “best effort” alone will not result in better performance. Simply continuing to do the same things, in the same ways, and just trying harder, or concentrating more, will not make any lasting difference. Instead, we need to acquire knowledge about the current situation, and use that knowledge to discover how change what we do and the way that we do it. The question “by what method?” is a call for intentional changes to the system as opposed to assuming the problem is with the people. Deming’s Red Bead Experiment was designed with this as one of the learning objectives. It includes no method for reducing the number of red beads other than extrinsic motivation, and it demonstrates that the outcomes of the exercise are only a result of the system.

Do Not Codify Method

Ohno is reported to have said this in response to people wanting to be given a prescriptive answer to a problem. His points was that once a method is codified, then people will blindly follow it regardless of suitability. Instead, he advocated for people thinking for themselves, in their own context, and coming up with their own solutions. While the only reference to Ohno actually using this phrase that I can find is from John Seddon and Vanguard (who ironically have codified their approach as the Vanguard Method!), I’m assuming its true for the purpose of this post. Please ket me know if you have a good reference confirming the quote (or otherwise).

Method or No Method?

What is interesting is that the Ohno quote is not “Do not have a method”, just not to codify it. In fact Ohno also said:

Where there is no standard there is no kaizen.

Thus there is no paradox. Both Deming and Ohno were suggesting that we should have a method to intentional improve. And that as we improve we should adapt and evolve that method rather than it becoming a static artefact.

This is why I like to put the emphasis on thinking in Kanban Thinking, and why I prefer to refer to it as a thinking model rather than a method. I’m not saying that all methods are inherently bad. XP, Scrum, SAFe,the Kanban Method and the Vanguard Method have all proved to be useful ideas in helping myself, my customers, and others to get better results. Its just that they all come with the risk of being taken as a prescriptive, and followed blindly. And I’m sure Kanban Thinking has the same risk. However, this risk could also be considered to be their kryptonite. In the same way that without kryptonite, Superman would not be powerful, without this risk, the methods would not be powerful. (Thanks to Seth Godin for this metaphor in The Icarus Deception)

So my takeaway is to have a method, but make it your own method. If you are going to use XP, Scrum, SAFe,  the Kanban Method ot te Vanguard Method, use them as pools of knowledge and ideas from which to pull and help you design your own method. Don’t just follow them blindly.

 

VN:F [1.9.22_1171]
Rating: 3.0/5 (1 vote cast)

Agile.FM Podcast: Agile Day NYC and Kanban Thinking

Podcast in Retro

Photo Credit: themaccraic-david

I recently met up with Joe Krebs in London and recorded a podcast with him. Joe is organising the Agile Day NYC conference which I will be speaking at in September (straight after RallyON). As well as the conference, we talked about Kanban Thinking, the subject of my talk there, and the Lean Systems Society Reactor Conference, which is also coming up in September.

Listen to the podcast, and hopefully I’ll see you at one of the event next month.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Thoughts on Kanban Thinking

Some thoughts on what I have been referring to as Kanban Thinking

Why create an other brand?

I’m in the camp that believes we need to create more brands, rather than reduce everything down to “common sense” or “good practice”. To paraphrase Alistair Cockburn, every successful team should create its own branded processes to describe the context and the solution.

Why another “Kanban” brand?

By using the name Kanban, I am acknowledging the roots of my current approach in hearing David Anderson talk about Kanban at Agile2007 in Washington DC. I consider that to be as important a turning point in my career as when I first read about Extreme Programming in 1999. Further, my response to calls to provide a single, clearer definition of Kanban for software development, is to encourage more definitions of Kanban. The more definitions there are, the less dogma there will be, and the more people will have to think for themselves about what Kanban means to them.

Why the “Thinking”?

As I mentioned when I blogged about Agile Thinking at the start of the year, thinking should be a core part of what we do. Alongside Lean Thinking, A3 Thinking, Systems Thinking, Complexity Complexity Thinking and Design Thinking, I want to make this explicit. Emphasising the thinking is also intended to make it clear that action is also required to succeed. Kanban Thinking is not a silver bullet as the right action is needed for each context.

What is Kanban Thinking?

Kanban Thinking is systemic. It takes a mindset of optimising the whole system, whatever the boundaries of that system are defined to be. Part of the thinking is deciding what those boundaries are. They do not naturally exist but are created by us to help frame a context.

Kanban Thinking strives to achieve flow, deliver value and build capability.

  • To achieve flow is to have smooth, regular and frequent progress of work. Kanban Thinking looks to eliminate delays rather than eliminate waste.
  • To deliver value is to focus on doing the right thing in order to delight the customer (and other stakeholders). Kanban Thinking looks to maximise value rather than minimise cost.
  • To build capability is to develop people and knowledge as a foundation for business success. Kanban Thinking looks to develop people as problem solvers rather than their tools to solve problems.

Kanban Thinking involves studying, sharing, limiting, sensing and learning.

  • Studying the current system helps understanding of the existing context.
  • Sharing the understanding gives everyone knowledge about what is happening.
  • Putting limits in place bounds the system to help stabilise it.
  • Sensing how the system is performing gives an understanding of current capability.
  • Learning from the systems performance allows for capability to be continually improved.
VN:F [1.9.22_1171]
Rating: 4.9/5 (10 votes cast)