Allow me to clarify this assertion. Your enterprise Agile™ transformation will fail. Let’s not mention that 90-odd per cent of all enterprise transformations fail. And let’s not pretend that the 10 per cent claiming success are only succeeding with semantic games and reframing. This is like saying you are going to transform your kitchen through a renovation and then claiming success when you manage to purchase an energy-efficient fridge. Yes, this is a step in a positive direction, and you may even save a few shekels along the way, but it is not a transformation in any material way.
At best, this is a small-t transformation. Even if your stated goal was to purchase a new fridge, it never qualified as a capital-T Transformation. So you’d have already failed before you’d begun.
This linked 2019 article, The Top 10 Reasons Why Most Agile Transformations Will Fail, provides reasons, but I am going to assert that if you are a larger—and particularly publicly-traded—enterprise, you are doomed to failure. I’d like to comment on how these relate to your organisation, but I’ll respond in a different order. I employ the term ‘you’ to reference the enterprise, so when I ask, ‘Why don’t you such and such?’ I am talking about your organisation, so don’t take it personally—unless of course, you are the executive rationalising this transformation, in which case I am talking to you.
#6 Lack of Why
Why do you want to do Agile? Note, that this is not asking why you want to be agile. It is asking how you think Agile is going to benefit your enterprise and asking yourself if there’s not a better way to accomplish this. Given the high failure rate, you should be leery. And if you are doing it out of a sort of peer pressure, just know that your peers are either (1) not doing it, (2) not doing it well, and-or (3) cherry-picking embellished stories—like the friend of a friend who knew a guy in Canada who worked on a successful Agile project.
#4 You Don’t Get It
Although Agile does have a very specific definition, it’s a framework or a thinking modality. This means you have a little leeway. Many people think this translates into a lot of leeway or anything goes. It doesn’t. And failure to stick to the intent will ensure failure.
For example, the first tenet from the Agile manifesto is “Individuals and interactions over processes and tools.” If you think this means you need to implement Jira or some requirements management system, you don’t get it. Can you implement Jira? Yes. Will Jira help? Jira is a tool. Asking if Jira will help is like asking if a hammer will help? It depends on what you are trying to do, and it depends on who is holding the hammer. Could you use Excel or Google Sheets? Again, yes. You could use Post-It! Notes or a whiteboard. Afterall, you’d be in the same room in a best-case scenario. And of course you are looking for the best case, right?
You need to prioritise individuals and interactions. There are interactions within the team—and this is not usually the challenge—, and there are interactions between the team and the customers or end users, and the interactions between the teams and the product owners, who should be dedicating at least 50 per cent of their time and focus to the teams.
All the while remember that Agile is a software product development methodology, not an approach to project management. Mark my words, to implement both is to create an anti-pattern. If you still believe you can do both, you don’t get it and will fail.
#1 Short Span of Attention
This ties in tightly with number 3 that I’ll get to next. Enterprise transformations take a long time. We’re talking years, not months; and we’re talking 3 to 5 years, not just a couple. Moreover, this 3 to 5-year focus need to be at the same level from start to finish. I’ve found that fatigue sets in very quickly and it’s on to the next thing.
One thing I’ve found that works is to appoint a transformation officer. This is a well-connected person with political clout and capital. And this person has had to have gone through this transformation business successfully before at this same level of engagement. The guy who worked at a company that transformed but had no material hand in the transformation is not the right person. The senior exec with their heart in the right place is not enough. And the non-gender-specific guy who masterminded the transformation of a 50-employee company is not the guy to be in charge of transforming your 40,000-person enterprise.
Given the high failure rate, these people are not a dime a dozen and don’t grow on trees. If you cut a corner, don’t let it be this one. Your best candidate will probably be from a third-party consultancy. Even if you don’t have the appetite to hire this person, partner with a consultancy that has charted these waters, and stick with it. Pair them with a savvy exec and don’t short-change their advice.
#3 Lack of Executive Leadership
This is big, and it dovetails nicely from the last one. This not only needs executive-level attention, but it also needs that person to be an active participant. This is why I recommend appointing a full-time transformation officer. This should be a top-tier, C-level executive. And this person needs to be able to devote attention for the entire duration, which as already noted, should be assumed to be 3 to 5 years from the start.
A good heuristic is to imagine that the person’s role in this position should only last 3 to 5 years. If they’ve done their job, then the transformation is complete, and they can move on. If they’ve failed, they were clearly the wrong person, and I hope you had a clawback clause in their contract for non-performance.
#7 No Coalition
This item reminds that without adoption, there is no transformation. And without buy-in, there is no adoption. This means that the leader cited in number 3 needs to evangelise and socialise to build this consensus. This also means derailing or marginalising detractors. I am not going to spend time articulating adoption and change management strategies, but clearly they begin here by clearly conveying WIIFM—What’s in it for me.
#2 Process Change Only
All change needs to consider people, process, and technology. As noted already, a process change means nothing if no one uses it, so there needs to be a culture change. People need to be bought into the process and abide by it. And although the Agile manifesto says “Individuals and interactions over processes and tools“, it doesn’t mean no processes or tools. It means that a face-to-face conversation with the product owner, the end users, and the team is preferable to some requirements typed into some requirements system.
#10 Waterfalling Your Agile
To reiterate, Agile is a software product framework, not an approach to project management. See number 4 above. Agile is an outcome-based, not output-based, approach. Companies have a very difficult time with this one. See number 4 above. Also see number 2 above. You need to change your mindset.
#9 A.I.N.O.
Agile in name only. This is where 99.999 per cent of organisations reside, typically waterfalling their Agile. See number 10. They talk the talk, but they cannot walk the walk. They’ll adopt the lingo and some of the rituals—at least in name—, but that’s where it ends. A cheap imitation. It’s a Rolex with a paper watchband and it doesn’t say Made in Switzerland. Bootleg Agile is the most prevalent version. Don’t get ripped off with AINO.
#5 Copying Others
Extending numbers 4 and 9, just because you read that Google is doing this or Spotify is doing that, they are not you, and you are not them. You need to operate within your own culture, and per number 2, you need to ensure your culture embodies Agile. Understand what Agile is and how it applies to you. If you hear that Spotify is using squads, renaming your teams to squads is unlikely to move the needle. Besides, because it worked there doesn’t mean it will work here. You’d need to find out what it was about the other culture including the secret sauce to be able to replicate the results, but cultures are organic and not only not very easily copied, but cultures change, so what worked for them (or you) yesterday may not necessarily work again tomorrow.
#8 Agile Everywhere
Finally, one size does not fit all. Anyone who has ever ordered several one-size-fits-all products should know this firsthand. You need to understand when to pass and when to run to use an American football metaphor. Not everything is suited for Agile. Gartner published its bimodal model about a decade ago, and even this isn’t enough modes. But the point remains that some things need to remain in a more traditional place.
One topic rarely mentioned. I never see it mentioned is diminishing marginal returns. Perhaps this is because I have a background as an economist. What this predicts is that we might choose the best people and the most suitable product to bootstrap the process. Then the second best product will get your second best people. And the third will get the third best, until the last product ends up with whoever wasn’t chosen for the better products. This is akin to being the last kid picked for a team in gym class. No one wants Wally on their team, but you’re out of degrees of freedom. So this is a practical or structural limitation. You can kid yourself and try to convince yourself that all of your employees are top rate, just like you can imagine a basketball team with all LeBron James’s or Michael Jordans’. But you know that’s not going to happen either. Not only is there probably a Jalen Green on your team, but you also aren’t likely to have a James or a Jordan either.
Conclusion
I am convinced that you will fail. As I scroll back up this list, I note that most companies are not only guilty of ticking 1 or 2 boxes. They tick them all. That’s 10 for 10, or flipping it the other way, it’s 0 for 10. And this is why the other companies have failed before you.