I gave up Caffeine

Last Spring I attended QCon London, during the course of the conference I attended Linda Rising’s talk entitled Agility: Possibilities at a Personal Level

It was suggested that in the same way agile teams rigorously apply a regime of inspect and adapt, the individual should do the same at a personal level. As an example, she asked why tea and coffee are so prevalent in the workplace and linked this back to the working practices of the industrial revolution. Specifically, that while caffeine was very useful in making sure unskilled workers arrived at the factory on time and alert, she questioned what penalties we incur force fitting these practices onto a skilled craft like software development?

Just to be clear, Linda Rising stood up in front of a room of computer people and said ‘Stop drinking coffee’ and at no point did anyone try and throw her out of the window. So it was a pretty good talk, so good in fact that immediately afterwards I decided to give up caffeine to see how I would react.

Firstly a bit of background. My company supplies free coffee beans and making coffee is a complex and communal ritual, verging on the sacrosanct. The etiquette has been built up over years, and even offers rival schools to subscribe to. We have Wiki pages detailing coffee brewing best practice and it’s no joke to say that my social standing and ability to make good coffee are linked. In short it’s a bigger part of my day than just a caffeine high.

I wasn’t a big coffee drinker by any stretch of the imagination, the coffee was definitely strong but I’d only have two or three cups a day. Nonetheless going fruit tea total came as a bit of a shock.

The first two weeks were pretty miserable, I found that I got very tired towards the end of the day, and where previously I might have stayed late if it meant finishing something off, I was pretty useless after 6pm. I also missed the ceremony and social interaction, sure I still went to the kitchen and brewed my cup of lemon and ginger (or whatever) but the whole process was deeply unsatisfying. I went through all manner of cravings which was strange since at weekends where coffee really isn’t part of my routine I hardly noticed the difference.

After having got through the hard part I started to notice some benefits, while the tiredness was still there, it was much more manageable, and crucially the knowledge that I couldn’t just stay late meant that I was more focussed during the day. I became more disciplined at trying to perform the tasks that required the most energy earlier leaving repetitive, less creative activities for the last few hours. Despite working less hours overall I think that I achieved a similar amount.

A second benefit that sounds silly in hindsight was that I started sleeping much better. As a student I wasn’t a big coffee drinker but I’d always been one to lay awake at night pondering some puzzle or other. So when this behaviour continued into my working life I didn’t consider it strange. Giving up caffeine meant that I had a fighting chance of falling asleep not long after I switched the lights out, which in turn meant I had less need for an early morning coffee.

As an Englishman, it was unlikely that I was ever going to last without tea in the long term. For a start my Nan would have struggled to comes to terms with the change. So after a few months I felt that I’d served my time and now allow myself tea and the odd coffee in the morning, interestingly though I can no longer run with my old coffee pals as the strength of their brew gives me headaches.

So the key points to take away are:-

Stopping completely after only a few cups a day led to notable and sustained withdrawal symptoms.
Not having the safety net of being able to stay late at work meant that I worked more effectively during the day.
Cutting out caffeine in the afternoon made a real improvement to my sleep patterns.

Kanban in practice

My team has been using a Kanban board to manage our day to day work flow for the past few months having switched from time boxed iterations, what follows is a description of how we use the board in practice. This post concerns itself only with day to day development and does not cover high level planning.

First some context. The team is made up of four developers, a technical lead and myself as project manager. We are responsible for the ongoing development, deployment, support and maintenance of six hosted products that are expected to run continuously. We would expect to release new functionality to the live environment a ‘few’ times a week.

The Board

Our is board is positioned in clear view of the team and we conduct stand ups in front of it.

The board contains 5 sections

Not Started – Stories we have committed to completing and that can be started at any time.
In progress – Stories where development and verification are underway
Ready to deploy – Stories that are ready to be deployed into the live environment
Done – Stories deployed live
Blocked – A place to track stories that have become blocked by parties outside of the team as project manager it is generally my responsibility to unblock these stories.

We limit work in progress in two places, currently we assign roughly a week’s work for ‘Not Started’ and a further week’s work for the combined total of ‘In Progress’ and ‘Ready to Deploy’.

We do not consider these limits to be ‘hard’ and will from time to time exceed them, however in doing so we will have had a conversation to ensure that we are happy to be exceeding the limit temporarily.

Stories

Stories are represented by post it notes, in addition to a brief description of the story each card is presented in a standard form like so:-

Size

Many lean practitioners view estimation to be a form of waste and therefore something to eliminate. Estimating is still valuable to us as it provides a means to build consensus over what the story entails, this is especially useful for less experienced members of the team who may not have considered all aspects of the story fully.

Project

While each story is a deployable artefact they generally form part of a larger set. By grouping projects in this way the story description can be simpler since the project itself provides context.

Dates

We record the date a story entered the ‘Not Started’ state, the date we began work on it and the date the story was deployed into the live environment. Doing so allows me to answer questions like ‘if we were to start a three point story right now, how long would it take to get it live?’, this in turn allows me to justify spending a fortnight on improving our deployment process as the positive impact is there for all to see.

Description

We try to keep the description as brief as possible, by ensuring that lead time is minimised to a few days it is practical to communicate decisions verbally. For complicated stories we can provide more specific details via a wiki or a tool like agilefant.

Pink Notes

In addition to planned project work we will receive a certain level of support and maintenance requests, that we represent by pink post its. These tasks are large enough to add up, but each one will typically take no more than half a day. Anyone within the team can create a pink note and we ensure that our board has enough slack to accommodate these new tasks.

New pink notes are discussed at stand up, after which there are three outcomes:-

The task has been prioritised and someone is already working on it (this is rare and occurrences should be minimised)
The task is added to our standard work flow and does not receive special prioritisation – we work on the assumption that our lead time is sufficiently low to respond quickly.
The task is removed and ignored. We explicitly do not use bug tracking software reasoning that tasks we choose to ignore when they are fresh in our minds are unlikely to be returned to.

The volume of pink notes is monitored so that more realistic estimates can be made for project completion as well as tracking gradual increases and decreases over time.

Maintenance

Smaller day to day maintenance tasks like reviewing error logs and looking into monitoring alerts/trends are handled by a designated maintainer. One off tasks that will take more than a few hours to complete can be added to the board as a pink note. The role of maintainer switches on a weekly basis amongst the developers and the aim is that the non maintaining developers can focus on project work and/or pink notes.

Performance Tracking

We attempt to track team performance over time so that we provide estimates for project work with greater confidence. It also means that we can track the impact of changes to the team e.g. what is the impact of moving a developer on loan to another team?

To do this we use two different methods. The first draws on Aslak Hellesøy’s work, and measures standard lean metrics such as lead time and WIP. The second provides some supplementary metrics such as finer granularity over what types of work were delivered on a weekly basis and finer granularity of lead time between phases. Aslak’s sheet generates a number of graphics, one being a cumulative flow chart which neatly visualises our recent Christmas change freeze.

A second sheet of my own making produces a chart for velocity, this is an agile rather than a lean metric, but I find it useful to track where we are spending our effort. The yellow ‘Total Velocity’ line saw tooths at about ~ 14 points, suggesting that we work to a fortnightly rather than weekly cadence. It also shows that during late Nov early Dec we spent more time on unplanned pink notes than we did on project work. Much of the pink note load will have come from outside of the team so it’s important that we have a way to make the impact visible.

The Switch to Kanban

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.

January 2010