Q&A on the Book Untapped Agility

The book Untapped Agility by Jesse Fewell explains what holds organizations back in increasing their agility. It describes barriers that may appear during an agile transformation and provides “rebound” moves for unblocking the transformation and moving forward. This recurring pattern of Boost, then Barrier, then Rebound both encourages and enables frustrated agile champions.

InfoQ readers can download an extract of Untapped Agility.

InfoQ interviewed Jesse Fewell about frustrations and barriers in agile transformations, how to generate alignment, true agility, customizing agile practices, deciding what to do or not do, combining a culture-oriented thought process with structural elements, dealing with criticism and complaints about not meeting expectations, and transforming the transformation.

InfoQ: Why did you write this book?

Jesse Fewell: Funny story… this is not the book I set out to write. It started as a 2017 article on agile leadership. I made the case that overcoming transformation resistance hinges on a balance of both culture and structure. I’m a big fan of the universal principle of balance, like pulse-and-glide in physics or yin-yang in metaphysics. 

Well, it seems I wasn’t alone in that conviction. When the article appeared in the Cutter Consortium Journal, it sparked more conversations about other barriers leaders face when driving transformations.

My original thesis emphasized balance: both culture and structure, both external ideas and internal talent, both big and small changes. But the more I looked into it, the more a different pattern started to emerge: making progress introduces new barriers to further progress. Those barrier patterns motivated more research, which evolved into this book.

InfoQ: For whom is this book intended?

Fewell: I believe there are champions for change at any and every level in an organization. From the software engineer to the PMO director to CIO, people deeply desire excellence, and everyone has an opinion as to what gets in the way of that excellence. 

But saying “this book is for everyone” is a little naive and vain. So we designed three personas to capture the patterns across people we interviewed: 

• Ted the Team Lead is an influential rolemodel team contributor (e.g. an analyst, tester, or developer). Ted believes in doing things the right way, the modern way. He hopes the book’s practical tips & techniques will overcome the team’s resistance, and also get more management buy-in.
• Maria the Manager has a budget and direct reports (e.g.  head of PMO, program manager, director of Agile COE). She’s done all the right things like training her staff and installing agile practices. However, the change just feels wrong. She’s eager to apply the ReBOUND pattern to overcome resistant employees, dependencies in the other groups, and executives distracted by other shiny objects.
• Emmit the Executive is a leader of leaders (e.g AVP Product, CTO, Deputy CIO). Newly installed with a mandate for change, Emmit is exhausted by the volume of issues his organization faces. He’s excited the seven patterns might help him triage his transformational investments, and change the cultural narrative from “Eventually” to “urgently”.

InfoQ: You mentioned in the book that there is a lot of frustration in agile transformations. Can you elaborate?

Fewell: There’s a popular internet meme that humorously contrasts “expectations versus reality”. In many ways, transformations carry the hopes of a shiny new car, only to find it’s not what you hoped for. That disappointment has turned into very real agitation in three key groups:

• First, the original industry pioneers feel betrayed. We see it in Martin Fowler’s critique of the “agile industrial complex”, Dave Thomas’ declaration that “Agile is dead”, and Ron Jeffries’ warnings about “Dark Scrum.” More and more true believers are dismayed by bad versions of agility.
• Second, executives are still skeptical. Just look at Scrum darlings Nokia and Yahoo, and the Lean Startup role model GE, and it’s easy to see why barely half of the executives believe a transformation will yield results for their organization. 
• Finally, the rank and file are disgruntled. 60% of agile champions experience very real resistance to agility. Then, when the ambitious 58% of executives brag about a new practice, a super majority (63%) of their very own staff disagree that practice is actually working. When people fight us all along the way, and then prematurely declare victory, it gets super annoying. 

The good news is those frustrations don’t have to define your transformation destiny. You can still influence progress forward. 

InfoQ: What barriers do companies face in agile transformations and how should we deal with them?

Fewell: This is the most alarming finding from our research. It turns out, there is an overarching consensus as to what holds us back. I looked across several recent surveys, interviews, and case studies, and what was surprising was just how frequently the usual suspects were mentioned: 

• Existing Culture and Structure - Ironically, the organization we want to change is itself the primary blocker to change. Bureaucracy blocks creativity; hierarchy blocks empowerment; Silos block collaboration. Here, the research highlights that the best way forward is one small step at a time. Culture reflects and reinforces current structures. Only with incremental changes to policies, metrics, and practices will we be able to evolve people’s values and belief systems over time
• Human resistance to change - Change champions forget that the unknown can be intimidating. Agile methods are not new to us, so they don’t unnerve or confuse us, the way they do other people. So a little patience can go a long way. Specifically, be willing to explain the big picture over and over again, so people can acclimate to the benefits and vision of the transformation. Also, take the time to frame a narrative around “what’s in it for me”; people will sooner listen to how the change improves their day-to-day work, than to some vague notion of “better organizational outcomes”.

InfoQ: How can we generate alignment in agile transformations?

Fewell: Another key blocker showing up often is a “lack of leadership support”. Sometimes that means our leaders simply aren’t on board with agility. In those cases, it’s better to “stop selling agile, start aligning with pain”. For example, a VP of product keeps shooting down your introduction of user stories. If you simply ask what his key pain points are, perhaps you’ll learn he’s more frustrated about blowing through date forecasts. At that point you have an opening to talk about MVPs, and prioritization techniques. In many cases, it’s better to keep your old requirements document, and instead align the kind of agility your leaders want.

However, sometimes “poor leadership support” means those leaders are fighting over what “agile” means, and where to start. Here, the best way forward is to get all the key decision makers into the same meeting, and put all the cards on the table. Granted, you may need a higher-level boss to clarify her vision of success, and break some deadlocks. But until you are aligned on what objectives are more important than others (e.g. delivering on-time gives us more credibility than delivering all the features), you won’t agree on the path forward.

InfoQ: You mentioned in the book that organizations can be doing all the agile activities without true agility. What does that look like and what can they do to get out of this situation?

Fewell: First are silos. The most frequent pattern is “only developers are agile”. Colloquially known as Water-Scrum-Fall, this is when coding alone is iterative and highly automated. This is a good beginning. However, all the upstream funding and product analysis, and downstream testing & deployment are still sequential and batch-driven. Despite all the mature practice among developers, it still takes a year to go from idea into operations, from request to reality. This is the most common starting point, but similarly also the most common plateau.  

Another common thread is the superficial changing of terminology. Requirements documents become “backlogs”; phase gates become “sprints”; project managers become “scrum masters”. Unfortunately, our actual behaviors are still the same: plan everything before you do anything; follow the chain of command; divide work into silos. Granted, changing of our language might be the only kind of change we can consume in the beginning, and it could become the spark of meaningful conversation. However, it creates the temptation to declare victory too soon, when all we have is “sugar high agility”. 

InfoQ: How can we customize agile practices without diluting their potential?

Fewell: This is where the tech mindset can get in the way. No technologist wants to be caught doing something “wrong” or “off spec”. Therefore we have a rich tradition around “best practice” or RTFM (aka Read The Frigging Manual). What is normally a question of doing something well quickly turns into a religious debate. Instead, a simple rubric can lead to a more pragmatic approach to given practice. 

• What is the PAIN for this practice? For testfirst development, you may not yet have the skills to do it in the riskiest parts of the application. Perhaps you don’t have the discretion to ignore the headache of compliance documentation. Acknowledge the reality. 
• What is the PURPOSE for this practice? Every technique or method has an intent for higher order outcomes. Testfirst-development encourages earlier validation of assumptions and prevents over-engineering solutions. Nightly builds and regression runs seek to highlight defects earlier in the timeline. “Working product over comprehensive documentation” is about focusing our energy on the right things at the right time to maximize value. Go for the substance beyond the surface.
• How might we PIVOT this practice, to capture some of its value, even in our situation? Perhaps we can get a start with testfirst development, by focusing only on new features for now, and addressing legacy code after we get good at it. Perhaps we can increase momentum by deferring those same old compliance documents until we’ve nailed down a releasable product. Embrace the value of a partial practice.

InfoQ: How can we say no to transforming everything? How can we decide what to do, and what to not do, or what to do later?

Fewell: Indeed. The temptation is to fix everything at once, which is also a good way to fragment your focus, and dilute your influence. Instead, there are two strategies.

Triage based on product strategy : the popular Innovation-Ambition matrix differentiates three distinct regions for portfolio investment:

• Ignore Core offerings. Here you’re optimizing existing offerings for existing stakeholders. This is where you know what you know, you know how to win, and you know where to play. Uncertainty is lower, so you need less agility here.  
• Support Adjacent offerings. Meanwhile, there are a handful of new incremental products for existing stakeholders, as well as new customers for existing offerings. These carry a few more assumptions and are a little bit more ambitious, which merits some agility.
• Drive Transformational offerings. This is further out from your core, where you kind of don’t know how to win and you don’t know where to play. There’s deep uncertainty; high risk and high reward. And that’s where your approach should be a lot more agile.

Triage based on motivation : One digital executive advises change champions “go where the wind is blowing”. Yes, that digital project may be the most complex and ambitious in the portfolio, but the lead sponsor is set on doing it the old way. In this case, a better course would be to find the few sponsors who are already on board with changing the ways of working. For example, the ops team might be the least interesting or challenging group. But if you can show value here, you can leverage that momentum to pursue more strategic groups who are on the fence.  This pull-based approach to transformation also aligns to the customer-driven mindset we advocate for.

InfoQ: How can we combine a culture-oriented thought process with structural elements in a transformation?

Fewell: I see it all the time, and it drives me crazy. Some executive rolls out scrum, kanban, or SAFe across dozens of teams, but forgets to tell people why it’s so important, or why we need to do it now, or why this time will be different than the last time. Even more annoying is when some coach says, “we need to be agile, not merely do agile”. He hosts a dozen workshops about values and mindset, and declares victory… but nothing changes on the ground. 

Instead of taking a culture-first or structure-first approach, leaders should simultaneously address both the cultural and structural elements of change, at the same time: 

• To get our people on board with the change, leaders must contextualize the new structure, new processes, new practices. Without that context, you give too much oxygen to haters and skeptics. 
• To make the change stick, change agents must operationalize the new culture they want. What small changes will encourage more collaboration? What new metrics will incentivize smaller, faster releases? Without concrete changes, your values are just empty fluff.

InfoQ: How can we deal with criticism and complaints about not meeting expectations?

Fewell: I recommend the advice from improv theater: respond with YES, AND. Saying “YES” is about acknowledging the key concern or emotion underlying the criticism. This is called empathy. By reflecting back to a skeptic their own words, you build credibility as someone who can see all sides of an issue. 

Once you set the stage like this, you have earned the right to offer a counter position. Saying “AND” is about painting a picture of how the positive directly links to the negative, how the opportunity connects to the opposition. 

Here are a couple of examples:

• Facing criticism over limited impact? Say,  “YES, I recognize the transformation so far is localized just to the development organization, which does not yield speed-to-market nor external collaboration improvements. AND by doing so, our new internal collaboration and improved quality set an example for others to follow. Therefore, I believe we can now give it away to other champions.”
• Facing criticism over poor practices? Say, “YES, I recognize that our practices are immature, which can be frustrating and less effective than desired. AND, by doing so, we’ve introduced new ideas and concepts into our teams, which sets a foundation to evolve from. Therefore, I believe we are now able to set the textbook aside and evolve into our own agility.”
• Facing criticism over aggressive leadership? Say. “Yes, I recognize that I asked a lot from all of you, which can seem like I’ve forgotten about your workload and realities on the ground. AND by doing so, we’ve accomplished so much initial momentum; it has set a foundation of growth we can be proud of. Therefore, I believe now is the time to invest in our own personal leadership skills, in order to support the next phase...myself included.”

InfoQ: What's your advice for transforming the transformation?

Fewell: For me, this is the exciting discovery from the book. However you got stuck, it means you were already moving. That is something to hold onto. Whether it was because of your initiative or your predecessor’s, the transformation somehow got moving. We call that the BOOST. However, the BOOST can only take you so far. As the saying goes, “what got you here, won’t get you there”. 

The key is the ReBOUND, a new direction that is found by going against the grain of what got you this far. It’s best explained with some examples, so here are three of the seven ways the pattern reveals itself in the book:

The BOOST is a smart move that generates momentum	The BARRIER is the inevitable blocker that eventually follows	The ReBOUND is the way forward to further gains by leaning against the concept of the original boost
First, leverage your role to mobilize people (PMO director, CTO)	But then, they’re not on board; they’re just going through the motions	So now, stop selling agile, and start aligning to their motivations
First, install best practices (scrum, kanban) to inject new ideas	But then, they’re doing the practices poorly, and not getting their full value	So now, throw the textbook away, and tailor the practices to your situation
First, generate momentum with all the opportunities you can (pilot projects, training, playbooks)	But then, we’re overcommitted, fragmented, with impatient stakeholders	So now, master the art of saying “NO” to parts of the transformation that can wait

Too often, agile champions believe so passionately in their mission, they will double down on the initial strategy. But doing the same thing over and over will only get you the same resistance. In the end, your transformation, any successful transformation, is a series of shifts in energy, shifts in direction. Change your sails to find new wind. 

About the Book Author

Jesse Fewell is an author, coach, and speaker who advises senior leaders in transforming towards more business agility. A management pioneer, he has founded agile communities from USA to Malaysia, co-created the PMI-ACP certification, and co-authored multiple standards for the Project Management Institute (PMI). Fewell’s writings have reached over a half-million readers in eleven languages. As a global advisor, Fewell has taught, keynoted, or coached agility to thousands of leaders and practitioners across thirteen countries in industries ranging from media to finance to government. He also serves on the Scrum Alliance approval committee for other emerging agile coaches. His industry contributions earned him an IEEE Computer Society Golden Core Award.