Agile Adoption Patterns: 6 Common Breaking Points and How To Fix Them

A few years ago, when companies started embracing Agile, they would bring in a consultancy firm to help come up with a strategy for the shift. They would hire some Scrum Masters, provide basic training to their teams, and proudly declare: “We are Agile now.”

But that statement couldn’t be further from the truth. More than a methodology, Agile is a philosophy, and adopting it means that everyone involved should get on board with a complete and profound transformation. A transformation that, oftentimes, fails.

Richard Durnall and Dan North both theorized on Agile adoption patterns, the latter having given a Ted Talk on the subject. According to their experience, there are six stages in Agile transformation at which something breaks. In this article, we will see what those Agile adoption patterns are and what you can do to avoid these breaking points in your own Agile journey.

If your company has tried to implement Agile and failed, know that you’re not alone. In general, companies must deal with these challenges when embracing an Agile transformation:

1. Disengaged workers
2. Agile is dictated from the top down
3. Trouble implementing an MVP 
4. Missing out on inspection and adaptation 
5. Few tangible benefits are realized

1. Disengaged Workers

Gallup’s “State of the American Workplace” shows that 7 out of 10 workers are disengaged at work with 2 out of those 7 claiming to be “actively disengaged.” This means that about 20% of your team members might be engaged in activities that are more harmful than beneficial to the company. 

The Agile Manifesto mentions “individuals and interactions over processes and tools.” But if a large part of your team is disengaged, how can you start a transformation towards Agile? 

2. Agile is Dictated from the Top Down

Often, management decides that the company will adopt Agile but considers this a team-level task rather than an organizational change. Therefore, managers instruct people to “adopt Agile” and do nothing else about it, trusting that teams will self-organize and achieve the desired goals.

However, since most people feel disengaged at work, they are likely to resist change. Furthermore, adopting Agile requires a much deeper change at the organizational level. You need to rethink all aspects, from the project, program, and portfolio management, to staffing, team design, organizational alignment, performance management, and budgeting.

3. Trouble Implementing an MVP

A Minimum Viable Project (MVP) is one of the main concepts in Agile. The idea is that creating a version of the product with just the essential features will provide room for iteration which, in turn, will contribute to the team validating assumptions and building the right product.

However, if your teams are disengaged and Agile is being dictated from the top down without an actual organizational transformation, you will have a hard time coming up with a viable MVP and, as a consequence, embracing agility.

4. Missing out on Inspection and Adaptation

Inspection and adaptation are essential in Agile, as they are the key to allowing constant progress and improvement. However, these concepts are quite far from traditional ways of working and, therefore, are quickly dropped by teams who are not accustomed to them. Inspection and adaptation might feel like a waste of time, but they are not — research shows that reflecting on work improves job performance by 20%. 

5. Few Tangible Benefits are Realized

If an organization still manages to move through the four previous steps, with all its shortcomings, it will arrive at something that is, most likely, not really Agile — even though most people involved will believe it is.

But if the methodology is not correctly adopted, there will be very few, if any, tangible benefits. Therefore, teams and the organization will be quick to deem Agile as a waste of time, without being aware they are not judging Agile but rather some hybrid solution they implemented that, naturally, won’t generate the same benefits as true Agile.

The points above are generally the base issue of the Agile adoption breaking patterns. As theorized by Richard Durnall and Dan North, there are usually six stages in an Agile transformation where the process is more likely to break. Let’s look at each in detail, and understand what you can do to prevent it in your organization.

1. The People Break

When implementing Agile, if you do it the right way, most processes in the organization change. But human beings are creatures of habit and therefore, in the face of so many changes, they break. They get lost and upset about this “new world” they are forced to enter, and where they often feel uncomfortable or inadequate, especially if they are not on board with the Agile adoption.

How to fix it: getting professional help is the best approach. Have expert Agile coaches train your teams to help every member better deal with the problems associated with this transformation. Experts can also instruct the teams on the benefits of adopting Agile, contributing to everyone’s belief that the organization is going down the right path. If you need a hand on this, BuildingBetterSoftware has a proven record of driving Agile transformation and delivering results.

Getting people on board with the transformation is challenging but doable. Take the example of ING Netherlands. Back in 2014, the company successfully managed its transformation, which required 3,500 people to basically learn a new job from scratch, as they were removed from their original extinguished positions and placed into new, Agile teams.

“It started with painting the vision and getting inspiration from different tech leaders. We spent two months and five board off-sites developing the target organization with its new ‘nervous system.’ In parallel, we set up five or six pilot squads and used the lessons to adapt the setup, working environment, and overall design. After that, we were able to concentrate on implementation” —Bart Schlatmann, ING’s COO.

2. The Tools Break

As people start to embrace Agile, they realize the tools they previously used no longer serve them. The metrics they relied on to assess productivity don’t fit. The previous communication tools fall short. Everything breaks, and it needs to be fixed.

Let’s look at Lonely Planet’s example. As information consumption methods have drastically changed over the years, the company realized that the existing infrastructure was no longer serving them. After experimenting with different options, they finally settled for Amazon Web Services. Ultimately, this translated into 30% cost reduction in publishing platforms and developers being able to build around ten times as much in the same timeframe. 

How to fix it: This is mostly a process of trial and error. There are no tools that fit all teams, so you will have to experiment and see what better suits your needs. As teams become more Agile, they will naturally discover tools that facilitate the work. Also, bring this subject to Retrospectives, as they are a great moment to have everyone reflecting together on what could help improve the team’s processes.

3. The Governance Breaks

After individual teams have successfully embraced Agile and adopted new, more suitable tools, you run into a new problem: scaling Agile. It’s not just about one team anymore, you need to manage cross-team dependencies and align work at the portfolio level.

Take the example of Amazon as a company that successfully overcame this breaking point. They can deploy software thousands of times a day while most companies, regardless of how much code they write, can only deploy a couple of times a day or even a week. The reason is that Amazon has built its IT structure to support frequent releases without endangering the whole system.

How to fix it: Establish a clear vision for the organization and the product you are building, as well as guidelines for the teams to follow. Establish measures that contribute to making everyone feel they work in a culture of transparency.

4. The Customer Breaks

“At scale, the customer is no longer the customer — it’s a nebulous concept. ‘The customer’ is really a placeholder for the product direction, or understanding the market” — Dan North

Agile implies a whole different relationship with customers, one they are, probably, not used to. The presence of the customer is usually required on-site, embedded in each team. What happens when there are multiple teams working on the delivery of a product? “Customer” becomes a term that is better translated into “product direction”. 

Moonpig has had a tremendous Agile transformation that you can read about more in detail here. They achieved results such as revenue increase, faster delivering cycles, and happier staff by adopting Agile and placing a great focus on customers.

How to fix it: This is largely dependent on how organizations are set up. Make sure that there is a process for fast feedback from the users to the Agile team. Keep communication flowy, open, and clear between all parties involved.

5. The Money Breaks

Agile breaks the ways in which projects and programs are usually financed. The work is ever-evolving and work estimations are made as more is known about the project. If there are no work estimations at the get-go, how can there be financial estimations?

While this might feel like shaky ground to accountants used to a certain way of working, adopting new accounting models has proven to be successful. Equinor, for example, has adopted Beyond Budgeting and manages finances by these four rules: no annual budgeting, dynamic forecasting, high levels of trust, and a cost-conscious mindset.

How to fix it: You need to adopt new accounting models. Beyond Budgeting and Throughput Accounting are two frameworks that help organizations adopt a new way of thinking when it comes to finance. Estimates and budgets can help Agile development teams create great projects in a more efficient way—you can read more about using estimates vs budgets here.

6. The Organization Breaks

After all the changes mentioned above, it’s no wonder that the organization breaks. People have changed, the tools are different, the governance model is new, the relationship with the customer has a new dynamic, and even the accounting is different. The old organization might be almost unrecognizable after so many changes.

Bosch was founded in Germany, in 1886. A company more than a hundred years old that still managed to deeply reinvent itself by adopting Agile. As its CEO, Volkmar Denner puts it, “For Bosch agility is crucial, it allows us to adjust to the increasing speed of change around us. Agility allows us to remain in a position as an innovation leader.”

How to fix it: After all the changes, it is worth it to rebuild the organization taking into consideration value streams, flow, and validated learning.

A root cause of all the Agile adoption patterns analyzed here is the inability of some organizations in distinguishing between Agile adoption and Agile transformation.

Agile adoption is simpler, it is about embracing new processes and practices. But Agile transformation goes deeper. It radically changes not only what people do, but also how they think and what they feel towards work.

Understanding and implementing this difference might be the last barrier to making your organization become truly Agile.

In doing so, remember the guidelines we gave you in this article:

1. Have professional help to get people on board with embracing Agile
2. Experiment with new tools that better suit your new working model
3. Establish a clear vision for the organization and the product you are building
4. Ensure there is a process for fast feedback from the users to the Agile team
5. Adopt new accounting models
6. Rebuild the organization taking into consideration validated learning

If your Agile transformation still breaks at some point, remember to follow one of the most important Agile rules: inspect frequently and adapt as needed. Your organization will be on its way to success soon.

Søren Pedersen

Co-founder of Buildingbettersoftware and Agile Leadership Coach