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)

Trade-offs

A really good way of improving the exchange of information between clients and suppliers is to try to get them to tell each other about trade-offs. Every business has them.

When you're buying a car or a coat - do you buy the cheapest? Thought not. So what's wrong with the cheapest car? What's wrong with the cheapest coat? OK let's make a list: horsepower, features, handling, quality, style, having to wrestle someone for it in Primark.


Primark - Pile it high... (pic courtesty of adotjdotsmith)

Do you buy the absolutely best quality? No. The most possible horsepower no. Do you by any chance instinctively understand that when it comes to cars or clothes there are whole bunch of trade-offs? You can have cheap, but it won't be fancy. The faster it goes, the less likely it is that you can get a baby seat in it (or get baby vomit out out of the carpet). You can have top-quality cashmere haut-couture but it won't be cheap and you probably won't want to wear it when you go to the gym. You can have cheap, but don't expect it to fit.

Get the idea? It isn't just one trade off, there are lots. You don't really understand anything, until you understand the tradeoffs. And it's more complicated that that. In software development they're very often three way rather than two-way trade-offs.

I took part in a panel discussion where one of the other members - Chris Heilmann - said that whenever he starts talking to clients about writing software, he draws three circles and labels them "Cheap", "Fast" and "Good". Then he tells his clients that they can have any two - that's at least a start at getting his clients to understand that there are trade-offs.


Expensive? Yes. Stylish? Yes - but maybe not the right thing for the beach...(pic courtesy of Tammy Manet)

When we first started doing Agile training, we had great difficulty explaining the difference between the Agile concept of stories and terms used in other design methodologies such as "Use cases". Things got much easier when we started to talk about stories as "negotiations" (or trade-offs) between scope, priority and effort. Stories are dynamic. Each story is an exploration of a possible trade-off. When you start to think about things like this, you begin to realise what an improvished, static and inadequate thing a specification is.

For more about trade-offs, read from Gerald M. Weinberg - Secrets of Consulting.


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)

Stories are - stories!

One of the things that we've found most difficult to explain to people new to Agile is the difference between an agile Story and an old-school waterfall specification.

If for example, you have a story for some website that goes like this:

Users can log in

and a line in a detailed old-fashioned specification document that reads:

1.2.2.3 Users can log in

How are the two different?

It seems very difficult to say that they are different when they essentially say the same thing, they have the same content. The difference between a story and a specification isn't necessarily in the content. Rather it is in the way that the story and the specification are used. As Henrik Kniberg says in his fabulous book Scrum and XP from the Trenches, stories are an ongoing negotiation between priority, effort and scope. Huh? Is that supposed to make things clearer? OK, we should deal with this in an Agile manner - a little bit at a time. Lets start with priority.


The "1.2.2.3" tacked onto the beginning of the specification is to indicate that this particular bit of specification is buried deep inside some multi-level numbered document and there, in a traditional waterfall development model, it will stay. In contrast, each Agile story gets some kind of priority rating either at the initial meeting where stories are extracted, or at the meeting where what goes into an iteration is decided. This prioritisation has be to done in consultation with the customer. As a result this story doesn't stay fixed like the waterfall specification but it moves around - it either becomes one of the stories that is likely to be implement in an iteration, or one that is left until later.

Now lets deal with effort. Each story is given an estimate of some unit of time that it will take to complete, preferably by the person who will be responsible for implementing that story.

Finally there's scope - just what does:

Users can log in

include and imply? What isn't needed? Again, in conjunction with the customer, the team need to work this out. Maybe some of this needs to be noted on the story card.

OK, so now we've got an idea of what priority, effort and scope are - how is a story a negotiation between all these things? Well, imagine we're sitting in a meeting with a client trying to decide the next iteration and we've got this story in front of us:

Users can log in
Priority: 100
Effort: 10 days

And the customer (who's normally very reasonable) says "What? How the hell can it take that long?" One of your developers explains that - although you haven't written this on the story card - you imagined that this would also need a form to register users and a bunch of work to create a database of users. So the scope for this story would look like this:
Scope: login page, user registration page, set up of user database

The customer is shaking is head - "No, no, no, right now we don't need to be able to register anyone new - we've got an already existing user database - all you need is a form with a username and password and we absolutely have to have it in this release."

So the team look around at the priorities on some of the other stories and then do a bit of scribbling and the story comes out like this:
Priority: 150
Effort: 3 days
Scope: login page, integrate with existing user database