≡ Menu

Why Enterprise Agile Transformations Usually Fail

Last week, I attended and presented at Agile Development Conference – East, and within a single 8-hour period, had the privilege of speaking with three senior leaders charged with driving “Enterprise Agile Transformations” at their respective IT organizations. These leaders are in different industries, don’t know each other, and have each been with their companies for over 10 years. They are all sober-minded techies at heart, and have earned the trust of their teams, peers, and top execs by being responsible, competent, open, and empathetic. They also have complete executive support, along with healthy budgets for training, tools, and reputable coaches & consultants.

In spite of these enviable advantages, however, the descriptions of their respective Agile Transformations were painfully similar:

“We are five months into our third attempt at transformation, and are only now seeing the beginnings of a shift in mind-set.”

“We won’t be able to show any concrete ROI for quite some time.”

“Some of our most senior technical experts have left…I guess that’s to be expected in any transformation initiative.”

“We knew that the dramatic changes we sought would meet with pockets of strong resistance…if we can’t bring them around, we’ll have to move forward without them.”

After nearly 25 years of hearing statements like this on all manner of “organizational change” initiatives, I can’t say I was surprised. However, the Agile movement has been very successful as a mostly grass-roots driver of performance improvement at the project level, so I was hoping to hear at least a few tales of warmly embraced large-scale adoption, team-based behaviors spreading in a virtuous cycle of camaraderie, and management systems designed to promote unity of purpose across the enterprise.

Before delving into the cure, it’s important to make sure we first understand the disease. For starters, the widely held assertion that “people resist change” is fundamentally incorrect. People willingly change their lives dramatically all the time, getting married and divorced, having children, moving, changing jobs/careers, going to night school, starting businesses, and so on.  All of these involve substantial risk, and most require significant financial resources, yet they are all commonplace. So, people are not genetically predisposed to resist change, they are just smart to avoid the changes they perceive as wrong-headed. Imposing Agile (or any other single method) across an organization is wrong-headed.

In his watershed book Drive, author Daniel Pink provides evidence to suggest that, after meeting our basic material needs, we are motivated by three things more important than money—specifically, autonomy, mastery, and purpose. Knowledge work offers humankind particular opportunities to obtain all three, and Agile and other methods have given IT knowledge workers better ways to pursue all three. So, if people aren’t change resistant, and if we have uniquely effective ways to motivate knowledge workers, then how is it that we’re missing the mark so badly in our transformation efforts?

I contend that the problem starts with the misguided notion that, because people resist change, we must push hard to overcome this resistance. This is backwards. People resist change because they don’t like when things are pushed on them in the first place—the loss of autonomy is de-motivating. None of the examples of big life changes listed above are decided by anyone outside our immediate families, and nearly all are simply chosen by individuals autonomously.

So, you might reasonably ask, “How is it possible to allow individuals to choose things autonomously, and still have everyone in an organization aligned toward a common purpose with a common approach?” This is where the “management systems” mentioned above come into play. Here’s what I mean:

1. Communicate Overarching Objectives. Rather than attempt to assert that “management knows best,” that Agile or any other single approach is the answer, and that all must either fall in line or be cast out, start by stating objectives that everyone should already be fully aligned with. For example, “We want to get more done, more reliably, and in a way that increases employee satisfaction, in order to deliver greater value to customers and have a stronger, healthier organization for many years to come.”

2. Emphasize Practicality Over Zealotry. Communicate that there are methods available from multiple domains that can help achieve these objectives, and that the emphasis will always be on what works best for the organization, as opposed to zealous adherence to any single approach. This makes clear that the organization trusts its knowledge workers to do what’s best. Such trust and autonomy are highly motivating.

3. Identify Areas of Common Purpose that the organization is committed to protecting, enhancing, and managing. For project-centric organizations, this must include a way to buffer projects against inherent unpredictability, focusing everyone at all levels on conserving and protecting project buffers across the portfolio. Regardless of the type of project methodology used, or the type of buffer employed, all projects must hedge against a multitude of risks in order to have any hope of being successful, and all in the organization are aligned in their desire for a high volume of reliable project completions. For senior management, this presents a unique opportunity to build trust by providing much-needed top-cover, “owning” the aggregated risk across the project portfolio, and offering support when risks cannot be avoided or mitigated.

4. Focus Attention on What Drives High Performance, improving the flow of tasks and projects, and boosting reliability by minimizing variability where possible. For example, if some teams use Agile sprints to improve flow and consistency by breaking down large batches of tasks into smaller ones while minimizing distraction and task switching, then great; if other teams have other ideas for improving flow and focus, then that’s great too. As long as the objectives of “getting more done, more reliably” are continually encouraged and reinforced, people will generally be very motivated to contribute ideas and approaches as a team, experiment with what works, and toss out what doesn’t. The culture of high performance will grow stronger, while the variety of methods in play will winnow themselves down naturally to a manageable level.

5. Highlight Successes in a healthy mix of “quick wins” and more challenging trial-and-error success stories. This will reinforce team success, expose ideas that work to anyone interested in trying them, and make clear that prudent risk-taking is encouraged to overcome the more daunting obstacles.

Interestingly, these five “management system” components take quite a bit of burden off of senior executives, while providing a way to focus their energies on where they’re needed most. They also engage the talents and creativity of knowledge workers much more effectively than any “management-knows-best” approach. And while training will surely be required, it’s provided when individuals and teams ask for it, as opposed to “just sending everyone to Agile training.” This is far less costly, far less disruptive, and far more likely to be applied for the benefit of organizational performance.

Above all, never lose sight of what makes Agile and other methods successful in the first place—valuing speed, reliability, transparency, team performance, and trust in the knowledge worker, all in the delivery of high value to the customer. Any attempt to elevate project/team-level methods like Agile to the enterprise/portfolio level will be much more successful if it strengthens these values. The sad irony is that the most prevalent Enterprise Agile methods and approaches violate the very value systems that underpin Agile itself.

Have similar experiences to share? We’d love to hear them. And if you’re curious to learn more, we’ve gone into a good bit more detail in our new book, The CIO’s Guide to Breakthrough Project Portfolio Performance, describing how to apply specific techniques from multiple domains to achieve dramatic enterprise-level performance improvements.

0 comments… add one