Trying to Understand Kanban in Software

I was very interested to hear Karl Scotland's talk yesterday at Minispa2009 about Kanban. I think he's a addressing some very important issues, but as I've said on Twitter, I wasn't quite convinced by his talk. I think he's nearly there and can't quite make out whether the problems are in my understanding; his communication; or in the actual ideas themselves. Anyway, here are some notes on things that I think at the moment are an issue.

Software components aren't car parts

One of the way I try to explain stories when I'm doing agile training or consultancy is that stories are stories. A story is an out-of the ordinary situation which needs resolution. It's news. Software development spends most of it's time dealing with "Man Bites Dog" cases because "Dog Bites Man" cases are already catered for in the language libraries and the API. Software people, project managers and the people who support them with training and consultancy are all what Peter Drucker called "Knowledge workers". Ironically, that means we spend most of the time NOT knowing what we're doing. I'm not sure how well this fits with manufacturing car parts, or assembling cars.

Toyota Production System is a "That would never work for us" method

Anybody who has ever tried to advocate any kind of project management method to someone in an organisation will be familiar with the "That would never work here, that would never work for us," response. What isn't perhaps discussed so much is that exactly that attitude is the root of the Toyota Production System from which Lean and Kanban ideas are extracted.

As I understand it from my reading of Taiichi Ohno's book and from reading "The Machine that changed the world." One of the original spurs for the Toyota Production Method was an understanding that the way that Ford made cars wouldn't work in Japan. They simply couldn't make enough cars to get the economies of scale that Ford (claimed) he was getting. Another realisation was that Japan's demand for manufactured goods was extremely cyclical and so Toyota needed a method that could "smooth" out these oscillations in demand. But Ford's model of hiring and firing low-skilled workers as the need arose simply didn't fit with Japan's cultural understanding of what work was. People worked for the same firm and stayed loyal to it all their lives. Enormous value was placed in the deep knowledge and mastery of skills. Toyota decided to put together a system valued skilled workers and held onto them through all stages of the economic cycle.

This is what I don't see in Lean and Kanban approaches to software. It doesn't say "We need to design our own Toyota Production System that reflects our culture, values and economic cycles," rather it says "we need to use theirs!".

Flow vs frame. How do you know what you're capable of?

This maybe not so much an objection as a lack of understanding. I didn't quite understand what Karl meant by the term "cadence". It seemed to be something like an iteration, but of variable length. I sat up and paid very close attention at this because one of the things that you're always asked when consulting and training about Agile methods is "How long should iterations be?" And so some kind of rule - even a rule of thumb for working this out would be interesting to know about. But at the same time I'm worried that giving up on the idea of fixed-length iterations, results in the loss of information about velocity. And one of the things that I think is vitality important about Agile methods is the ability to get better and better understandings of what you're capable of as a team.

Another way of thinking of iterations is a frame that you put around the work that would be getting done anyway that allows everybody (developers, project manager, clients) to talk about it in an different way, to reflect on progress, to decided on changes of emphasis and direction.

The aim of these comments and objections isn't to dismiss Kaban/Lean approaches because I think they would be particularly well-suited to settings such as web development agencies, where the work tends to turn up in a continuous flow and doesn't necessarily fit itself into time-boxed. Iterations.

Thanks to Karl for an interesting talk.

For further information, contact Mark@agilelab.co.uk (07736 807 604)

Agile Training - Why Bother?

This is an article about a blog post I don't like. Here is one by Paul Dyson on Agile project management that I really do like. Why aren't many other people thinking so closely about what the project manager actually does?

Why Bother?

Why bother with Agile Training? Isn't it just a waste of time? When you search for "Agile Training Blog" using Google - one of the first posts that comes up is a three year old post on a dead blog (hey you Google boys - are you sure this is right?) claiming that Agile training is a waste of time. The gist of the post is that when you attend an Agile training course you're going to get one of two things for your money: either you'll get taken through all the Agile concepts or you'll be regaled with war stories of the trainer's Agile experiences.

Education Bad

The point of the author of the "Why Bother with Agile Training?" blog post is that either of these approaches is a waste of time. If the course is just a lecture that takes you through the standard Agile ideas and concepts, you could have just as easily read about these in a book. If the course is just a collection of war stories, the chances are that they aren't going to apply to your situation.

Wrong and Wrongerer

I don't agree with either criticism. It's always useful to have someone who understands the material to take you through it. There are a couple of aspects of Agile - stories, velocity - that in my experience people don't immediatiately "get". And the idea that you can't learn from other people's stories because they aren't in the same situation as you is just strange. How else could you learn most things? If someone tells you not to put your hand in the fire, because it burns, what do you do? Say to yourself? "Oh that was a completely different fire, not comparable to this fire at all. Ow! Ow! Ow! Don't just stand there! Call an ambulance!"

Can you Feel it?

But the most important reason why I disagree with this post is because I think there's a third kind of experience that you can get from training. An experience of what it feels like to do things in a new way. And that's why I work really hard to develop and improve the exercises that I include in my courses. Through the exercises, I want to give people an idea of what it actually feels like to take a brief for a project, break it into stories and then develop it iteratively, using time-boxed iterations. By the end of these exercises, there's a much better chance that they "get" what I mean by a story and have a feeling for how to calculate velocity and use it in future iterations.


Fire - like they say in the "War stories" - it burns. (Picture courtesy of . SantiMB .)

For further information, contact Mark@agilelab.co.uk (07736 807 604)

Experts Know what they're Capable of - Using Velocity and Yesterday's Weather

This is a reply that I gave to someone on the London Java Community mailing list who was asking about better ways to manage estimation of tasks and time. I thought it was worth reprinting it here.

Dear X,

One of the best ways of improving your abilities at estimating over the length of a Sprint is to use two concepts combined: velocity and yesterday's weather. These are actually some of the more tricky aspects of Agile to explain, but I'll have a go just now, really quickly.

Imagine that you're first sprint is a fortnight. And so, quite naturally you plan to do 10 days work in that week and sign up to do enough stories/tasks to fill those 10 days. At the end of the 10 days you count up how many stories that you have actually done. Surprise, surprise, some things took longer than you thought so you actually only managed to do the tasks that you estimated would take you 7 days.

Ok, important concept #1: Velocity - this figure, the number of days of estimated work that you actually delivered is called your velocity. You can think of it a bit like your power. You thought you could deliver 10 days work, but actually you can only deliver 7. Ouch that hurts doesn't it? But the pain is worth it because by understanding your velocity, you're on the way to being able to accurately estimate things in the future and actually deliver things when you say you're going to deliver them.

Ok, now important concept #2: Yesterday's Weather. For the next sprint of 10 days, you only sign up to stories/tasks that you estimate will take 7 days. Ouch - that hurts even more doesn't it? But what you're doing is using your experience of how good you are at estimating and feeding it back into the process. This of course doesn't meant that if you get through all those things by the end of Wednesday on the second week, you don't find some other stories to work on. What it does mean is that over the course of several iterations, you keep checking with yourself how good you are at estimating your own velocity.

This feature - knowing what you're capable of, being aware of what you can and can't do in a fixed period of time is a well-documented feature of experts and high-performing teams. This books is a fascinating account of how experts are different from beginners http://is.gd/pots


There are bunch of other psychological tricks that you can use to detach yourself from trying to get the number right for any particular job. One that I found very useful is to try to imagine what the absolute worst case scenario figure would be and what the minimum time would be and then take the geometric mean (http://en.wikipedia.org/wiki/Geometric_mean).

I got this idea from this brilliant book about estimation -
Guesstimation: http://tinyurl.com/cypdbg



There's a really good book that looks at all this velocity/yesterday's
weather stuff in close detail: Scrum and XP from the trenches. It
also deals with "focus factor" which is a big issues in actually
delivering on estimates.

http://tinyurl.com/c26p8p


You could also come on my next course:

http://www.nmk.co.uk/event/2009/3/12/reducing-risk-and-improving-results-agile

Regards,

Mark Stringer.

For further information, contact Mark@agilelab.co.uk (07736 807 604)