Version 1.0, as per Adrian’s request 😉
There is much debate between traditional and new project execution and project management methodologies. It’s like the old proprietary vs. open source debate. I, personally, think each has its own purpose and applicability …
The gains of agile methodologies are delivery speed and decreased cost. But are heavily reliant on three “variables” – same as the resource/time/scope traditional project management:
1.- professional knowledge level of the team members within their domain area of expertise
2.- interpersonal dynamics within the team (collaboration, no conflict), including company culture
3.- tech.tech.tech. Architectural patterns and standards, needing to be prescriptive
I’m also hoping the example bellow also highlights that there are some immutable requirements that cannot be touched later on. My personal preference is to execute an iterative waterfall before going into full agile mode. The examples and analogies bellow try to highlight some common issues with agile.
But in essence, at a very high level, this is how I’ve explained it to my 13 years old son:
Spoiler: When you don’t really understand the whole mechanism, you don’t understand its benefits. Agile can keep customer happy, increase throughput and revenue – it’s doing MORE with LESS in effect.
Epic story (pun intended):
There is a nice Italian Pizzeria (perhaps sometimes they even have Chianti-NFR)
The customer comes in and orders a pizza. There is a set menu, but also the option to customise the pizza (we actually used pies but pizza will do). Regardless of what option he chooses, the process will end up with the customer making up his mind and ordering, after which the cooking process starts.
Scenario 1. (waterfall and iterative waterfall – to a certain extent – phase and architecture constraints)
Customer wants pizza on thin crust, olives, capsicum, onion and salami, with tomatoe sauce. Browses the menu (doesn’t matter if custom or select-ready) and orders a medium $12 pizza. He is gluten intolerant, so he already explains when ordering, for the pizza base to match his requirements (the immutable).
The cook makes the pizza base, then tells the kitchen hand to start chopping the ingredients, then combines the ingredients, cooks the pizza, and delivers (release).
Customer takes the pizza, takes a bite, and remembers he has a date that evening, so can’t really eat it because of the onions (might make his breath smelly) , but it’s still hungry and wants pizza.
Pizza throw away. Customer wastes 20 minutes and $12. Then he orders another pizza, without onions, and pays another $12 dollars, then waits another 20 minutes for a new pizza. Not too happy. Can’t think about seasoning or Chianti – now he’s on a time strain with his date (race to market)…
Total cost: 2x = 40 min and $24
Scenario 2. (agile)
Customer wants pizza on thin crust, olives, capsicum, onion and salami, with tomatoe sauce. Browses the menu (doesn’t matter if custom or select-ready) and orders a medium $12 pizza. He mentions the gluten intolerance, and pays for the order.
The cook prepares the base dough, with the immutable gluten-free (you need a solid base to start building anything!!! – customer is either gluten intolerant , or is not)
All ingredients, , ready to cook, then customer says – can I change my mind and have a regular crust. Waiter goes to cook and cook says SURE, that will be another $1 as I need to add more ingredients for more dough. $1 and 1 minute added.
Cook tells the hand to chop all the items the customer ordered, in separate bowls (proper written stories). Cook ready to mix the ingredients, customer now remembers he has a date and asks if he can swap the onions with jalapenos. Cooks says yes, tells the hand to chops jalapenos instead, that will be $2: $1 for the chopped onions throw-away, and $1 for the jalapenos. Then mixes the ingredients and puts the topping on. $2 and 1 minute added.
Cook is ready to put the pizza in the oven when the customer says can I please have a message written on it by rearranging the ingredients. Cook says ok, I’ll throw that in for free, all I’m loosing is a minute. 1 minute added.
Cook puts pizza in the oven. Now we’re cooking! Cook pulls out ready pizza from oven. Customer asks if he can have BBQ sauce and parsley instead. Cook says sure – I haven’t used the tomatoes sauce yet, so no charge, I can just replace it with BBQ in the same cost. Tells hand to chop fresh parsley and tops it, then puts it back into oven for 30 seconds. 30 seconds added.
Release: Cooks pulls finished, fully customer-requirements pizza and delivers (Release).
Customisation: Client can add salt, pepper, and maybe even tobasco for free. Sometimes, he want’s a glass of nice Chianti to go with it (nothing to do with that pizza itself), which he is happy to pay for (support).
Customer changed his mind a lot (another immutable, in a different perspective, but that’s another story). He got what he wanted in the end, despite not being quite clear or changing his mind along the way (various reasons: market forces, tech requirements, innovation ideas, forgotten requirements)
Total cost (agile) : Total cost: ~x = 23 min and $18
Total cost (traditional): Total cost: 2x = 40 min and $24
Savings: Total saving: ~x= 17 min and $6
Advantage Differentiation – customer is happy with a saving of between agile and traditional
Counter Advantage Differentiation: if not supported by executive leadership: Pizzeria boss is only interested in revenue, so prefers to get $24 dollars for 40 minutes. What he doesn’t realises is that the cook will be as frustrated, and even if he gained another $12 dollars, the customer might be unlikely to come back if he’s not allowed to change his mind (refer customer mindset change research, competition) . He also doesn’t realises that the equation is in fact:
Gained $6 and lost 3 minutes
Gained 17 minutes and lost 6$
$/min = 0.6 .
Result: (given next customer ready to order) is more revenue due to more serviced customers within the same time-frame (lost $6 but gained 17 min to service another customer – ie, opportunity to gain roughly 30 dollars and save 3 minutes at the SAME TIME) AND an awesome customer experience – ie, guaranteed business for a while.
Resource burnout: cook might get angry if he has to deal with this all day long
Resource mindset/cultural fit: cook doesn’t mind if he has to deal with this a lot
Waste: we got rid of the onions (although the code written might have some shelf life and we can reuse in the next pizza
Imutables: Docker containers cannot run on Windows (yet)
1. Staff quality – cook is patient and experience enough to know that the customer might not be clear. So is the waiter.
2. Team gelling – cook and waiter have been doing this for a long time, actually they have steak and wine once a week together and talk about fishing, all which they both enjoy
3. Tech– if all equipment is same in the kitchen (architecture , standards, patterns), then only one really good skill and one set of staff is needed: the cook, the waiter, and the hand. Different equipment (ovens, mixers, etc) will yield different results, therefore either more staff or multiple skills are required (see resource burnout and staff quality)
Unclear cards/stories: – customer comes into store and says “I’m hungry!”
Leadership and executive support – if the restaurant owner doesn’t get the maths and the potential of keeping the customer satisfied, increased revenue, and uniform resourcing, and doesn’t provide prescriptive support for it, then all is lost
That’s all folks. It’s Friday, after all …