Skip to main content

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 perfectUsing 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.
Rock climbing. Source: WikiMedia Commons

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.

Weight lifting

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. 

Rock climbing

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.


Popular posts from this blog

from zero to production in eighty days

When I mean zero, I literally mean zero. A brand new project, a PO that's new to IT, no existing processes in place and a small team of four including myself and the PO.

The departmental organisation we were working for doesn't have any developers, scrum masters, product owners working for them. Everything they did was either done by another department or outsourced completely.

This is a story how we went from zero to production in eighty days.

Have You Ever Produced Negative Value in a System!?

As developers we encourage our product owners to order the priority of their backlog in order of value. However, every time a new feature is implemented by a development team, there is a certain degree of risk associated with the introduction of that new code. Namely, risk of breaking another part of the product and maintenance cost. When a development team pulls in a new feature to implement there is a certain acceptance of this risk. In many cases, the risks that arise due to additional code complexity doesn't justify the value added by the new feature itself, so the development team can start implementing it.

Are there scenarios where the value added to a software product can be negative though?

I Don't Know

Many people who come from command and control working environments have a very limited circle of safety. This maybe because their suggestions have been discarded rudely, being treated poorly, or always fearing for their job. They do not suggest improvements and are often too scared to ask for help.