Antipattern 1.1: Doing an Agile Transformation

This post on the Agile Transformation Antipattern is adapted from Chapter 1 of Sooner Safer Happier by Jonathan Smart, with Zsolt Berend, Myles Ogilvie, and Simon Rohrer.

I’ve met with many organizations and leadership teams that want to undertake an “Agile Transformation.” The process usually begins in the same way. We sit with senior leaders and ask them why they want to change. The response is often silence. A couple of people will stare at the ceiling. Someone will stretch their legs. Then, eventually, one brave person will raise a hand, and say:

“It takes us too long to get new ideas to market. We’re slow and inefficient.”

“Good,” I’ll say, and write that on the board. “Anyone else?”

More replies usually come in then, and they are written down in turn:

“Everyone else is doing it.”

“We’re struggling to stem attrition and attract talent.”

“Our customer satisfaction is trending in the wrong way.”

“We don’t want to be left behind.”

“Beats me. I think we’re doing fine as we are,” says the person with their arms crossed and brow furrowed.

Each of those answers is reasonable and understandable (even the last one). We continue asking why the company might want to change how it does what it does. Eventually someone lands on the existential point: “We’re being disrupted. If we don’t change how we do things here, we won’t survive.”

Often, the organization is about to embark—or has already embarked—on an “Agile Transformation.” Or they’ve had a bitter experience in the past with a “Lean Transformation” or Six Sigma or tried to become more “DevOps” with a focus on tooling. Typically, desired outcomes have not been articulated other than “How many Agile, Lean, DevOps teams do we have?”

There are bubbles of agile in a sea of Gantt charts with predetermined solutions, dates, and spending predicted at the point of knowing the least, an annual, bottom-up financial planning process that takes six months of the year to plan and re-plan and focuses on output over outcomes.

There are “drop dead dates” and “deadlines” (in most cases it’s not life or death); RAG (red, amber, green) statuses and change control processes; a change lifecycle with twenty mandatory artifacts, most with their own stage-gate governance committee; a traditional waterfall Project Management Office; sixty-page Steering Committee decks; project plans with the word “sprint” ten times in the middle; a lack of psychological safety; a performance appraisal model that incentivizes mediocrity (underpromise to overdeliver) and uses a Think Big, Start Big, Learn Slow approach.

The good news, with a charitable intent, is that the organization wants to improve.

1: Tools in the Toolbox

It’s not about “Agile,” or “Lean,” or “DevOps” for “Agile’s” or “Lean’s” or “DevOps’s” sake. Figuratively speaking, they are tools in a toolbox. Of course, they are much more than tools; they are behavioral principles, practices, and tools. The point is that you have a collection of bodies of knowledge to deploy optimally in context. A tool transformation, such as an “Agile Transformation,” is not optimizing for outcomes, it’s optimizing for the tool.

For example, let’s say you want to hang more pictures on your wall, so you
do a “drill transformation.” To stretch the analogy further, the make of drill denotes a particular agile framework. For example, a “Bosch drill trans­formation” or a “Black & Decker drill transformation.” At the end of your drill transformation, you may have a multidisciplinary team creating a wall full of quarter-inch holes faster, meeting hole-drilling commitments, but it doesn’t mean that the pictures are going up. Agile and lean principles, practices, methods, and frameworks are bodies of knowledge to achieve a goal, but they are not the goal. Equally, success is not defined as teams using actual tools, such as JIRA and Jenkins. A tool-led transformation does not equate to agility.

2: Cargo Cult Behavior

During World War II, America had airbases on a number of Melanesian islands in the South Pacific. Planes would land regularly, dropping off cargo such as medicine, foodstuffs, tents, and weapons that the islanders had never seen before. Once the war ended, the planes stopped coming. The islanders responded by creating what anthropologists called a “cargo cult.” They built wooden control towers, wore headphones made from coconuts, performed parades and ground drills with wooden rifles, and built life-sized replicas of airplanes out of straw. They had seen that when the Americans performed similar behavior, planes arrived with boxes full of goods. Despite their attempts at re-enacting this activity, the flying machines did not return to drop their cargo.

This cargo cult behavior can occur in organizations undergoing Agile Transformations. It can happen when organizations “do Agile,” pursue Agile for Agile’s sake, or focus on “How Agile are we?” rather than on desired outcomes. Staff might not wear coconut headphones, however, there are new role titles, iterations, standups, retrospectives, and stickies, which by themselves do not necessarily translate into better business outcomes. People are practicing the ceremonies, but the planes don’t land and the cargo never arrives.

It happens at both large and small organizations. Until 2010, Nokia had the number one market share for smartphones. Nokia development teams had adopted agile ways of working and, with a positive intent as an improvement on previous ways of working, would apply a “Nokia Test,” which measured the company’s agility in relation to the Scrum agile framework. In the space of just two years, during 2011 and 2012, Nokia’s Symbian operating system fell from the largest market share to extinction. The last Nokia phone with the Symbian OS was unveiled in February 2012. In the UK, not a single major operator stocked it. Nokia sold its mobile phone business to Microsoft in September 2013.

In his book, Transforming Nokia, Risto Siilasmaa, Nokia’s chairman since 2012, described how he felt when he learned that it took two days to compile the Symbian operating system and two weeks to do a complete build:

“It was as though someone had hit me in the head with a sledgehammer.  .  .  . There were fundamental flaws in how we developed the platform that most of our profitability and near-term growth depended on.  .  .  .  As I later learned, the overall build time was two weeks! This was a recipe for catastrophe and a catastrophe was exactly what we had staring straight into our eyes.”

The teams could “do Agile” as much as they liked. They had Product Owners, standups, sprints, and so on, all of which are improvements on a traditional waterfall approach with a very long concept-to-cash time and a long time to learning. However, it didn’t save Symbian or Nokia mobile. According to Siilasmaa, the bigger problem was a lack of psychological safety. Bad news was being buried instead of exposed, discussed, and dealt with. No one had bubbled up the fact that the overall build time was two weeks. Doing Agile will not address that problem.

In my experience, the behavioral norms in an organization are the biggest lever in transforming ways of working. As I’ll explain in Chapter 4 of Sooner Safer Happier, they’re also the hardest to move. Had there been a primary focus at Nokia on the outcomes instead of on the tools, the results might have been different. A focus on Sooner might have shone a light on the long lead time to learning for Symbian features. A focus on Happier might have exposed a lack of psychological safety. Focusing on all of BVSSH might have kept Symbian competing with Android and iOS.

I’ve experienced this cargo cult behavior firsthand. It was one of my biggest lessons learned. At Barclays in 2015, I was leading an “Agile Transformation.” We ran a “How Agile Are You?” self-assessment survey with four levels. The test had a positive intent, and it gave a rough indicator of who was working with agile principles and practices and who was still working with old, waterfall ways of working.

In hindsight, I wouldn’t do it again. The test led to cargo cult behaviors with new labels on the same old practices. We also had teams who had adopted agile principles and methods but, for a wide range of reasons that I’ll describe in later chapters, didn’t produce the expected beneficial outcomes. They were focused on agile practices but not on the outcomes.

Worse still, we had targets on the four agility levels—and you get what you measure. Teams found ways to game the system, and in some cases that produced even more cargo cult behavior. Every business unit achieved their “How Agile Are You?” targets, with some miraculous, almost unbelievable, jumps just before the end-of-year performance appraisals. The survey might have had a positive intent; however, with the benefit of hindsight, it turned out to be misguided. We learned and we pivoted.

In our next post, we’ll visit the corresponding Pattern to Antipattern 1.1.

- About The Authors

Jon Smart

Jon is co-founder and CEO of Sooner Safer Happier. Jon is a business agility practitioner, thought leader, and coach. Jon has been an agile and lean practitioner since the early 1990s. Jon helps large organizations deliver better value sooner, safer and happier through better ways of working. He is the lead author of the award-winning and bestselling Sooner Safer Happier: Patterns and Antipatterns for Business Agility.

Follow Jon on Social Media

• 
•