Last month I attended the excellent London XPDay. This year, XP Day was largely made up of open space discussions but there was an ‘Experience Report’ track where I gave a presentation on switching my team from Scrum to Kanban. The talk draws heavily on previous fragile posts (1,2), but also reflects what I have learned during the interim.
Dec 212010
Mar 072010
Scrum, as a framework, is practiced in many different organisations and can be considered a mainstream approach to software development. To me agile is way of scaling common sense and while I no longer practise Scrum I consider it an excellent implementation and would happily return to it if my circumstances were better suited to time boxing. However as with all great ideas that are adopted widely, there are many instances where people are simply doing it wrong.
Warren Buffett has a neat way of describing this:
First come the innovators, who see opportunities that others don’t. Then come the imitators, who copy what the innovators have done. And then come the idiots, whose avarice undoes the very innovations they are trying to use to get rich.
In the case of software it’s reasonable to replace the goal of getting rich with that of successfully delivering software that is valued by the customer.
As such there are a wealth of posts discouraging the adaption and variation of Scrum, in fact the notion of Scrumbut is so well understood it even has a definition.
scrumbut [skruhmbut] noun.
1. A person engaged in only partially Agile project management or development methodologies
2. One who engages in either semi-agile or quasi-waterfall development methodologies.
3. One who adopts only SOME tenents of the SCRUM methodology.
4. In general, one who uses the word “but” when answering the question “Do you do SCRUM?”
Project management will necessarily vary from company to company. As such the ubiquity of a term like Scrum has less value within a specific company, since the shared understanding of the company’s approach ought to be evident to all. When I talk to people outside of my company it’s useful to reference commonly understood terms as a starting point. For time boxed approaches Scrum is an obvious point of reference, but the specific system that I wish to describe is highly likely to deviate from Scrum in some way and I do not necessarily see this as a bad thing.
The challenge of software development is to produce something that someone will find valuable. There are plenty of different ways to achieve this and all are highly dependent on the context of the project. Generally an iterative and incremental approach that bakes quality in from the start is preferable and a number of ready made implementations exist such as Scrum, Kanban or Evo. In some cases it may be appropriate to lift something like Scrum wholesale, but in many other cases, there are legitimate reasons for adapting the process. For example a team might be writing an implementation of a system where the behaviour is well understood. In fact in order for the system to be compliant and therefore usable it must adhere to a large pre-written spec provided by an external party. Clearly this is at odds with Scrum but there is no need for the team to drop time boxing or stand ups as a result.
So adapting a process is not in itself something to be frowned upon. Clearly bad project management is bad, and if the manager blames their own failings on their inability to implement a methodology then larger problems exist. The key point is that good managers should not worry that they are running Scrumbut, or indeed if they are ‘doing it right’ as the only metric for correctness is that the team maximises the value they create.
Jan 042010
Recently my team have been trialling the use of a Kanban board to manage our work flow and in doing so have dropped time boxing. So the far the switch has been very positive, while it may not be an appropriate transisition for all teams I thought that it might be useful to share our experiences.
In brief, Kanban is an agile development methodology that does not prescribe time boxing (i.e. fortnightly iterations), rather it focusses on limiting work in progress. For each stage of a story’s life span e.g. ‘in progress’ or ‘ready to deploy’ the team has a maximum amount of work that can exist. As stories are completed the team pull new stories from the project backlog. For more information I would recommend Henrik Knibergs excellent comparison of Scrum and Kanban
Why Kanban?
We originally adopted time boxing about 6 months ago, the key benefits we were looking for included:-
- A sense of rhythm and points to reflect on our working practices.
- Better visibility over tasks that were dragging on.
- A highly visible feedback loop to help improve our estimations.
For the most part the adoption of time boxing was very successful, we’ve certainly improved our abilities to estimate, and generally we have better visibility over our performance. The thing that didn’t work so well was working to the self imposed iteration deadline since it often felt false and sometimes was counter productive.
Any team working to an iteration will occasionally finish early or fail to complete all tasks, it’s not ideal but manageable so long as the team continually refines it’s working practices to minimise occurrences. In my team’s specific case this is especially hard since so much of our work is dependent on our interactions and integrations with companies much larger than ourselves. Experience tells us that it is practically impossible to predict the time spent on an integration and even harder to guess at what point the time will be spent. As a result, despite working in a predictable manner on the majority of our iteration goals it was common that we would under or over shoot.
This is hardly the end of the world though it started to chip away at the sanctity of the iteration and continually raised questions of why the system was pushing us in ways that felt wrong to us i.e. if we finish early then we can take another story from the back log so long as it fits into the time remaining, however ideally, for a given project, we’d want to the story with the greatest risk attached which may or may not fit in the time allotted. It felt that time boxing was nudging us away from this idea.
Furthermore, my company is such that our developers typically have a very good level of product domain knowledge, as such the need for a formal Scrum style Project Owner is reduced. This means that while we would demo our work to interested parties on completion of features, come the end of an iteration it was rare to demo our progress.
It was clear that while providing some benefits we were fighting against time boxing and we needed to find an approach that better described our work flow. What we were aiming for was not so much to complete a set of tasks in a pre-allotted time period, more that we should be able to regularly produce deployable features in a predictable manner. By limiting the work in progress rather than limiting the work per time Kanban presented a viable alternative we felt better reflected how we actually work, while preserving the discipline necessary to deliver working software multiple times a week.
Initial findings
Since mid iteration our practices were already similar to that of Kanban we found that migration to the system caused very little disruption and we did not notice a productivity hit while we got used to the new system.
The migration has brought about subtle but positive changes to how we work, largely due to the fact that by explicitly limiting the amount of current work it forces conversations to be had where we are close to violating the limits.
In addition to making it easier for us to refine our process, the main benefits so far include:-
- Greater flexibility in our work flow, we can respond in days rather than the three weeks a two week iteration promises. This is key, as delivering supplier driven changes quickly provides significant competitive advantage.
- On a related note, we no longer feel that we are fighting our process. It is no longer the case that we regularly take a course of action that violates our process (albeit for perfectly sensible reasons).
- The board provides a highly visible place to display tasks, communicate priorities and highlight bottle necks. These benefits are not Kanban specific however Kanban’s greater emphasis on use of the board (through tracking work in progress limits) means that any benefits are magnified.
- It saves us an iteration meeting – the role of the meeting is covered in stand ups or in project specific design meetings.
- Our stand ups have become much more focussed, this is partly because we do them in front of the board. Again this is not Kanban specific but in Kanban running them anywhere else makes no sense at all. Id’ say that we’ve halved the length of time we devote to stands ups, where further discussion is necessary it is taken outside of the stand up.
- Our retrospectives are no longer coupled to the period of our iteration, currently we still run retrospectives fortnightly, though since our stand ups are now more effective for day to day tweaks we may extend this period.
In terms of cons, thus far we do not feel that we have lost anything by adopting Kanban, the only potential problem that we have encountered is that greater discipline is required in ensuring that all tasks are completed in a timely manner.
The future
So far we are very happy with Kanban and will continue to use it.
In order to measure performance over time Kanban teams track two metrics.
- Throughput
- Lead time – the time it takes for a feature to be delivered after the team has committed to its delivery.
At present we do not have enough data for meaningful results but long term we will maintain something much like this as suggested here.
Further reading
In addition to Scrum vs Kanban comparison referenced above you may find the following useful.
- Implementing Lean Software Development by Mary and Tom Poppendieck.
- The Limit Work in Progress Society Kanban blog
- A guide to incrementally introduce Kanban ideas into a Scrum environment, known as Scrum-ban.
Finally not everyone is as sold as I am on Kanban for some anti Kanban debate see:-
I found the comments that follow the posts to be of particular interest.
