Climbing, especially Bouldering is an important thing for me. Climbing is not just about reaching the top. A big part of climbing is problem solving and to me it provides the perfect way to keep my head in shape.
Every route you climb is different and before you can reach the top you must first understand the problem. Some problems are easy and you top them with the first try, but some are more complex and you need multiple tries before you are able to solve them.
To me this same mentality and the logic used in solving a climbing problem also applies to Agile software development Sprints. If you are not familiar with Agile software development methods e.g. Scrum, a Sprint is a short (Normally 1-4 weeks) period of time during which a development team selects a set of problems and produces working software features.
Planning your first ascend
A New route is a project with an expected outcome, but without a clear understanding of how to get there. You start with the information you have and with that information analyse the possible moves needed and plan your first ascend.
Basically this is the same thing you do in Sprint planning. Based on the empirical information you have you plan what could be done and what possible tasks are needed.
First try
Once you think you know how to approach the problem you start your first ascend. You execute the moves you taught would be needed and steadily start to ascend towards the top of the problem. The tougher the problem the bigger the possibility that at some point your idea on how the route should be approached was not correct and you end up back to the ground and need to review and reflect what else is needed.
During a Sprint based on the stories and tasks we have planned we start solving the problem(s) and building new features. But as things progress we learn new things and might need to re-think some of our planned tasks and solutions.
Re-thinking the moves
After each time you fall it is important to understand why you fell. Did you ran out of strength, did you try the wrong move or was your balance on the wall wrong? Once you figure it out the important thing is not to get stuck in what you did wrong. Instead you focus on what you need to adjust to get past the problem spot and also get better in what you are doing. Usually the best way to reflect is to analyse together with another climber and climbers like to help each other.
When doing a sprint review we have not “fallen” like when climbing. We have not automatically made a mistake we are reflecting, but the analogy is still there. We have the reviews in order to see what needs to be adjusted/changed in the build solution.
Helping each other to become better
We also follow up the reviews with retrospectives where together we think about the progress and how we can become better. As part of the problem solving process we want to get better and we want to work together to make each other better as well. Better individuals, better team, better results.
The solution is out there
No matter if climbing or working with software features, there is no better feeling than solving a complex problem what has required a real effort. The more complex the problem is the more it might require time and effort, but in the end there is always a solution somewhere.
Nalle Hukkataival, a famous Finnish climber said it really well after sending one of the world’s most toughest boulder problems “The Burden of Dreams: “Not succeeding is an important part of the process. The most memorable things in life are not the ones that came effortlessly—no matter how impressive—but the ones you struggled with and overcame in the end”
