Does A Kanban System Eschew Estimation?

I was recently involved in a brief twitter conversation which started when Mike Sutton tweeted:

estimation is not about the number that pops out. It is about exploring effort and discovering that you don’t know stuff.

Paul Dyson responded:

spot on! This is fundamentally what I don’t like about the kanban “if people find estimation hard, don’t make them do it” mantra.

Which is where I jumped in:

where did you hear that “kanban mantra”? Not one I’m familiar with.

Only to be told:

err, it was actually in the talk you gave at mini-Spa!

Since then, Paul has blogged some more on estimation, and this is my response, hopefully clearing up what I said, or at least meant to say at mini-Spa, in addition to what I’ve already written on estimation and waste.

A simple summary and paraphrasing of Paul’s post would be:

Estimation, as part of time-box planning, leads to whole team interaction and collaboration, to create learning about past capability and forecasts of future capability

Lets start by drilling into these key points from Paul’s post. Essentially the implication is that by eschewing iteration, we cannot have whole team interaction and collaboration, cannot learn about past capability and cannot forecast future capability.

Whole team interaction and collaboration

I can think of 3 ways a team a whole team can interact and collaborate around planning a new piece of work without estimating in a time-box planning meeting:

  • Cadence. The team agrees a cadence at which they will all get together to collaboratively plan new work. This planning cadence looks at what new items the team may be able to pull, given their current work-in-process, rather than estimating what items they may be able to complete.
  • Workflow. The team explicitly models their workflow to make transparent that fact that they need to get together to plan new pieces of work when they are pulled. This stage could be a stage called “Planning”, or even ”Analysis”!
  • Just do it! When the team pulls a new work item, they spontaneously swarm on it to plan it. This probably requires a small and high performing team.

Even so, this is assuming the whole team really does need to interact and collaborate on every piece of work. However, not every piece of work is equal, and there may be some smaller, simpler features that can be planned and delivered by a smaller group.

Create learning about past capability

We can learn about our past capability by measuring data such as cycle time, and tracking it with a Statistical Process Control chart. Common cause variation is to be expected within a stable system. However, special cause variation is something we can look at in more detail to see what we can learn (as long as we don’t change the system in response to special cause variation).

Forecast future capability

Once we understand our past (or current) capability we can use that information to forecast future capability. By understanding how long things have typically taken in the past (with natural variability) we can determine how long things will take in the future (with natural variability). Dennis Stevens has recently written some great posts discussing knowing when we will be done, using classes of service and service level agreements to manage variability.

So kanban teams do not eschew estimation simply because it is hard. Some teams choose not to estimate because they can realise the same benefits that estimation gives with a lower cost. The old joke does still apply (“Doctor, Doctor it hurts when I do this”, “Don’t do that then”). If it hurts to estimate, then find other ways to encourage whole team interaction and collaboration, learn about past capability and forecast future capability. On the other hand, if estimation doesn’t hurt, or costs too much, then it may be the right thing to do in your context.

What I think we do agree on is that when we are planning, we should decompose work for understanding, rather than sizing (thanks to Eric Willeke for this phrasing). As Mike says, the estimate is just a number that pops out of the discovery.

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

Aspects of Kanban in Methods and Tools

I wrote an article on “Aspects of Kanban” which has just been published in the Summer 2010 issue of Methods and Tools magazine. Download it, have read, and let me know what you think!

Alternatively, there is now an html version available.

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

Kanban and Scrum – Intention and Implementation

In my last post I introduced the idea of a PVC System – one which exemplifies Pull, Value and Capability – and closed by posing the question as to whether Scrum could be considered to be a PVC System. In answering that question myself, I realised that there is another distinction which I will describe in this post. In doing so, I am also re-entering the great Kanban and Scrum debate, with the goal of learning rather than fighting!

The XP Community popularised the concept of programming by intent; writing code which describes what it is doing rather than how it is doing it (programming by implementation). I believe the same distinction can be used to describe methods, and can help differentiate Kanban and Scrum. Kanban is an intention-revealing method. The intention is to reveal the workflow, visualise the work, limit work in progress, establish a cadence and continuously improve. How to do that is up to the team. They can use any workflow, visualisation, WIP limits, cadence or improvement mechanisms. Scrum on the other hand is an implementation-revealing method. The implementation is described in terms of the Sprint and the associated roles, meetings and artefacts. Even if the implementation is described in abstract terms, as Tobias Mayer does, (and Tobias’s interpretation of Scrum is one I respect greatly) I still consider it to be focussed on implementation.

This is not to say one is better than the other. An implementation is ultimately required, and Scrum has proven to be a very good one with which I have had considerable success. But is Scrum a PVC System? I think it can be, if implemented with an intention-revealing mindset. If the Sprint, roles, meetings and artefacts are implemented in way which reveals the workflow, visualises the work, limits work in progress, establishes a cadence and continuously improves, then it will be implemented with the right intent. I expect that most cases of “Good Scrum” will fall into this category. On the other hand, if the Scrum Sprint, roles, meetings and artefacts are implemented in a mechanical way, then I suspect that the workflow will remain hidden, the work will not be visualised, work in process will not be limited, a cadence will not be established, and continuous improvement will not happen. This is when we get cases of “Bad Scrum”. Thus ScrumBut is not when the Scrum practices aren’t followed per-se, but when they are followed with the wrong (or no) intent.

So Kanban and Scrum are like apples and oranges (to jump to an different analogy). Both are good for you, and both can go together – with other fruit – to create a tasty fruit salad. But they are different. Kanban is intention-based and Scrum is implementation-based.

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

From KFC Development to PVC Systems

I’ve been revisiting my earlier KFC Development work in light of my more recent focus on five primary practices. This is an brief overview of what’s changed, and what my mental model looks like now.

Firstly, I’ve stopped referring to the practices as such, in favour of calling them aspects. Practices always felt slightly wrong, but at the time I couldn’t think of a better way of describing what I wanted to be practical, rather than theoretical points. I think aspects still allows that practical focus, without giving the impression of being a prescriptive process. So the aspects are:

  • workflow
  • visualisation
  • work in process
  • cadence
  • continuous improvement

How does the KFC triad fit into that then. Here’s my thought process, which focusses more on conceptual ideas.

  • Kanban. In this context, Kanban is the tool. As I have become more interested in Systems Thinking, I have become less focussed on the tool. What is more important is the concept behind the tool. Kanban is a great way to create a pull system, but there are others; drum-buffer-rope and CONWIP are a couple. Kanban seems to be the one that’s easiest to explain, and the one that caught people’s imagination, but really its about Pull.
  • Flow. Given the first concept is Pull, and we should flow where we can and pull where we must, then I think Flow comes under the concept of Pull. What I tended to find myself talking about with Flow, however, was what should flow. There’s not point having a pull system where work flows smoothly if the work is useless, so the second concept is really about Value.
  • Cadence. Having identified Cadence as a Aspect, it can’t really be a concept as well. I talk about Cadence as a means of achieving predictability and reliability and of demonstrating capability. Cadence is just one way of doing this however, so the third concept is really about Capability.

So instead of KFC Development, I have moved to thinking of a Kanban System as a PVC System – one which exemplifies Pull, Value and Capability, and that can be described in terms of workflow, visualisation, work in process, cadence and continuous improvement. I quite like the ‘plasticity’ metaphor that springs to mind with this new triad; “the capability of being moulded, receiving shape, or being made to assume a desired form”. Its probably not very environmentally friendly though!

For me this also leads to the question of whether a process (such as, for example, Scrum) is a PVC System. That’s the subject of another blog post though!

VN:F [1.9.22_1171]
Rating: 4.4/5 (7 votes cast)

CfP: LESS2010 – International Conference on Lean Enterprise Software and Systems

This is a belated announcement about LESS2010, whose Call for Papers for LESS2010 closes tomorrow – June 15th.

LESS2010 is the International Conference on Lean Enterprise Software and Systems, in collaboration with the Lean Software and Systems Consortium (LeanSSC), to be held October 17-20, Helsinki, Finland. CfP details can be found at http://less2010.leanssc.org/call_for_papers/ with submission details at http://less2010.leanssc.org/submit/.

Note that we have clarified the submission requirements. The instructions should be used as a guide. However, content is more important than style initially, so submit whatever is best to give us a good idea of your proposal. Any accepted submissions will need to eventually be expanded and conform to Springer’s LNBIP format for publication.

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

LeanSSC 2010 UK

The Icelandic Volcano Ash Cloud meant that non of the European Speakers could present at the LeanSSC Atlanta 2010 conference. Additionally, many attendees were unable to make the event. As a result, we have put togther this small mini-conference to allow the speakers to share there ideas and experiences, and ensure that the time and effort put in to prepare is not wasted!

We have chosen to collaborate with the UK Agile Coaches Gathering, are are hosting the event at Bletchley park immediately before that get together, so that anyone wanting to attend both can hopefully save on travel and accomodation.

The following speakers are confirmed:

  • Karl Scotland – A Kanban Universe
  • Simon Baker & Gus Power – Product Development in the Land of the Free
  • Liz Keogh – BDD: A Lean Toolkit
  • Benjamin Mitchell – Using Kanban to Get Knowledge and Continuously Improve
  • Mattias Skarin – Converting A Scrum Team to Kanban

Because this is a free event, with limited places, please only sign up if you are genuinely intending to come!

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

A Kanban Multiverse – not from LeanSSC Atlanta

I should have been at the LeanSSC Conference in Atlanta this week, but unfortunately Eyjafjallajokull intervened. This is the Prezi I was going to use. It may not make much sense on its own but hopefully gives a flavour of what sort of things I was going to talk about. I’m hoping to put together a post together to flesh out the details.
Update: I posted a write-up on the Management 3.0 site
VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Defining the Last Responsible Moment

I was involved in a recent twitter discussion with Chris Matts about Lean’s “Last Responsible Moment”, and he set a challenge to come up with a usable definition. Chris’s opinion is that there isn’t one, compared to the Real Options equivalent. This then, is my response to that challenge.

I will define the Last Responsible Moment (LRM) in terms of Cost of Delay, as used by Don Reinertsen, and Benefit of Delay, a related term that came up in an email conversation with Julian Everett. In short, the Last Responsible Moment is just before the Cost of Delay outweighs the Benefit of Delay. Its not necessary to be able to quantify the costs and benefits very accurately because any evaluation is going to be better than none!

In his challenge, Chris used the example of knowing the Last Responsible moment to submit a session for Agile2010. I’ll use that example to explain my definition.

Firstly, the Cost of Delay for submitting to Agile2010 goes up at the submission deadline, because when you can no longer submit, can can no longer get accepted, and thus can no longer receive speaker benefits including conference registration, complimentary hotel nights. However, that does not make the submission deadline the LRM, because there is no benefit in delaying submission due to the open commenting and review process. Thus the LRM is actually as soon as the submission system opens. From then on, submitters are losing the opportunity to improve their submission.

What would happen if the Agile2010 submission process wasn’t as open or iterative? In that case, then there would be benefit in delaying, because it would allow more time to refine a submission before entering it. The Benefit of Delay would drop off just before the deadline, however, so the LRM would be then.

A third scenario, as suggested by Chris, is that a speaker might have something so important and valuable to say, that the Benefit of Delay doesn’t actually drop off at the submission deadline. There may be a Benefit right up to the conference itself because a speaker can turn up with a Soap Box, or propose a session for Open Space. The Cost of Delay remains the same, due to the loss of speaker compensation, but the Benefit might always outweighs the Cost.

Finally, in this scenario, a speaker might choose to register for the conference early anyway to take advantage of any early bird deals, and book flights and hotels early to get good prices. This would reduce the Cost of Delay, and thus potentially reduce the Benefit needed to make it worthwhile not requiring an official speaking slot on the program.

To summarise, understanding both the Cost of Delay and Benefit of Delay can be a practical way of defining the Last Responsible Moment. Real Options thinking provides ways of influencing the Costs and Benefits of Delays to gain some flexibility.

VN:F [1.9.22_1171]
Rating: 4.0/5 (2 votes cast)

Facilitating A Kanban Konversation

As I mentioned in my Scrum Gathering Musings, I came up with a twist on the Goldfish Bowl format which I used during the Kanban Exploration Deep Dive.  Here are some more details.

The Goldfish Bowl format works really well for facilitating a focussed discussion with a large number of people. It keeps the active voices to a manageable number, while being open for anyone to join in if they have something to add. Apart from providing a solution to my challenge – keeping a spirited debate under control – it also seemed appropriate that the limited number of chairs provided a means of limiting “Voices In Conversation”.

However, there was one thing about the Goldfish Bowl which didn’t seem appropriate. With a Goldfish Bowl, when someone wants to join the discussion, they fill an empty chair as part of the conversation, and force someone to leave to free up a seat again. That seemed to be like “pushing” in to the discussion. What it no-one wants to leave? So instead, I moved the empty chair out of the discussion, and made it a Queue. If someone had something to contribute, they could fill the “Waiting to Talk” seat, which would be a signal to the “In Conversation” people that one of them should leave when ready. I was pleased to find that this change worked really well. Rather than the discussions being interrupted when people moved around as they figured out who would leave, the conversations flowed smoothly as people moved in and out naturally. Initially the “Waiting” person had to wait some time, but once we got used to the system, this seemed to be less of a problem.

These are the instructions I used:
  • 4 “In Conversation” seats and 1 “Waiting to Talk” seat
  • Only “In Conversation” people may speak
  • If you want to join the conversation, fill the “Waiting to Talk” seat (if it’s empty)
  • When someone “In Conversation” leaves, that is a signal to move from “Waiting to Talk” to be “In Conversation”

I wondered whether we would evolve the system, by increasing or decreasing the number of seats in each state, but that didn’t happen. Its something I’ll look out for in the future. I’d also love to hear if anyone uses this format, or has already done something similar.

VN:F [1.9.22_1171]
Rating: 4.8/5 (4 votes cast)

Did I Mention The LeanSSC?

I’ve just posted an entry on the LeanSSC blog, introducing myself, and talking about my involvement with the group. Its the first of what I hope will be a series of posts introducing a number of the founder members of the Lean Software & Systems Consortium. The goal is to create some more visibility and transparency of who the LeanSSC is and what we are trying to achieve. In addition we have created a public Yahoo! Group where we hope that we can more openly discuss the ideas advocated by the LeanSSC.

While I’m talking about the LeanSSC, I should highlight that if you’re thinking of going to the Atlanta conference and haven’t booked yet, the price gores up again in April. Book now while you can at $995. And if you’re not thinking of going, why not?!? The program looks excellent, and having just begun piecing together my talk, I’m really looking forward to it. I’ll be bringing together some ideas on visual management kanban board techniques which I’m calling the Kanban Multiverse.

An added benefit of coming to t he conference is that the Technical Advisory Board is also meeting at the same venue on April 20th (Tuesday) and is open to all conference attendees. To attend all you need to do is to show up a day earlier, and to register for the conference and collect your badge on Tuesday. The registration desk volunteers will direct you to the room for the TAB meeting.

I hope to see you there!

http://atlanta2010.leanssc.org/
VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)