The Three Broad Stages of Agile Adoption and Maturity
Explore the 3 stages of Agile adoption and how businesses evolve from traditional methods to agile ways of working.
I’ve been involved in technology initiatives for over 30 years and have been working with Agile for the last 16. In my conversations with clients and students, I am seeing some interesting patterns of agile adoption.
These patterns don’t follow the expected pattern of innovation adoption that other new ideas have followed. So I have attempted to describe what I see as the stages of adoption. Let’s explore.
The Rogers Diffusion Curve
The Rogers Innovation Diffusion Curve, also known as the Diffusion of Innovations theory, is a model that explains how new ideas, technologies, or innovations spread within a society or a market.
It is divided into five categories of adopters as shown in the chart below. This model helps businesses and organizations understand how to target different segments of the market based on their adoption tendencies, allowing for more effective marketing and diffusion strategies.
I’ve discussed the Rogers Diffusion curve as it applies to agile ways of working in my agile training classes. Since Agile has been around since the mid-1990s, one would imagine that most people have already adopted it. Which I think it accurate. There are still a few laggards out there who are trying to figure out how to apply Agile to their current work but otherwise, most people have already adopted Agile.
However, this approach doesn’t accurately reflect the current state of agility. That is because, for the majority of organizations, they have not fully embraced agile ways of working. Instead, they have simply co-opted some of the terminology and have A.I.N.O. or, agile in name only. They continue to do the same thing and call it by agile names.
Let’s look at what I believe is a more accurate description of the stages of agile adoption. I have labeled these three stages as Pre-Agile, Primitive Agile, and Partnership Agile. Let’s take a look at each of these and then explore how we can use this to help organizations.
Stage 1 Agile: Pre-Agile Ways of Working
I was fortunate enough to work in technology back in the 1990’s. Most of my experience was with waterfall with a few agile experiments here and there. Though Scrum and XP were both created in the 1990s, adoption was slow. The prevalent paradigm was the waterfall project.
Waterfall projects were plan-driven. The key to technology projects at this time was predictability.
Some of the key characteristics of what I would call “Pre-Agile” include:
1. Using the Project Paradigm
Most initiatives used projects which mean they were treated as unique and temporary. We pulled together an appropriate team, picked a project manager and empowered that project manager to task manage everything and direct the work. We had a single throat to choke.
2. Big Planning Up Front
Most initiatives at this time featured an initiation and planning phase.
3. Requirements Focus
Requirements were known to be problematic so most organizations invested heavily in collecting detailed requirements and then getting them ‘signed off in blood’ by the stakeholders or project sponsor. There were even tools to help manage those requirements — DOORs being one of the more popular ones.
4. Fixed Price, Timeline, and Scope
Once the requirements were signed off, the vast majority of projects were treated as fixed price, timeline, and scope. There was a belief that the plans were accurate and that just managing to the plan would result in a successful initiative. This set up an adversarial relationship between the stakeholders of the project and the team delivering it. The delivery team was incented to do everything possible to resist changes in scope unless the change resulted in more cost and more time. This set up a win-lose scenario and pitted the two factions against each other.
5. The Blame Game — Not surprisingly, this often led to the blame game. When things did not go according to plan (which was almost always), there would be finger-pointing and blame. The blame was justified and expected based on the
- The Business Stakeholders would blame the technology team for not understanding their requirements, taking too long or being too expensive.
- The Technology team blamed the stakeholders for not being able to articulate what they needed and for changing their minds.
6. Failure was Rife
In the 1990s, two of three technology projects were considered failures. And things did not get much better over the years for this plan-driven, waterfall approach.
7. Employee Engagement Was Low
Though it wasn’t measured back in the 1990s, employee engagement would have been low. Many of the large technology projects became death march projects. They consumed everyone on the team and burnout and turnover were high.
There are still organizations that work in this pre-agile space. Some continue to use Waterfall despite its shortcomings. Others use code and fix or other unstructured approaches.
Thankfully, the problems related to the waterfall approach resulted in the invention of alternative approaches and frameworks and the 2001 Manifesto for Agile Software Development. That initiated Stage 2.
Stage 2 Agile: Primitive Agile Ways of Working
While some organizations adopted Iterative and Incremental Development, Scrum, Extreme Programming, or another agile framework prior to 2001, it was the 2001 Manifesto for Agile Software Development that served to codify agile ways of working. And the most popular of the various agile approaches then and now is Scrum.
I label this the ‘primitive’ agile ways of working because of the characteristics of most teams at the time. Sure the teams in this stage use agile words. But do they use an agile mindset and approach? Not so much. The theme of Stage 2 seems to be control. Unfortunately, most of the problems with the plan-driven approach still exist in Stage 2 Agile, including the adversarial relationship.
Some of the characteristics of Stage 2 Agile include:
1. More Projects
While agile ways of working generally leverage a ‘product backlog’ and teams can be aligned to value streams, the vast majority of teams using Stage 2 Agile organize around projects. Projects represent big batches of ‘unique’ work that have a start and finish. Like their waterfall predecessors, most Agile teams are still in the position of trying to hit commitment dates that are set by others rather than working off the prioritized backlog as quickly as possible.
2. Assignment of People to Multiple Teams
Stage 2 agile also involves assigning people to multiple teams to get more done by the same amount of people. Assigning people to multiple teams forces multi-tasking and context-switching, it actually results in less productivity rather than more. But it gives the illusion of lots of things underway and it pacifies leaders who really should know better.
3. Focus on Velocity and Generating Features
Stage 2 agile usually means that teams are required to use an agile lifecycle management tool like Jira. These tools do support development but they also allow for micromanagement and focus on the wrong things like output and velocity. Rather than the teams delivering against customer value, most Stage 2 Agile teams are simply feature mills with the teams pumping out as many features as possible.
4. Lack of Self-Management
One of the agile principles that is conveniently overlooked by practitioners in Stage 2 relates to self-organizing teams. Most teams are led by a project manager, who is rebranded as a Scrum Master. Or they are led by the department manager. Teams are not self-organizing and they don’t make decisions about the tools they use or reports that are helpful to them. Teams simply follow orders and continue to pump out whatever features they can.
5. Continued Adversarial Relationship
While agile done well is intended to get business stakeholders and agile teams aligned with the same objectives, it rarely happens. Certainly, there is a Product Owner role who could replace the project manager or business sponsor from the prior ways of working. But rarely is the product owner on the same page and ‘one’ with the technology team. This is because of all the above that the teams don’t generate as much value as hoped or desired. As a result, there is friction with business stakeholders who may try to compensate by setting more aggressive delivery dates for the team in the hopes of accelerating development. The friction is evident in the language used which tends to be us and them — the business vs. the tech team.
6. Employee Engagement
Employee engagement at this stage is somewhat stable. As I wrote in a separate post on employee engagement, the statistics today show that for a team of 6, there will be two engaged employees, 3 disengaged, and 1 actively disengaged. These global engagement statistics should give managers pause.
Both the Pre-Agile and Stage 2 Agile stages seem like necessary steps to get to a pure or true state of agile. Unfortunately, most organizations have stopped here. They feel that they are agile enough.
Or more commonly, they simply rebranded things and kept using waterfall thinking and agile words to deliver. They are comfortable in this space because they can claim to be using agile yet they have absolute control over the teams, the work, and the measurements.
I am not optimistic about any of these organizations moving to a more mature agile approach, or what I call Stage 3 Agile.
Stage 3 Agile: A True Agile Business Partnership
I named Stage 3 Agile as a true agile business partnership because I think that is the essence of this stage — partnership.
In this stage, which is rare, there is no separation of ‘business and technology’; everyone is the business. That is, everyone is trying to advance the goals of the organization and meet the needs of the customer.
Teams don’t think of themselves as subservient to ‘the business’ as much as doing their best to uncover customer needs and meet them in the most effective way possible. All areas partner together to delight the customer and maximize the delivery of business value.
1. Focus on Business Value
Stage 3 Agile teams focus on the business value. They use Lean Startup techniques and short experiments to uncover hidden business needs or test out assumptions. They measure themselves using true business metrics — things like revenue generated, new customers added, or cost or time savings.
2. Self-Management
Teams are truly self-managing without a boss of any type on the team. They don’t have project managers or department managers hiding in Scrum Master costumes. If they have Scrum Masters, they are experienced individuals who excel at coaching.
3. Transcendent
Team focus has evolved from pushing stories and velocity to serving a higher purpose. Team members are aligned to the purpose and motivated by it.
4. Employee Engagement
Employee engagement on these stage 3 agile teams should be high. They are self-organizing and autonomous and they are aligned to the purpose of the organization.
How Many Are in Each Stage?
If I had to guess, I would break down the number of organizations roughly into these numbers.
- 10% — Stage 1 Agile or Pre-Agile
- 70% — Stage 2 Agile or Primitive Agile
- 20% — Stage 3 Agile or True Agile Partnership
Yes, I know that seems low. What do you see? Do you think my breakout above is directionally accurate?
The reality is, that most of the organizations today are in Stage 2. And they are pretty much happy to be there. They are not clamoring to get better. They have introduced just enough “agile” to mollify stakeholders that they are using modern techniques. Even though they really are not.
Bottom Line — Stages of Agile Adoption
The Rogers Diffusion Curve falls short of explaining the way agile ways of working have been adopted by organizations. The three stages I have identified above do a better job of explaining agile adoption. And the current levels of adoption indicate that there is a potential for more adoption of True Agile Partnerships.
⭐️Thank you for reading. If you enjoyed this article, feel free to hit that clap button 👏 to help others find it.
Let’s connect on Twitter or find me professionally in Linkedin.
Leave a comment below if you have any questions, and subscribe to receive the latest updates in Agile and Scrum.
Anthony Mersino is the founder of Vitality Chicago, an Agile Training and Coaching firm devoted to helping Teams THRIVE and Organizations TRANSFORM. He is also the author of two books, Agile Project Management, and Emotional Intelligence for Project Managers.