I am very grateful to destiny for introducing me to rock climbing. These indoor climbs are ascents to the top of a building wall which can be 40 feet high. Routes can also range in difficulty by type of grips and techniques that must be used. Some climbs leverage ‘naturals’ or the surface instead of being all hand holds. I have just done this a few times and already I see some great things about being able to take away and bring into the agile context. We ever talk about scaling mountains of problems in an agile way…
Not all facilities are auto-belay. The belaying is often done with a partner which can put the brakes on the rope you use to climb. This also makes for a great trust building exercise. Trusting not only in someone who literally holds your safety in their hands, but in the equipment that you’ve checked out as well. Your partner is also someone who can call out advice for holds you do not see, or a technique that does not come to mind. The same happens when we pair program or pair create tests. How quickly can we think upon the problem at hand and continue to communicate as we develop the solution. Climbing is after all a physical problem to solve. Plenty of other people have been up this same route without fear, or hesitation. How did they do it, what hold is next? Programming is thought work, and every so often I may find myself thinking ‘let me go work on this and I’ll get back to you’. It mostly means I am not being flexible towards teaching, learning or sharing in the solution right now. We become a better team when there is trust between the climber and the belayer who holds the other end of the rope that will catch you when you fall. In pair programming we trust in the patience, focus, and desire to solve the problem at hand. The climb to the top or even just the next handhold. Sometimes we just need a bit of motivation as physical exhaustion starts in during some of the more difficult climbs. Even then I am an active participant invested in the success of the reaching a goal. Even if I am not the climber I am learning technique from occasional climbers which are more skilled, sharing with climbers less skilled or simply challenging one another as equals. Challenging with the intent to grow ourselves into better climbers, programmers, problem solvers…
Focus Near and Far
It happens occasionally. I come across an complaint or gripe about the program, or a team, or even an individual. It takes hold and we focus on the can’t, what we are NOT doing, or the 100 critical questions that halt us in our tracks. Distractions abound. Sometimes I have to remind myself of the end goals, sometimes I need to focus on the next hold or step. Motivators come at different intervals. That interval often depends upon internal needs and external perceptions. If my progress is quick my focus is usually far, If I feel stalled out or blocked then it is the single next step I am looking at. We can all use help now and again with our tempo, and sometimes it comes with experience and consciously striving to improve every single time. Everyone is present to make the team better, adopt the best solution, create the best software they need it to be. If you stall on a climb on a hand hold, it is a matter of time before strength gives out. We are repelling back down eventually to go after something easier, or simply recharge. We are still the better for attempting more and more difficult challenges. Learning something every time we do. The practiced ease which turns learning into reflex allows us to learn even more beyond what we were taught. Alternate between near and far and use each to their advantage. How far might far be? We cannot see the sun directly, but by it all things are seen. How about not the next climb but the next several.
Climbing routes are rated for their difficulty. They start out around 5.4 and work their way up to 5.8, 5.10, and 5.13… A 5.4 would be easier with larger and numerous holds to grab and step upon. A 5.9 might require much greater finger strength, some varied techniques, and perhaps simple physical endurance. Climbers are usually practicing to move up into the more difficult climbs. Developers and Testers do the same thing as well. further into the architecture to improve it and make subsequent work far easier and more robust. Further into different areas of testing to qualify and characterize the software at different scales or more quickly than we had the ability to do before. What techniques have we added to our experience to draw on as we move to the next climb, be it a release or a sprint? Maybe it wasn’t a skill so much as a process. If you started with a fear of heights, then isn’t the goal to simply gain enough experience that the fear is crowded out by continuous perception, reasoned evaluation and finally smooth execution?
A Target Indirectly Hit?
I want better teams, better practices. Does the ability to pair program fall under a near term goal that will improve several things if this is done well? Several small techniques to practice and on the whole the interaction and the ability to tackle more complex problems becomes apparent. It is usually why agile stresses breaking down into actionable, move forward steps. The experience helps us as we continue onward into the more complex. Then the focus at times flips from those who cannot climb fast enough to those who might not have taught others fast enough. A sense of balance, timing and care is ever critical when climbing on small holds up a vertical stretch of wall or mountain.
“Character cannot be developed in ease and quiet. Only through experience of trial and suffering can the soul be strengthened, vision cleared, ambition inspired, and success achieved.” Helen Keller, who was blind her entire life, knew exactly what a clear vision truly meant. It enabled her to climb past the obstacles that seemed directly in front of her and not only live, but also influence the direction of so many other lives.