Kanban

Lately, I’ve seen a lot of discussions on Kanban. For those of you who, like me, want to know what all that fuss is about, I collected a couple of links that I will try to merge into a coherent whole below.

So what exactly is Kanban? Literally, it means “visual card”, but that’s not very helpful. This introduction explains that Kanban revolves around a board that visualizes the software development flow.

In fact, flow is a very important concept here. Kanban is a pull system, in which Minimal Marketable Features (MMFs) flow through the development stages when there is capacity available. This contrasts with most Agile methods that push work items into iterations. Also, note that for most Agile methods, those work items (e.g. User Stories) would be smaller than MMFs.

The other big point is that Kanban limits Work In Progress (i.e. the number of MMFs per development stage). This naturally exposes the bottleneck(s) in the flow.

This leads us nicely to the main reason to use Kanban: to improve your software development process. Other Agile methods deal with process improvement as well, but Kanban is different from e.g. Scrum.

So, if all this sounds cool and you want to give Kanban a shot, then apparently this is how you should get started. If you do, then you may see these effects. Also, make sure to get into a Kanban state of mind.

Update: here is a great compilation of Kanban resources.

Create a better software development team

If you’re an agile team wanting to build better software, then check out abetterteam, “Because it takes an awesome team to build awesome software“.

Introducing XP Studio

At my organization, we use a lot of the tricks from the Agile toolbox, like unit tests (although most of us are not doing TDD), refactoring, continuous integration, collective code ownership. We also write black box tests using Selenium and HtmlUnit, but since the developers think them up and implement them, not the customers, we can’t really call them acceptance tests.

If you look at this list, you probably notice that these are all technical practices. What has been lacking so far are the more management oriented ones. But my team has now embarked on a journey to incorporate some of those.

We’re using user stories to define functionality, and deliver them in iterations. Since we’re building a product, not doing a project, our product manager plays the customer role.

The planning game wasn’t easy, since it was all so new for us. But the first iteration delivered all planned stories, the first ever deadline that the team made! Although it is far too early to declare victory, the start is promising indeed.

We do face some challenges, however. Our customer is in Kentucky, USA, while the development team is in The Netherlands. Also, I work from home about half of the time. So we’re definitely not a co-located team. This means we have to invest more in communication. We use e-mail, instant messaging and conference calls to stay in touch.

The distributed nature of our team makes capturing user stories on index cards difficult. Since we’re pretty XML focused (our department is the R&D department for XML in our company), we decided to capture the stories in XML instead and store them in our source source repository.

I know that many in the Agile community don’t like this formalization (Individuals and interactions over processes and tools), but it does have advantages. The biggest one in my book, after making distributed development possible, is that it opens up a whole lot of possibilities for automation. Remember Ubiquitous Automation?

This was the stimulus I needed to breathe some new life in one of those open source projects I participated in, but neglected lately: XP Studio. Check it out and let me know what you think.