An Introduction
Part of the A Matter of Survival: Software Development as Wilderness Adventuring Series.
Some number of years ago, I found myself in the midst of a crisis. As any good crisis should, this one slapped me up alongside the head hard enough to shake a few things loose. In particular, it forced me to reconsider the very foundations of what I thought was essential in software development, causing me to view my chosen profession through a radically different lens — the lens of wilderness survival.
I know what you’re thinking. Wilderness survival? What?
No, I had not actually been lost in the wilderness. I hadn’t been lost at sea, or survived a plane crash in the mountains, or suffered a nearly fatal accident, or contracted some exotic disease. My crisis was of a professional nature…which precipitated a crisis of faith.
Up until that point, I’d been an Agile zealot of the XP clan. I first encountered XP in an article by Kent Beck, “Embrace Change with eXtreme Programming”, published in IEEE Computer magazine in 1999. I was immediately transfixed and transformed. I started breaking my work into “stories”. I organized the stories into short iterations. I even became addicted to that little thrill one gets when unit tests go “green”. I would sometimes run the tests a second time just to see them turn green again.
During 2001 I was fortunate to have a couple of lunches with Ward Cunningham, whom I knew from the Software Patterns movement. Ward, of course, knows Kent Beck and helped sharpen my understanding of XP. I also read avidly the discussions about XP on Ward’s C2 wiki.
By 2002, I was boldly pinning story cards outside cubicle walls for all to see, and had put in place the rudiments of continuous integration. Over the next couple of years, I worked hard at developing my Agile chops. I participated in a fairly significant online banking project with James Shore, which gave me an opportunity to see XP applied to a larger team. And I had a stint as an engineer/manager at a rigorous XP startup where we pushed the boundary with things like promiscuous pairing — a practice that made the team exceptionally productive at delivering high-quality code, and remains to this day one of my peak engineering experiences.
Success, of course, fed the zealotry.
Along about 2006, I met my Waterloo. I’d taken an engineering management position with an education start-up. The VP of Engineering and I had had a number of conversations about Agile, my experience with it, and how it might lead to improvements. I was excited by the challenge, and was confident that I’d be able to turn that ship around.
Looking back, the signs of trouble were apparent from the start. Some of these signs I saw clearly, but didn’t give them enough weight. But others, I didn’t see at all. Key among these was the fact that, aside from my conversations with the VP of Engineering, there seemed to be no one with a strong interest in the kind of Agile I was promoting. This included both the team I was tasked with managing and the executive team.
Half of the software organization, the half that developed the online educational content, the half that made money for the company, had significant pressures driving them toward a top-down waterfall process. They needed to deliver multiple academic years worth of lessons meeting a complex set of requirements that differed from state to state. It was a high-risk venture. There was no opportunity to be responsive to change. You had to understand the whole thing and get it right, or it wouldn’t sell at the yearly sales events.
The other half of the software organization, the half that I managed, the half that provided the delivery platform, had pressures to adhere to yearly delivery cycles aligned with the start of the school year. Mid-year changes to the platform were not especially appreciated by the schools. Changes in the platform meant changes to district documentation and the retraining of their staff. As a consequence, the executives, product managers, salespeople and company trainers all wanted to have a pretty clear idea of what was coming months in advance of the start of school.
I was just getting my head around all this when the VP of Engineering, the guy who hired me, was let go. The company replaced him with an old-school Engineering VP with distinctly anti-Agile leanings. That was it. Game over. At the start of 2009 I found myself unemployed. It was at the height of the Great Recession. I had two small children, and my wife had only just put her toe back into the workplace as a project manager.
It’s an embarrassment to enumerate these things now. They seem so obvious. I should never have taken the position, or adapted sooner, or moved on to an opportunity more in keeping with my interests. But I didn’t. I persisted in beating the Agile drum. I had come into the company high on my Agile successes. I was following the scripts that had served me well in the past, and had trouble seeing beyond my (admittedly limited) mental model of a well-oiled software team.
Well, it turns out that I’m not alone in being blinded by success. As my eLearning adventure slowly crumbled, my wife began nudging me to take a look at a book she was reading by Laurence Gonzales, Deep Survival: Who Lives, Who Dies, and Why. Although she is not a software engineer herself, she had spent a sufficient number of hours listening to me blather on about XP and Agile to know immediately that this book is about being Agile in the wilderness. And it is. It demands that we be responsive to the context in which we find ourselves, whether that context is truly new or just new to us, and offers numerous examples of what happens if we don’t. It describes adventurers who, like me, were blinded by their success…or pride, or ignorance, or sheer foolhardiness…with consequences far more dire than my own.
A perfectly sensible man on a snowmobile is warned not to go up a hill because it will probably produce a fatally large avalanche. He goes up anyway and dies. A firefighter and experienced outdoorsman knows he is going in the wrong direction but persists anyway and winds up profoundly lost in the wilderness. A number of scuba divers are found dead with air in their tanks. They pulled the regulators from their mouths and died.
Deep Survival: Who Lives, Who Dies, and Why, Laurence Gonzales
Given the number of otherwise competent people making these kinds of mistakes, there’s clearly something worth knowing about how and why we do it. And, more importantly, what can be done to prevent it. Gonzales analyzed hundreds of accident reports and survival case studies. He interviewed pilots and firefighters and Army Rangers. He pulled together research from neuroscience and the science of complex adaptive systems and psychology. From this, he garnered a number of insights into who lives, who dies, and why — insights that he consolidates into the Gonzales Rules of Adventuring.
Rules of Adventuring…for Software Engineers?
The following rules summarize Gonzales’ findings. They offer his best thoughts on how to avoid finding yourself in dire survival situations.
(Note: Gonzales lists a separate set of qualities needed to survive a life threatening catastrophe once you’re in one. We’ll get to that in another post.)
- Perceive, believe, then act
Strive to perceive things as they are, not how you wish they were or how you think they ought to be. Believe what you perceive. Then act accordingly. - Avoid impulsive behavior; don’t hurry
Impulsive behavior leads to mistakes, and mistakes will do you more harm than slowing down. So be quick, but don’t hurry. - Know your stuff
Be a consummate professional through continuous and obsessive learning. - Gather the information
Before adventuring, get the lay of the land. Talk to people. Read what’s been written. Get informed. - Commune with the dead
Study the past — your own and other’s — and apply what you learn to your adventures. - Be humble
Don’t assume that just because you’ve successfully gone adventuring before that you’ll be successful in all your adventures. Cultivate a beginner’s mind. Pay attention. - When in doubt, bail out
Never be afraid to recognize that something isn’t working. When you do, don’t be afraid to change course. Doing so demonstrates an ability to perceive things as they are, and a willingness to be humble.
This all seems very sensible, right? If I look back on the times when I or my team have been in trouble, I can generally peg it on perceiving the situation incorrectly, or not acting on what I perceived, or acting impulsively, or lacking technical depth in a certain area, or failing to gather the right information at the right time, or failing to bail out sooner. As a framework for promoting success, it’s spot on. But, as I’ve tried over the years to put this guidance into practice, I’ve found that it’s not so easy. These high-level rules are not enough. I do better with mental models for how things work, and scripts for day-to-day functioning within that model. I do better when I’ve developed gut-level triggers, through learning and experience, that prompt me to take actions, or stop actions, or adjust actions.
Mental models, scripts, triggers — I know, it’s beginning to sound like the very things that got me into trouble in the first place. But as it turns out, operating without them isn’t an option. It’s impossible for mere humans to absorb the entirety of everything, make sense of it, and act accordingly. By necessity, we must see the world through filters (mental models), act in ways that have proven useful in the past (scripts), and choose when to act based on limited input (triggers). These models, scripts and triggers are the tools that enable us to function in a complex and ever changing world. We can’t avoid using them, we can only try to make them better.
An Outline for Our Adventure
Adventuring in the wilderness demands that we be responsive — to change, to the context in which we find ourselves, to the people with whom we’re adventuring. It’s “agile” (lowercase “a”) in the sense of being quick, resourceful and adaptable — to thrive, not just survive, in whatever context we find ourselves. Applying that same agility to software development, even in contexts where Agile methodologies seem to fail, that is the work of this series.
The outline below divides the posts of this publication into two main sections: “The Preparation”, and “The Adventure”.
Any significant adventure should, of course, start with preparation. You don’t just step out into the wilderness and hope things will go well — if you want to thrive. For this series, “The Preparation” explores the relationship between Agile and wilderness adventuring, offers a brief foundation in complex adaptive systems (CAS) theory, and takes a deep dive into a set of specific CAS topics that seem particularly applicable to the business of developing software.
“The Adventure” section takes us into the Gonzales Rules of Adventuring, exploring how they apply to software development. It then looks at issues regarding teams, staying healthy and surviving catastrophes.
Thank you for reading.
The Preparation
- Agile Adventurers
Looks at the lives of various wilderness adventures — explorers, mountain people, those lost at sea or on mountains, the victims of war — to illustrate agility within a complex ever-changing world. - Complex Adaptive Systems: A Field Guide
Develops the primary mental model needed for the adventure ahead.
The Adventure
- Perceive, Believe, then Act
Perceiving accurately, understanding what it means, and believing sufficiently enough to take action…it’s not as simple as it sounds. - Avoid Impulsive Behavior; Don’t Hurry
As John Wooden, former head coach of the UCLA basketball team, once said, “Be quick, but don’t hurry.” - Know Your Stuff
Takes a look at the nature of expertise, the importance of having it, how it’s acquired, and the variety necessary to succeed as a software organization. - Gather the Information
The active and continuous nature of effective information gathering, and the breadth of domains and sources from which to gather. - Commune with the Dead / When in Doubt, Bail Out
As Edmund Burke once said, “Those who don’t know history are doomed to repeat it.” - The Zen Qualities of a Software Master
Humility, being present, listening. - Choose Your Adventuring Companions Carefully
Selecting a team to join, and building a team others want to join. - Staying Healthy
Individual and team health. - Surviving a Catastrophe
Despite your best efforts to avoid disasters, they will happen. What are the rules for surviving? - Epilogue
A personal story about how a child experiencing disability, a school district trying to figure out how best to serve him, and an impossible work situation conspired to suddenly and dramatically transform my life — a truly agile adventure.
