How rock climbing, cooking, and weight lifting help us relate to software delivery.
Incremental, iterative, sprints. Whatever word you may use, the whole point is, as the agile manifesto says to Deliver working software frequently. The key here is working not necessarily perfect_. _Using the words just mentioned or even the word _agile_ can cause some confusion. One of the most common aspects of confusion for people not wanting to deliver incrementally and pushing a large amount of changes into a future release is _Aren’t we agile, let’s be flexible_. Of course, this perception of _flexibility_ ends up hurting the team in the future because many changes are pushed through one big release. What this means is if something goes wrong we’re simply guessing which change caused the bug.
Here are a few analogies I’ve been working with to help people understand the importance of frequent delivery.
Cooking a new dish
When first learning to cook a new dish. We get the ingredients, read the recipe a few times, cook the dish, then eat it. We do not cook the dish then throw it away. No, we eat it, invite others to taste it then get feedback. After getting feedback we go through the process of cooking the dish again. The second time around, the dish will taste better, the third even better. Until we’ve become so good at cooking this one particular dish that we can cook it perfectly and quickly.
Imagine for a few minutes that you did throw away the dish the first, second, and third time you cooked it. Then you decide on the fourth time that you will eat it. Not only is this a complete waste of effort (and food) but the dish wouldn’t taste good because we may not be making the right changes on subsequent methods of cooking.
Anyone wishing to increase a certain lift will attempt progressive overload on that particular lift. Say your goal is to be able to deadlift 100kgs. You will not lift 20kgs on Week 1 of your training program, ignore deadlifting for another 16 weeks then attempt to deadlift 100kgs on week 17. If you do this, you will get injured, you will fail the lift.
You may be doing support exercises that can help your deadlift like good mornings or squats for 16 weeks, however, these are still not a deadlift. On the other hand, say you increase your deadlift by 5kgs every week for 16 weeks. By the 17th week of your training program you would’ve reached your goal of 100kgs.
When climbing a wall we look for rocks that we can grab onto sturdily with our hands and step on with our feet. After we’ve raised our bodies up and are stable, we then look for the next set of rocks. Climbing like this, ensures that we have a position of safety instead of blindly climbing up a wall hoping that the appropriate rocks will magically appear in the right position directly above our bodies.
All these examples above illustrate an important reason for frequently delivery. That is, increasing the known environment by creating positions of safety. When software is released frequently with small changes, we can revert back easier, we increase our known environment (by limiting introduced changes), and have something to fall back on if a deployment can’t happen.