Pawel's Blog

Altitude sickness has taught me two important insights about speed and trends, which can be applied to software development projects (and probably many other areas as well).

Photo: Krystyna Kupiszewska

Altitude sickness

After trekking above approximately 3,000 meters one has to take care not to climb too fast. The general rule is not to ascend more than 300 meters daily to acclimatise.

If your organism does not adapt to the height you reached, several symptoms appear (headache, fatigue, stomach illness, dizziness, and sleep disturbance).

This once happened to me in Nepal. The symptoms usually disappear within couple of hours. However, in some cases they may be getting worse, especially if you climbed significantly more than 300 meters within a day.

Altitude sicknes is quite a simple illness. If a patient is feeling worse and worse the end is always the same – death The only reliable treatment is to descend.

Speed limit

The first general thing I have learnt from altitude sicknes is existence of hard limit on velocity. Attempting to get above this limit is asking for trouble.

This applies to projects and speed of development as well. I like to keep that in mind when planning software development releases. Usually there is hardly anything we can to quickly achieve higher output (I am not talking about long-term improvements here) and the only reasonable option is cutting down on requirements.

Trends

Moreover, the way altitude sickness develops and comes away shows that it is all about the trends.

For instance, a percentage of code coverage in your project is relevant, but it is more important whether it is increasing or falling. The same applies to more general matters like quality, moods, financial situation and so on.

If we are on the wrong side of the trend, doing nothing and just waiting for better time to come will not help, exactly like in the case of sickness getting worse and worse.

All in all, I find those lessons on velocity limit and trends very useful – much often than in the high mountains.

-Paweł

I used information about altitude sickness from wikipedia and altitude.org. 

This post is a part of short series “What a ScrumMaster Can Learn From a Mountain Guide”. I previously wrote about preparing breakfast and getting up from breaks.

Being a leader may sometimes feel like being an ambitious guy trying to sell the idea of getting up after the break and continuing hiking uphill to the group of exhausted backpackers.

How to make them stand up and go?

Stand up first

There is no other way. Just talking about any idea you want to sell to others will not work. You have to give an example, be the first one.

A mountain guide willing his group to stand up, stands up first, with a backpack on his shoulders, ready to go.

Photo courtesy of Krystyna Kupiszewska. On the photo: Jakub Organ

Make room

OK, so we have got most of people standing and almost ready (adjusting their backpacks, talking to each other, drinking water and so on).

Now, a non-obvious trick to make the “process” of starting smooth is to make few steps forward, then call and wait for them to move.

This is important because:

• if you just start walking you may end up walking alone and
• otherwise, if you just stand and wait right next the whole group you are actually blocking the way you want them to go.

Introducing an organizational change

From my experience introducing a change in the team or an organization usually requires following similar scenario. If you want others to adopt a practice, after showing them an example, you need to make some room for them to start.

Understanding this is important if you want people to self-organize, or even just take over some responsibilities.

A very simple example might be introducing a habit of documenting important things on a wiki. Or keeping an eye on continuous integration system. To make this ultimately happen you need to stop doing all of it yourself  (not to walk alone) and stop reminding about this every time. Otherwise you block room for progress.

-Paweł

PS This post and a previous one are part of “What a ScrumMaster Can Learn From a Mountain Guide” – something that may become a short series.