Tuesday, October 1, 2019

Polar Expeditions and Agility: The 1911 Race to the South Pole and Modern Tales

This article was originally posted on  on the OCTO Technology blog
A polar expedition and an IT project have much in common. They both share a goal, a team, and constraints. They share risk management issues, as failure is always a possibility even if the stakes are different. They also share a special relation with tooling and the influence of leadership style. But they mainly share the importance of the philosophy under which each project is undertaken.
We will see in this article how the approach taken to face a challenge can have tragic outcomes. And how the fantastic race to the South Pole in 1911, or modern polar explorers methodology, can relate to our daily IT experience.
My personal life as a software developer, a data scientist, a team leader and now an agile consultant is every day influenced by my ten years experience as a polar skier, and even more by the giants on whose shoulders I stood.
Vision, team, leadership, decision making, continuous improvement, tooling… The source of inspiration never ends. This post is an attempt to share some of it.
Slides are also available on slideshare.
Amundsen (left) and Scott (right) teams reaching the South Pole. But the story is not over. Credits Olav Bjaaland and Lawrence Oates.
“Victory awaits him who has everything in order 
— luck, people
call it.
 Defeat is certain for him who has neglected to take the
necessary precautions in time;
 this is called bad luck.”
Roald Amundsen [1]
“Our luck in weather is preposterous […]
How great may be the element of luck
Robert F. Scott [2]

Addressing challenges: big corporations vs. startups

In the early twentieth century, the arctic regions were the last ones yet to conquer. European big powers had more or less finished to colonize the world and their once shining stars were slowly fading out. Among the challenges of those days, being the first to reach the South Pole was the greatest: a two thousands kilometers round trip in the coldest environment possible. At the time, it consisted in sending a boat with a party that would winter on the shore, making leaps inland to build intermediary food depots before launching the final assault. For almost one year, no contact would be possible between the explorers and the outside world. It looks pretty exciting, doesn’t it?
The most powerful empire of the time could not see the South Pole escapes, for commercial and prestige reasons. And they addressed this coveted challenge in the way which has historically brought success: sending the Royal Navy, with an expedition led by Captain Robert Falcon Scott.
But the Arctic was not only haunting the Admiralty dreams and those of ambitious captains. In the recently born Norway (which acquired its independence from Sweden kingdom in 1905), seamen were also relentlessly attracted by the frozen lands. Among them is Roald Amundsen, born in a family of shipowners from Oslo. He had therefore grown up in environment inclined towards outdoors and have learned young to become an accomplished skier. In 1906, he proved his skills as an explorer by breaking through the Northwest Passage, sailing the Gjøa with a team of thirteen from Canada to Alaska. If his financial means had nothing in common with those of the Royal Navy, he, also, was dreaming of being among the first men to set foot on the South Pole.
Both expeditions were backed by strong cultures. Shall it be the British Navy history and its conquests, the undisputed master of the oceans. Or shall it be his Viking ancestors, the inspiration of the greatest explorer of the time (of all times?) Fridtjof Nansen or the energy boiling at the birth of the young norwegian nation.
In summer 1910, the Terra Nova set sails from Cardiff and Fram from Oslo. An historical race was launched, a tour de force of courage and endurance, but also, as we will see, the direct confrontation between two radically different styles.
Big corporation vs. startup. The confrontation between the two styles also appears all over the IT world. Company culture, financial means, intrinsic motivation have direct influence how projects are conducted, shall they be driven by a top-down processes or in a lighter, more adaptative fashion. But one shall not forget that if the organization size certainly correlates with corporate  philosophy, it is not by far the critical driver. Humans are.

Robert F. Scott (left) and Roald Amundsen (right).

Vision

“Scott was marshaling his forces 
for a ponderous campaign,
while Amundsen was sailing on a raid”
Roland Huntford [3]
Any project shall be carried by a vision. Often verbalized as a short sentence. The statement is framed to share the project purpose inwards, to the team, and outwards, to stakeholders. Towards external stakeholders, so that anyone can simply understand the long term goal, the why and the how. Towards the team, so members can use it as a compass for decisions and fuel for motivation.
Scott and Amundsen of course expressed their goals differently. A lot have been written on both explorers personal motivations, but we shall focus on what was actually publicly shared.
Both men wanted of course to reach the South Pole and claim it. But Scott’s mission purpose was more intricate, as it also engaged scientific data collection and another expedition, lead by Campbell towards King Edward VII land. Moreover, in many writings, Scott has described the polar journey as the ultimate way to prove the bravery, the strength and the superiority of the so called “british race” [3]. Playing by the Navy book of the time, Scott’s views, doubts and ideas were not to be shared with his men. It was seen as the officer in chief to make decisions and to the men to implement them as told.
On the contrary, Amundsen played a totally different piece. His goal was clear and loud: “Going to the pole and back” and a map with the major steps of the expedition pinned on the chart room’s wall, “for everybody’s use.” Emphasizing “and back” in his statement made it clear for everyone that the return trip was a crucial leg of the plan and shall be accounted for since the beginning (this sounds trivial, but is in radical opposition with Scott’s view, who bluntly hoped for the best, as we will see later on). Moreover, Amundsen’s ambition was to reach the South Pole for the unique sake of it, and that makes him the father of modern sport expeditions.
A vision has been stated, more or less clearly, it is now time to assemble a team to realize it.
Any IT project shall have a clearly stated vision. If it may sound too obvious, experience shows it is rarely the case. Most of the times, management might have a vision, buried “somewhere in a Powerpoint slide deck”. Once found, it often happens to be a long intricate sentence, a pile of generic verbs and buzzwords.And from the development teams, the message is even more blurred. One experiment you can make is to ask everyone in a team to write down on a post it the overall purpose of their current project (why? what?). Wait five minutes, stick all the notes on the wall and appreciate if you effectively have a shared vision…

Assembling a team

“There were many men, shoved at random”
Edward Wilson, a Scott’s companion
“The wrong companion is infinitely more dangerous
than the worst blizzard.”
Roald Amundsen
“A small team of chosen specialists”
Roland Huntford, on Amundsen [3]

Recruitment

Once more, the two approaches greatly diverge. Scott’s views on how to assemble a team were not explicit . If we refer to his companions words, coherence was not the primary driver. The assembly was driven by upper management influence, previous expeditions, personal resents, shipmen volunteering, rank balancing and expertise.
On the contrary, as an independent entrepreneur, Amundsen was freer of a commanding chain or external sources of influence. Neither was he constrained to a closed pool of men (such as the Navy or Army personnel). And of course, like Scott, he was influenced by his previous expeditions. As for most of recruitment campaigns, a four steps process was set up: a) advertise position openings; b) receive resumes; c) check references; d) conduct interviews. This looks familiar, doesn’t it?
Even though Amundsen was seeking for the most skilled experts in every domain (skiing, navigation, dog driving etc.), he also wanted to build a team he could trust as a whole and not only an assembly of fearless heroic experts. And letters from interviewees are enlightening on his process. He devised an insolvable situation concerning dried fish, to see who would stand up and simply say: “I don’t know how to do that”, and was actively plotting questions to figure out who would be able to answer in the face of their boss: “I cannot do it.”
If Amundsen’s method looks rather sound in retrospect, let’s not forget the context, when assembling a ship crew for the most daring adventure in the beginning of the 20th century. For that, again, Amundsen can also be saluted as an innovator.
The IT world can be a perfect mirror of the situations described above. Too often are teams assembled at random, driven by personal agendas and dismantled after a project. Too often a “hero” is looked upon as a savior to a failing project, but will most often be no more than a temporary bandage (and maybe a powerful team spirit undermining).
In fact, a team is an interdependent system, performing best when members, as good as they can be, can expose their technical weaknesses and seek for help around them. One leader’s role is to foster such an environment.
If a certain level of skills is a requirement for a job, we can easily pursue the Amundsen’s strategy during interview. And push a candidate into situations where “I don’t know” is the only answer left, or watching how long they will hesitate before jumping on Google to seek for an answer during a coding evaluation session.

Team organization

“Lt Ewans, Campbell and Wilson have formed
 a sledging committee
and I am nominally the 
secretary […] with not much to do.”
Cherry Gallard, a Scott’s companion
“It was the most astonishing boat
 I have ever seen.No order
were given but everyone
 seemed to know exactly what to do.”
A pilot on Fram [3]
As soon as a goal has been set and a team assembled, realization could start. Two strategies were opposed: top-down or self-organization.
At this stage, it should not be a surprise which strategy was chosen by whom. A British Navy officer carried wisdom and knowledge on how to implement his decisions. There was a Book by which the rules applied and usages in place (such as gathering a “sledging committee” to finally make no decisions).
Amundsen’s pattern was about delegation. Once the goal stated, the decision shared as clearly as possible without much implementation details, a task owner was responsible and accountable for its completion. There are many reports from his men on his approach, and one of the most striking one of them was written during the Gjøa epic journey across the Northwest passage: during three years, no direct orders were explicitly given, although everyone on board did know what to do to implement the Captain vision.
Amundsen’s party was also driven by the rule that everyone must participate to the common tasks, and no one was above or below any of them. For example, everyone would clean the dog excrements lying on Fram’s deck, Captain included.
Olav Bjaaland was hired as a champion skier, a carpenter and a ski maker. The boss would not show up in his shop, except if  requested. [3]

Leadership

“Myself, I dislike Scott intensely […]
He is not straight, it is himself first, the rest nowhere.”
Lawrence Oates, a Scott’s companion
“Discipline was instinctive. […] He often used to say that on
board all were captains and all crews […] But nevertheless
nobody was in any doubt who was the chief on board.”
Helmer Hanssen, an Amundsen’s companion
It’s hard to overdo those quotes…
When Scott was backed by an explicit authority and a formal set of rules, the Norwegian shaped a more implicit style. The English flavor was easier to implement, as it was referring to reproducible standards, meanwhile Amundsen’s authority had to percolate differently. And one could see this second style act as a strongest cement. Stronger on an emotional level, but also on a practical one: if rules are enforced, it is hard to blame anyone for seeking ways around them.
On the contrary to British situation, few reports exist about tensions within the norwegian party. There were nevertheless some disagreements between Hjalmar Johansen and his leader, illustrating the fact  that no team is ever perfect. But one vigilant observer could note that Johansen was the only team member not selected by Amundsen himself, but taken on at the request of Nansen.
Under Amundsen’s party (left), captain and crew are to share an equal level of space and privacy, while Scott’s is driven by the Navy’s rule, where comfort comes with rank.
On the paper, many managers welcome delegation of responsibility and accountability. And everything is perfect in good weather.
In the best situation, an equilibrium is reached by the team to deliver a software at regular pace and quality, with iterations and features flowing down. Developers can explain the customer value of features they create, demos are applauded by everyone.
However, such an equilibrium can easily be disrupted by upper management layers: shortcutting the once beloved Product Owner to get features “done quicker”; adding extraneous constraints  (even absurd technical ones); pressing everyone to do “more points per week”, and digging the technical debt for short term victories. A different posture can be adopted: “the business deadline is approaching and we are are going to miss it. What features can we removed? Hei techies, what solutions do you propose so that we ship a valuable product in time?” But autocratic and micro-management reflexes are sometimes strongly sticking.
But to be fair, extraneous perturbations are not the only risk for a self-organized team. To many people, it is discomforting not having someone dictating every steps, every task and every process. If decision delegation means accountability, it also requires a lot of self discipline. Self discipline instead of a Book of rules, the path is not easy

Tools to move

We have discussed until now about vision and team organisation. It is now time to focus on the daily bread of any expedition team: tools. Clothes, food, camp, navigation: everything is tied to equipment quality. And “how to move” scores high in the priorities of a polar traveler. If nowadays such discussions are still passionate, one can imagine the dilemma at the dawn of polar travels.
The problem looks simple: X must move from A to B in the fastest and safest manner. The ground is of snow and ice, often uneven, and sometimes (in the Arctic) broken by open water channels. Simple, no?
During the preparation of their expeditions, both Scott and Amundsen spent plenty of time thinking about the best equipment to move on snow. They both had access to the same resources, the same information, the same technology and prototyping opportunities.
The first reflex in such a situation was naturally to turn to experts to seek for advice. At that time, the most successful polar explorer was without any contest Fridtjof Nansen. He had led a team across Greenland in 1888 [4] and the epic Fram Arctic drift between 1893 and 1896 [5], before embracing an amazing public career rewarded by a Nobel Peace Prize in 1922. Being Norwegian and a strong Amundsen supporter, he also had the honesty of providing both explorers with the same information whenever they were asking: how ski and dogs were the solution and a Siberian contact that would sell them the best animals – “dogs, dogs and more dogs” [6]. Less accessible but even more experienced were the Inuit people, to whom moving on snow is not even thinkable without dogs.
So the answer to a simple question “how to move on snow?” looked simple: “use ski and dogs.” Almost.

The cost of tradition

“No Ski. No dog”
Sir Clements Markham, 1888
Father of  modern British Antarctic Exploration [3]

To paraphrase a french show by Les Inconnus [7], there are two categories of traditions: good traditions and poor traditions. The first one produces technical excellence, patiently shaped through time by trials and errors. The later one is stuck into beliefs and looks at the world with blinkers and certitudes. It can still be true in modern polar exploration, at a lower scale, but the phenomenon was exacerbated at the time.
Even if all facts were advocating for the use of dogs, Scott looked down on the animals. To his defense, he was immersed in a culture emphasizing the supreme merit of the British (and more generally the westerners) over the rest of the world. He repeatedly wrote his defiance of dogs [3], how they could not be trusted nor managed and their vicious passion for fighting.
Scott finally embarked dogs, but also manchurian ponies and even motor sledges. However, he was ultimately betting on man hauling to reach the Pole. The ponies were of poor quality, bought on a second grade market, and even if equipped with custom snow shoes and cover with coats, they quickly died. The motor sledge destiny was even shorter. One fell from the ship at offloading, while the other was abandoned after merely eighty kilometers. Once again, we see the lack of vision, of focus, with the multiplication of solutions and none taken seriously.
On the contrary, Amundsen transport strategy was simpler. He focused exclusively on dogs and ski and put all his team energy towards mastering these two complementary means. Even though dogs were eaten on the way back when they proved needless (a common practice by the time), his writings are full of enthusiasm and empathy with his animals.
Guess who is is who, and which team had to rely on man hauling for most of the journey.

Focusing, apprehending and perfecting the tools

Wisely selecting a tool is a crucial point. But it is only the beginning. The team has to discover, learn and then master it. Amundsen pushed his team in continuous training, emphasising technical improvement on skis, sledges, clothes, food packing during the depot laying parties and the long winter night. Once more, Scott downplayed preparation. Even if he followed Nansen’s advice, hiring the Norwegian skier Tryggve Gran, he gave to Gran little influence on the overall team, preferring to rely on football sessions for physical training.
Even in modern expeditions, most of the preparation effort is not focused at first  on physical training but on selecting and perfecting the equipment.
Let’s now step aside our 1910 race for a moment and embrace a couple of other aspects critical to the failure or the success of a polar expedition.

Innovation

We discussed in the previous section about embracing the best technique of the time and improving it in the sake of better fitting one’s particular needs. However, times come when innovation is necessary. Innovation have different flavors, and as disruptive the outcome can be, it rarely if ever falls out of blue sky [8]. It often results from the synchronisation of previous experiences, a receptive environment, an adequate timing and a catalyst innovator.
Nansen sticked a mast and sails on his sledge for his 1888 Greenland crossing [4]. More than one century later, we experienced different kiting techniques on the same lands.
When facing the challenge of crossing an “ocean of snow” like in Greenland (or in Antarctic), one can focus on the word “snow” and head for ski and glide. One could also note the word “ocean”. And what have men done for millennia to move across seas? This observation convinced Fridtjof Nansen to give a try at using sails for his amazing crossing of the Greenland icecap in 1888 (where dogs, for practical reasons, were not an option) [4]. Even though the practical realization was not easy, Nansen made a major step, which has been endlessly improved until nowadays. And still can be…
If using sails to cross oceans of snow can be seen as a natural evolution, some innovations are more disruptive. And let’s now head North for a moment and meet the King of modern polar expeditions for an illustration: Børge Ousland
The Norwegian Børge Ousland crossing open water channels. There are crucial obstacles on the arctic ice pack and we see Ousland hoping for the best on ski, fearlessly paddling across or finally swimming through. Credits Børge Ousland/National Geographic.
Traveling on the arctic is radically different than on the southern lands. There is no more a static icecap, but a tormented, ever moving ice pack. Open water channels are recurrent obstacle to overcome, and no one knows that better than the Norwegian Børge Ousland, once quoted “arguably the most accomplished polar explorer alive!” by the National Geographic [9]. His accomplishments, both in the Arctic and Antarctic are unrivaled [10]. Of course, his physical and psychological strengths have been key to his numerous successes, but also has been his imagination to overcome obstacles.
The “classic” way in front of a water channel, is to circle around, losing hours and eventually days. Sometimes, a thin layer of ice looks like a passage, but skiing through it feels like playing russian roulette. Therefore, heading straight through water can seem appealing. Ousland broke a first barrier using sledges as a canoe, leading to efficient but rather scary paddling parties. But he has disrupted the game even more, when he packed a dry-suit in his sledge, and wore it to swim across the channels. Security and speed!
As for a polar skier, tools are the bread and butter of our IT departments. No matter which one, mastering the technique is a crucial aspect to the success of any software project.
Even in the age of global information, too often do we find developers entrenched in obsolete or inappropriate technical choices, by fear, laziness, or simply by stubbornness. No need today to take long trip to learn how to build an igloo or to manage dogs. The Silicon Valley experts and word class references are a click away, even if the tool is only a part of the solution with its mastery being the key.
Indeed, organizations must foster conditions to make their people grow and innovate. Methods exist and have proven their efficiency: pair programming, internal developers fora, trainings, conferences, blue sky projects…

Automate wherever possible

One aspect a long polar trip which shall not be left aside is the prevalence of recurring tasks. Setting up camp, preparing food, de-icing the ski bindings. Even the simplest gesture of pulling a bottle of tea out of the sledge can mean: opening the sledge with mitts, seeking for a bottle, having a couple of thing falling of and putting everything back in can easily take 2 or 3 minutes. And ten times a day, those are 25 minutes lost, for an operation that can be set up to last ten seconds.
Losing time on repetitive tasks is not only theoretical waste. It directly results in less sleep, thus psychological and physical strain. It translates into pain, when standing up in a freezing and windy environment soon drills through the toughest character. It translates into security risk, when multiplying steps is error prone. And errors can translate into…
Let’s focus on setting up camp for a party of two, a daily task occurring at the end of every strenuous day. The todo list is straightforward: pulling out the tent and setting it up; tying it with ropes and building a snow wall for the wind not to blow it out; getting it ready for sleep, with two layers of mattress, a sleeping bag and a vapor barrier inside; getting the ice and snow out the clothing; melting snow into drinking water; cooking a 2’500 kcal evening meal. This simple pipeline can easily take two hours and will have to be reversed in the morning.
Inconvenient side effects can be: losing the tent, when the wind rushes straight  through thousands of kilometers of ice lands. Losing one finger, when standing motionless in the same wind. Losing a crucial piece of equipment in the snow, because of disorganization. Losing your self control, for all the previous reasons. And losing the fun part of it.
Being a repetitive task, one should focus on streamlining the process. Let’s consider a few details: the tent is not rolled into its small pack, but folded on the top of the sledge, with the tension poles only broken in two; idem for sleeping bags, with the vapor barrier and a mattress inside; mattresses for the floor are sewed together; the snow is carefully chosen to melt faster; as soon as the tent is up, one will start cooking and the other will reinforce the camp, use sledges as walls. The full list is rather long, but the end point is that one hour and fifteen minutes can be saved every evening. And as a consequence, camping by -39°C becomes a breeze.
But such a process does not come up straight away at the first try. It is based on experience of others and self experiments. And let’s thank Børge Ousland and Sjur Mørdre, the great Oslo skiers, who have opened their books and shared their countless tricks and tools.
Process automation is at the technical core of agility. Shall it lay at low level, with unit tests running automatically on the developer laptop or when the database evolution path is stored in the code repository and seamlessly applied by every source code stakeholders.
Automation is taken to the next level with a build factory (such as Jenkins, Bamboo or TFS), where code is built, and integration/system/end to end/performance/security tests suites run continuously, before the application is deployed to production.
It can even be pushed further by DevOps, with tools such as Ansible, Puppet, Kubernetes, with the whole infrastructure being described in code (akka “Infra as Code”), to be tested and deployed on all the application environments.


Continuous improvement

On any journey, one will inevitably make mistakes. The best team, with the best tools, the best preparation cannot avoid them (maybe precisely because such a team will seek for higher challenges). Small or big, those mistakes shall be recognized and addressed, as we have previously illustrated how they can take their toll. There is no universal recipe to improve oneself, but there are obvious ones not to do so: never acknowledge you are wrong, embrace suffering as an end in itself, don’t leave room for trying new solutions and tear down any initiative to do so.
Continuous improvement is a mindset but it shall certainly be organized. Let’s consider some aspects of improving a kite system to pull a skier. Even in a constrained environment, many aspects are to be chosen: how to link the sail to the skier to be comfortable and better transmit the power to the sledge? What rudder system to be handled for hours (a good windy day can push a party to last 24 hours on ski in a row)? How to eject the system in case of emergency without losing it? How to launch or bring down the system in strong winds? How to pack? What line material to use to limit knots? How to repair? How to tie two skiers on one sail?
Again, a pattern can be applied to focus and avoid the energy and time being dissipated pursuing multiple topics simultaneously. The problems are to be broken down during a brainstorming (even a single person can brainstorm!) and hypotheses for improvements written down. Each hypothesis must be verbalized to be challengeable against a measure, or a hard fact. Each of them can then be sorted according to the expected  benefit  versus the resources estimated for implementation (hence the benefit of having broken them into smaller bits). One of them is then elected and a time frame is allocated to implement it, check the estimation and eventually adopt it. Finally, a new hypothesis is taken out and pursued, in light of the experience recently gained. And the whole process can loop.
However, the process described above can only be applied during the expedition preparation stage, which typically lasts a full year. It is not likely to be undertaken during the expedition itself. However, the journey is the richest mine to gain knowledge. The bright ideas and painfully acquired lessons can easily be forgotten before the next expeditions. Therefore, the first action after a trip (or maybe right after a strong meal and a shower) is simply to write down the lessons learned and eventually share them as an appendix to a web story, for the benefit of everyone
A snapshot of a “lessons learned” report written down in the plane on the way back from  an expedition and shared on the net
Although experience cruelly shows that continuous improvement is among the first dimension to be neglected in “agile” IT projects, it is a core value of agility. Every methodology carries it explicitly. Scrum prescribes the retrospective meeting, at the end of each sprint. Various formats [11] can be used, but the common outcome is to let the team acknowledge what went wrong or well and decide which initiatives shall be tried before the next gathering, together with measures against which the outcomes are to be evaluated. It is a common saying that any other meeting could be dropped by a very mature team, but the retrospectives. Other methodologies also include continuous improvement, and many tools exist to pursue it: Plan-Do-Check-Act, 5 whys, speed boat…

Facing the unplanned

Decision making

We have covered many aspects of a polar expedition in this article. But until now, we have also acted as if the process were linear. Strenuous maybe, but without too many surprises down the road. Surprisingly enough, this cannot be further from reality…
Weather, equipment, navigation, food, camping. Every aspect brings its load of unexpected events. The reward of having set up every components is to make most incident minors, but surely enough, some complex situations will happen.
In a system where everyone is accountable for the project success, everyone certainly has an opinion on the problem solution and shall be given room to voice it. The goal is then to build a decision that will appear the best to group, in the shortest amount of time. For such, we propose the following method:
  1. phrase the question and the scope;
  2. welcome and listen to everyone’s opinion, trigger alternatives if none comes spontaneously;
  3. encourage everyone to defend every other’s opinion and seek for a solution take the best out of each of them;
  4. be sure that everyone has understood the reasons of the selected solution;
  5. stick to the decision and do not re-evaluate, except if the scope clearly evolves.

It is important that the method presented above is not designed to converge towards a weak consensus. The median ego level among the group is not the correct metrics to optimize. The commons reflex of everyone sticking to his/her original idea must be relaxed, as well as the natural feeling “I’m stupid because my solution was not taken”. All this can only happen if the group has grown a mindset with enough trust. Referring back to a previous session, we can fully apprehend here the role of a talented leader, who will catalyze the team vitality rather than force feed them by authority or lack of self confidence.
But as with everything, the ability to take group decision must be trained, and not tested at first in a major crisis. And when the skill is acquired, it can be used efficiently, even when team members are on the verge of exhaustion.
In some situations, a consensus process is not possible. An experienced party fellow, recognized by his peers, could have to make the decision for the group. This can happen in emergency situations, or when everyone is too tired and fall back on a natural leader. Should the group remain a team, this should be rare enough and the decision explained, possibly afterwards. Of course, all those arguments do not apply in a journey where a professional guide was hired and all burdens willingly delegated.
During a crossing attempt of the Southern Patagonian icecap in 2001, accessing to the glacier plateau required us to enjoy 17 days in this ice labyrinth, with backpacks over 40kg. Every 65 minutes, the two of us would break 5-7 minutes to rest and have a short discussion about which trajectory we shall head for the next period. Sure enough, our initial opinions were rarely aligned, but within a couple of minutes we could build the best out of them. The same decision pattern was intuitively applied for small decisions or for more radical ones during this journey.

Managing risk

“- No risk, no fun.
– No brain, no pain.
– Indeed”
Anonyms
Risk is a part of any accomplishment. It is defined by the the Oxford dictionary as “the probability or threat of quantifiable damage, injury, liability, loss, or any other negative occurrence that is caused by external or internal vulnerabilities, and that may be avoided through preemptive action.”
Possible risks in an expedition are to be assessed, based on experience, their potential consequences and the cost to mitigate them. Following an equipment failure, an expedition can try to limit the consequences by doubling it or carrying adequate repair kits (turning a tool into a degraded version, less efficient but still useful). However, carrying more weight is a risk in itself, as a party will be slower, spending more time in a “dangerous” place, therefore increasing the exposure to adverse events.
Risk can also come from external hazards, such as falling into the water or meeting a polar bear. Obviously, such situations cannot be addressed by a polite decision jabber, as seconds literally count. Nor it is the time to improvise, as the stakes can be high.
Let’s consider a situation of a two week camping party to watch polar bears, in Eastern Svalbard. First research quickly shows that a) there are definitely a lot of polar bears in the area; b) they can occasionally consider anything as food; c) “don’t go there, you’re doomed to fail” seems a general advice. Pushed by the upper motivation of enjoying a first hand sight of those incredible animals, let’s consider pursuing the project. Evaluating the risk is conducted by a careful study of past human/bear encounters, and the factors that might have clustered a “bad” from a “good” encounter (an encounter is to be labeled as “bad” in case of a physical contact). Although such a study might greatly reduce risks, it will not totally eliminate them. Therefore, common scenarios are pulled out from the study and a plan agreed upon by the party in case of emergency situations, e.g. “X handle the gun and is ready to shoot; Y talks with the bear and decides when the situation is out of control; Z shoots a video for posterity.”
Such plans have proved not to be applicable in every situation (e.g. when guns were found to not to be rented to foreigners) but they definitely help when a problem actually occurs. The worst situations can be observed when the risk is known but not acknowledged and luck is called upon to solve issues.
Video Player
00:00
00:00
1. “ours_l”
0:13
A bear passing by, in Eastern Svalbard (video) in 2001.
Risk assessment in IT is a popular and prolific discipline. Whether in agile or other type of methodologies, tools and methods do exist to face it. Without digging into architectural or functional concerns, let’s just point out the use of Proof of Concept projects, sound software craftsmanship practice, design and code review, security testing, “what can go wrong?” brainstorming sessions and pre mortem analysis.

Measures, predictions and outcomes

Let’s close our contemporary discussion and roll back to 1911, where we left Scott and Amundsen. And let’s follow them until the end of their adventures. As they were about to launch their final assault, the big question was: “do we have enough resources to complete the Journey, plant our flag at the Pole and head back to our harbor?”
Each of them had built resupply depots down the route during winter, as carrying all the food and fuel at once seemed impossible at the time. As displayed in the figure below, Amundsen had taken particular care to install his depots at regular one degree intervals, up to 85°S, while Scott party was more driven by the circumstances and set them up based on a “best effort” driver.
Amundsen and Scott’s routes – with a zoom in on the right. Resupply food depots for the Amundsen’s team were set up at strictly one degree interval, before the final Plateau rush, while Scott’s are more irregularly placed.
Amundsen setup measuring tools: a wheel was attached to a sledge to report the daily covered distance, as astronomical observations are time consuming and imprecise under those latitudes. With measures and regular iterations (the food depot distance), the team was able to predict how a constant effort would lead them to the goal or not. As the team leader, Amundsen also wrote how a decent amount of sleep and food was important for the men to be in shape to sustain the moving pace for a long time.
Regular iterations, measures, sustainable effort. The tempo was set and led the team to a success, with men coming back to the harbor and reporting to have gained weight!
Scott journey is another story. Designed from the beginning to be an heroic march, it quickly became so. Those men diaries are a great inspiration on how one can push their physical and psychological limits to an end. But to an end it would be. Reaching the Pole a month after Amundsen party, they discover the norwegian flag slapping over a tent and a message to them. If deception wasn’t hard enough, men also wrote down their doubts about making it back alive. An heroic march back started, and starving men would walk to their death, caught in a last storm twenty kilometers away from a major food depot.
One of the most dramatic burndown chart ever, where delivering means making it back alive. The effort is the number of kilometers to go from the winter base camp to the Pole and back. Amundsen team had a slightly shorter round trip, but Scott team did benefit from a known route and an “easier” access to the Plateau, scouted by the previous Ernest Shackleton’s expedition. The chart is extrapolated for Scott’s return trip, as his logbook does not contain daily or regular position reports (progress was not as linear in reality). On the contrary, Amundsen’s party increased speed on the end, travelling lighter from one depot to the other.
Regular iterations and throughput are the ultimate goals of an agile delivery. Measuring, via velocity, lead time, throughput certainly are ways to assess this goal and more importantly to predict it.
However, if everything can be measured, IT project shall not drown under useless figures, that no one will watch but once. For example, it might be worth for a while to time the process of deploying an application to production if the step is felt to be painful. Actions can be undertaken to improve this part of the delivery and evaluatued against hard metrics. But once the process has reached an acceptable pace, there may be no longer the need to report them. In other situations, it might even be wise to keep track of the team “mood level” by asking everyone, after each iteration, to grade their current “happiness in the project” on a scale from 1 to 5, without further justification.
Measures are endless but they shall be used on dedicated purpose. As Lord Kelvin once said: “you can only improve what you can measure”.
Another blasting parallel between the agile methodology and Amundsen approach is the attention to build a sustainable pace. Extreme Programming, for example, explicitly states a “40 hours per week” in its core value. Bypassing that limit shall only be exceptional for one week, and pushing the exception further is considered a failure.

Oslo, the Silicon Valley of polar expeditions

Throughout this article, we have focused on Roald Amundsen and taken a couple of slight detours mentioning other Norwegian explorers, Fridtjof Nansen and Børge Ousland. But they are only three out of an impressive ecosystem. We could have mentioned Sjur Mørdre, Vegard Ulvang, Liv Arnesen or many others. How such a small country can have produced so many great accomplishments? The culture of a country can explain it partially (even though that can be another chicken and egg dilemma).
Another explanation can also come from the ecosystem which has grown around Oslo. Small entrepreneurs certainly have reached amazing success, but they are the tip of the iceberg. Many more modest enterprises have set off, a network of tool developers has emerged. And more importantly, a culture of innovation and sharing has grown. Even if considered as a star, Børge Ousland always took the time to answer our questions (even by fax at the time), opened his workshop, shared tips, gave advice.
And the parallel with the Silicon Valley cannot be more blasting. If it is often summarized to a few successful giants, the real magic of the San Francisco Bay lies elsewhere. It is of course grounded in historical roots (Nasa, HP, Rank Xerox, Bell) and has seen its culture ingrained by the Hippie movement. But the real energy of the Bay area is an incredibly dense network of small interactions (meetups, bus discussions), a will to share and fearless garage dreamers.

Conclusions

If organization processes, tools and rituals are key to a successful agile transformation within a company, deep and lasting success roots are deeper. It must be backed by a profound will of the upper management to alter the fundamental decisions channels. If not, bringing Agile in a corporation will be a varnish of Scrum certified peoples, with technical teams applying rituals at best and improving their software craftsmanship practices. And business deciders believing they can constantly change the project directions at any time because: “hei! You’re agile now!”
We presented in this article a confrontation in approach between a small Norwegian enterprise and one of the largest and most powerful organization of the time. We could have found other examples alike, making similar oppositions between a Nansen expedition and that from another Royal Navy dramatic expedition, led by Sir Franklin. It would then be easy to simply oppose startup and big corporations. But the organization size is not a determinant. We could also have focus on how Ernest Shackleton, another Royal Navy captain, led his expeditions in a style much closer to Amundsen’s one and with great achievements. And pinpointed small modern expeditions, engulfed in top down decision making, stubborn technical choices and failure.
Finally, to answer those who hide behind the fatalist “my company cannot change”,  we cannot forget to mention the extraordinary adventure of David Marquet, US Navy Captain on a nuclear powered submarine [13]. He totally transformed the chain of command and the decision process in a domain with the highest process constraints. The “agile” word was nowhere, but the spirit was.

References

Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)