Oct 9, 2007

Agile project management has certainly come a long way in the last few years and there is strong evidence of a rapidly growing maturity in the space and a commensurate awareness of agile in the maintsream consciousness. As an example a few years ago trying to hire someone with agile experience would have been a very difficult process, like finding the proverbial needle in a haystack. Most candidates would have stared at you blankly and wondered what the hell you were talking about.

Fast forward to today and you'll find that the haystack is rapidly getting smaller and many people will now at least acknowledge that they've heard of agile, even if they haven't actually experienced it.

With the growing body of knowledge regarding Agile methodologies there comes an understanding that there are many ways to solve the same problem and a rise in different ways of "being agile". A question popped up on one of the internal Readify discussion lists recently around the suitability of Kanban for internal development.

For those who don't know, Kanban is an agile methodology created by David Anderson to run his development projects. David knows a lot about agile development and is widely regarded as a thought leader in this area. Here's an extract from http://www.agilemanagement.net/Articles/Weblog/KanbaninAction.html (and other writings of his)

“The Kanban system might be visualised as a "Three bin system" - one bin on the factory floor, one bin in the factory store and one bin at the Suppliers' store."

The idea is that there is pool of resources and you set a "kanban limit" which defines how much work-in-progress you're prepared to commit to.

Then as one "kanban" (new feature, bug, change request) is shipped, another "kanban" becomes available. So you go back to the business and ask them which feature/bug/change they want done next.

balance capacity against demand (as new CRs can only be introduced when a kanban card frees up after a release);

and prioritize.

We hold a business prioritization meeting once per week with vice presidents from around the company. They get to pick new CRs from the backlog to allocate against free kanban cards. This forces them to think about the one, two, or three most important things for them to get done now. It forces prioritization."

David's thinking is largely based around the principles of Lean manufacturing and the Theory of Constraints. In seeking to improve efficiencies in the software "manufacturing process" you have to think about where the constraints are and where the bottlenecks occur, and this is what David has done (and quite well).

The kanban system realises the constraints are squarely within the realm of the development team. This is almost always the case in any business. The demand for new software by customers (internal or external) almost always outstrips the ability of the development team to supply that software. If that isn't the case, then it soon will be as the business will start downsizing development staff pretty quickly (developers are an expensive resource after all).

But what kanban also does is take a subtly different view to the development process itself. Kanban treats software requests as a stream or work. You've dealt with one request? Great! What's next in the stream? It never ends, just keep the work flowing.

Scrum, and all the other agile iteration based methodologies, differ in that they segment the "requirement stream" into chunks of work and process those chunks in a batched manner. The customer selects what items they want done at the start of the iteration and 2 weeks later the team (hopefully) comes back with the completed work.

So the question now Is which approach is better? Well, as in all things, you need to think about what is best for your team, your customers and your business. I personally think Kanban can work really well in software maintenance environments where work is coming in as a stream of small amendments and changes, while Scrum may be better suited to new work where delivering lots of thin vertical slices of functionality is more appropriate for customers. But, hey - we're talking about agile methods here. Think about what's happening, inspect what is working and what isn't and adapt what you do so you can do it better :-)

3 comments:

Correct me If I'm wrong but in contrast to scrum you would use kanban if:a) your requirements don't have a definitive 'finish line'b) there is no/or less need to demonstrate Proof of Concept and Risk management techniques (prototypes) to the client as opposed to scrum.

You can use either Scrum or Kanban when there is no definitive finish line. Scrum places more emphasis on release planning, but it's not required (only sprint planning is). Thus under both methods you could decide to release at any point in time by simply taking the current solution and pushing it out.

Scrum focusses more on discrete delivery, but it doesn't mean you can't use it for rolling requirements or software maintenance work.

And I would disagree with Kanban being more appropriate in situation B). POC's and prototypes can be delivered under either method, though Scrum will help ensure that the team only does the spike task for a limited time, while under Kanban you would probably need to explicitly state that a POC exercise can not exceed 2 weeks worth of effort (for example).

If you don't need to do a POC then you'll just be doing normal development. Either method will work equally well in this case (as you would expect).

Project managers prefer Scrum better than Kanban. It is more oriented toward systems while Scrum has a close affinity with project managers and stakeholders due to their presentation of processes and events. Both their workflows are alike, with the only exception of Scrum having their deadlines better demarcated.