A couple of weeks ago I arranged an “Agile cooking” session for my colleagues in my home in Lorenskog, just outside Oslo. The plan was to have focus on agile methods and combine it with cooking and social gathering. My colleagues are very open-minded and the meetup was very good indeed, 10 out of 12 showed up. Planning was started a few weeks before the session, on our company wiki, were we discussed which food to cook, agile techniques. Since we were all going to cook, we decided to make tapas and so, a tapas backlog was created on the wiki…..
The backlog was filled with tapas dishes proposals and a simple voting determined the priority. This way we could go into the session with a prioritized tapas backlog, so that we new what to start on.
I believe that this is always a good idea but oftentimes this is not the case in the software industry. If you are going to do agile software development it is extremely important to work continously with the backlog to make sure that it reflects the needs of the organization. Too many times I see that this work is neglected, so when going into the iteration planning people end up discussing the product backlog instead of discussing the stories. Our agile cooking team was not going to fall into that trap.
At the day of the session, my boss and I met early to do some preparations. Primarily, this meant buying the ingredients needed for the tapas dishes and drinks. Luckily, we found a huge super market were all the ingredients were found. After a couple of hours shopping we went to my place and arrangesd so that everything was ready when the rest of the crew arrived.
I think that this is something we can learn from when doing agile software projects. We want to minimize planning and preparations but you need to do enough of these activities to avoid chaos. Having a development and test environment ready when starting a project can never hurt, and if you also have a continous integration environment set up, then you are certainly on the right track
Estimating the backlog – does planning poker help when cooking?
Since we had quite a few tapas dishes in the backlog I had an idea that we could do a planning poker session to get a rough feeling about the complexity with regard to the various tapas dishes. I do think that cooking is a good example to use when explaining planning poker, but applying planning poker to figure out how many tapas dishes to cook is probably not.
As in all software projects, planning was delayed due to the fact that some of the participants were held back at work. So after a round or two of planning poker we realized that if we were to get any food at all this evening then we had to skip planning and just start doing some real work…..
10 people, one kitchen and a terrace with a newly aquired gas grill, a product backlog but no plan. Could we avoid chaos? Since we already had wasted a couple of hours on chit-chat, drikning beer and discussions on whether planning poker is any help at all, we decided to timebox the actual implementation phase. One hour was decided to be enough. Faced with the fear of not having anything to eat that evening, each of the team members started picking and delivering tasks, cutting vegetables, making spicy meatballs, setting the table etc. If people were unsure of which tasks to pick other team members were consulted, very much like self organizing teams.
At 2115, 15 minutes late, we sat down and enjoyed some very tasty tapas dishes (I believe 13 dishes were delivered).
The agile cooking session turned out to be a success. We managed to eat before people starved to death and the food was really good. Having a prioritized tapas backlog prior to the session proved important, so did the preparations. The planning of how to cook the dishes were heavily delayed and since the group realized that planning would most likely means a very, very late dinner, this planning was skipped. This is important and conforms to one of the most important principles of the agile manifesto, responding to change over following a plan.
The team members did commit however, to delivering as much food as possible within the specified time limit and were very motivated indeed. This is equally important and true for all kinds of projects: You may have the best plan in the world, but if you don’t have the right people with the right motivation, then you are almost certain to fail.