Agile failure is common but this can help

With the closing “ding” of the New York Stock Exchange, CA Technologies, the first software company to break $1 billion in revenue in 1989, confirmed that it would no longer be an independent company. Broadcom, a massive global semiconductor company, closed the deal at $18.9 billion, touting that its newfound ownership would bring diversity to its “mission critical technology portfolio.” This pivot is particularly intriguing given CA Technologies’ recent emphasis on business agility.

The move may be indicative of a greater trend baring newfound caution to the business operations system. For example, the U.S. Air Force failed to modernize the F-22 because of problems with SAFe. IBM suffered an embarrassing backlash when it called all its remote workers back to centralized offices under the guise of “self-directed teams.” Air France is still at risk of bankruptcy after going Agile two years ago.

All of these stories come at the heels of some less-touted Agile statistics: almost one in four (23%) of large Agile projects suffer from Agile failure. Over a third (37%) of Scrum projects are unsuccessful. While 95% of CIOs claim that they have an Agile at Scale experience, only 7% say that “Agile has never failed them.”

While those statistics are alarming, many companies have also seen incredible success with scaled Agile practices. For example, Northwestern Mutual was able to come in $12 million under budget. BMW was able to test new vehicles with 95% fewer defects than comparable models. Barclays was able to increase throughput 300%.

Why do some businesses thrive with Agile while others are left struggling? Three common problems - along with their solutions - are explored below.

There isn’t enough Agile experience within the company.

Scaling Agile requires advanced-level Agile teams and people with two immediate skills: mastery over an Agile practice (be it XP, Scrum, or otherwise) and enthusiasm for Agile for the enterprise. Without these cheerleaders, senior decision makers will struggle to gain buy-in across the company.

The easiest, most obvious place to look for these people and teams is within software delivery teams. If DevOps isn’t the de facto method of software delivery, prioritize that transformation first. If methods like test-driven development and pair programming are foreign to the company’s developers, hire a coach to teach them Agile best practices. If the team isn’t yet using an Agile tool that can scale across the business, emphasize that needed software adoption before getting the rest of the business on board. Without an enterprise tool, it’s tough to see the company’s project portfolio, forecast deliverables, and keep the business’s backlog in check.

At least one team - ideally an advanced IT team - needs to have significant Agile experience to justify scaling Agile across the business. A business cannot enjoy the benefits of SAFe, Nexus, or LeSS without first internalizing Agile’s foundational principles and methods; without them, the company’s infrastructure will be built on code without technical excellence, let alone unmotivated individuals and heightened complexity, all delivered at a pace deemed unsustainable to all involved.

Middle management is panicking.

Scaling Agile often requires new roles within the company. For example, SAFe introduces Agile architects; Nexus introduces the Nexus Integration Team. What Agile has no patience for is excessive oversight. That means that middle managers face a severe risk of losing their job.

The news isn’t all bad. Ideally, if the company partook in hiring T-shaped individuals, former managers can comfortably slot into newly created product owner, Release Train Engineer (RTE), or Solution Train Engineer (STE) positions. To be clear: enterprise Agile is not meant to remove individuals from the company. That said, it does remove inefficiencies, like excessive management.

There is no way to implement Agile across the business without a significant change in organizational structure, and intermediary managers face the greatest brunt of that pivot. These individuals are leaders within the organization, so if they are not enthusiastic about the changes to their position, their teams will likely reject Agile practices at large, especially if they haven’t ever practiced Agile to begin with.

Transparency is critical when scaling Agile. Remember: Agile is a mindset that prizes the individual over any process. The true Agile company creates a roadmap for all of its employees, provides options for teams to participate in the change, and executes iteratively. No one should fear - and act negatively on behalf of that fear - the immediately personal unknown in any Agile transformation.

Unspoken contracts undermine trust in the system and cause Agile failure.

Embedded teams mean creating a labyrinth of dependencies. Individual team members hold each other accountable for delivering tasks on budget, on time, and with quality; those individual tasks roll up into features, projects, products, and into the company at large. One of the best things about Waterfall is that due dates are clear; anyone new to Agile quickly realizes that due dates are more fuzzy with iterative processes. Not only do those due dates - or implicit contracts - disappear, but so too do traditional metrics.

One solution to this problem is creating a minimum viable product (MVP). This practice is well established within the Agile community. That way, stakeholders can see that the project has some tangible output, and product owners can quickly get customer feedback for improvement. From there, each ensuing release fosters greater trust in the process.

The second way to deal with this problem is to create a top-down approach to implementing Agile metrics - think closer to company-level OKRs than individual KPIs. Agile metrics mean adopting measurements like team happiness, customer satisfaction, and velocity. While monetary outcomes are undoubtedly valuable, team metrics create buy-in for Agile at the team level. Without these metrics, teams quickly get frustrated with scaled Agile, wishing to opt for the predictability and consistency of traditional business once again.

Scaling Agile across the enterprise isn’t easy

There are many more signs that a business isn’t ready for Agile at scale, with poor team communication structures and cultural fit problems not being the least of them. While business Agile promises many enticing benefits, the difficulty of undergoing an enterprise Agile transformation should not be ignored. When considering Agile at scale, look for employees and teams who could act as Agile champions, be transparent about the changes required for transition, and start weaning off traditional business practices to make way for iterative improvements. Proactively implementing these solutions will usher in SAFe’s rewards smoothly, all while building great teams, enabling effective management, and creating expectations for continuous improvement for the company at large.