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.

"The kanban system allows us to deliver on 3 elements of [David's] recipe for success:

  • reduce work-in-progress (in fact it limits it completely);
  • 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 :-)