Title: The Agile Chef - Part 1 Date: 2011-02-08 04:25 Author: eamonnfaherty Category: agile Slug: the-agile-chef-part-1
To get me through development I try to be the agile chef:
Imagine cooking a meal. You can split cooking a meal into smaller parts (not necessarily in order - I am not really a chef):
- sourcing the ingredients
- preparing the ingredients
- preparing the workspace
- preparing the oven
- making the meal
- cooking the meal
- serving the meal
Using agile methodologies we would tackle each part of this process individually and then tackle the next only once it is completed.
As a novice chef, he would tackle getting the ingredients; Knowing what he am making, he would make a list of the ingredients and purchase only what was needed. As an experienced chef, he would buy more than what was needed, adding some for unexpected accidents. Either way, he would have completed the first task and would be ready to start the second. Within this first step we have some technical debt, we have made decisions that we need ingredients and which ingredients. As a junior chef, if he makes a mistake with some of the ingredients he am stuck. He have not allowed for any extra ingredients. Even as the experienced chef, he could face issues if the person we are cooking for changes their mind he is stuck. These are the obvious problems. There are more subtle issues that could occur. Our agile chef could be preparing a meal for somebody with an alergy. He need this knowledge in order to buy ingredients but may not find this out until the serving the meal stage. At first it looks like the agile chef had an impossible task of sourcing ingredients for a meal for people he knows nothing about. This is where the ‘business product owner’ comes in. This is usually a stake holder who has knowledge of the current business requirements. In this case, it would be the waiter. When taking the customers order, the waiter should check if the customer has any alergies. This is a common problem with projects I have been on. The business product owner does not know all of the customer requirements. The lack of requirements gathering is often blamed on ‘being agile’ and ‘being light on planning’. This reminds me of a saying used a lot in my school:
If you fail to plan, you plan to fail
This first simple task of sourcing ingredients could have caused the whole meal to be a failure. This illustrates the importance of both the chef and the waiter in this scenario. Without both playing their part we would fail at the first hurdle. This is why we need help with our meal. We need somebody who knows the ropes who can give both the waiter and the chef advice, to ensure our meal is a success. This is where the head chef and the head waiter come in. They are responsible for ensuring we are doing all that we should be. In the engineering world I believe this role is between a technical lead, a technical architect and a business analyst. Without knowledge of how to lead a team how can this person manage resources, conflict and moral (a head chef checks managing in their). Without knowledge of architecture how can they ensure the team are not making decisions that will cause problems in the future (the head waiter knowing the menu and its ingredients).
So far, my agile chef is not looking too ‘agile’. He cannot succeed on his own. This is not what agile is about. Having a small team (or one/two people on their own) is not an agile principle. It is peoples expectation of agile.
To recap, our agile chef needs a head chef to give guidance and a waiter to check requirements. This waiter also needs help, this is in the form of a head waiter. In order to cook our meal we need four people! This seems a lot, despite how complicated the first step has been.