This site uses cookies. Continue to use the site as normal if you are happy with this, or read more about cookies and how to manage them.

×

This site uses cookies. Continue to use the site as normal if you are happy with this, or read more about cookies and how to manage them.

×

Kanban Versus Scrum for Product Development

Disclaimer: I'm not a big fan of the term "Scrum" and think the metaphor is completely wrong. Certainly in my rugby days, scrums were something that involved conflict, aggression, and a high probability of severe personal injury...Perhaps a better (although less SEO friendly) title for this blog entry would be "push versus pull in product development".

In a break from Black Pepper's traditional model of delivering world-class enterprise IT platforms for blue chip clients, we've been building a product of our own - Companion - the market leading location-based mobile application platform. Now, most product development projects have an air of chaos around them, especially when trying to break new ground or enter markets, but by using many of the agile practices that we would use on a "standard" Black Pepper project (TDD, user stories, iterative development, continuous integration etc) we've been able to navigate much of the white water of this project with some dignity intact.

However, with the product built and shipping and version 2.0 nearing release, I thought is useful to look at some of the differences between this project - and product delivery in general - and traditional agile project delivery.

1. Iterations only mark the passing of time

In a standard agile project, and within the Scrum methodology in particular, iterations are the key unit of measure. By focusing on iterative development, agile projects can rapidly respond to change, provide tight control on development efforts, and allow for planning and forecasting based on past performance. However, in the world of new product development when market forces can dramatically change priorities on an almost daily basis, any iteration of two weeks or more tends to fall apart. I can't recall any iteration in the Companion lifecycle that delivered exactly the stories that we thought we would play within that period. At first, I thought this was down to our own estimation or project management practices - with hindsight, I believe we just had the wrong rhythm. Two weeks is a long time in product development, and we would have benefited from much shorter iterations (one week or less) or adopting a kanban / pull model for getting work done, with the key metrics relating to cycle time: "if I request a new feature of size X, how long before it should be live?"

2. Everyone needs definitive WIP limits

On larger agile projects, work in progress (WIP) is effectively limited by the capacity of the team and the feedback from velocity on an iterative basis: i.e. you only take the number of story points into an iteration that you think you have the capacity for and can realistically achieve based on previous performance. On product development projects, capacity becomes glaringly obvious - you know have more ideas than you know what to do with and usually not enough people to do them - which demands strong prioritization, and can be helped with clear WIP limits. No one works on more than two stories at once. Focus on delivering the value in an individual story and making sure it's done before moving on to the next.

3. There are always better metrics to be had

The traditional agile project metrics of velocity and burn up (or burn down depending on your point of view) are often not as valuable to a new product build as measures such as the average age of stories in your product backlog, cadence of new features being delivered into production, or even automated test code coverage (a key metric on any project that should give you the confidence to release software to your chosen market). Ultimately, any software project should be driven by core business metrics - revenue generated, costs saved through the use of new technology, or more specific earned value metrics. In a start-up or new product development scenario, these business metrics can be all too visible: you launch a product and (hopefully) go from zero clients to one, then two then hundreds or more. Good practice suggests instilling the same focus on business objectives within any IT project to ensure you deliver something of value to the company.

The key theme in this analysis is as follows: whatever methodology or practices you use for any given project, you must always look for continual improvement. All of the tools and techniques under the "agile" banner are geared towards this - the terms agile and agility refer to one's ability to change direction faster and easier than more weighty processes. Black Pepper has learned a great deal from the successful delivery of the Companion platform, and as we watch that product stand on it's own two feet we'll be applying all of that new knowledge and experience to the rest of our projects.