In this series, the 6 Deadly Sins of Agile Implementations, Peter Cronin discusses the six reasons that can cause Agile implementations or transformations to go astray.
Has your Agile implementation failed to produce the benefits and results you were hoping, or had planned on getting? Maybe it seems to be going alright, but it’s not what you’d really hoped. Or maybe worse, everything has reverted back to the way it used to be, the Agile implementation or transformation has been ripped back out. There are six reasons that can cause Agile projects to fall short of expectations. The first reason is a failure to get management buy-in to the project or transformation.
How the Agile Approach is perceived
Often when people think of Agile, they think in extremes, but actually, it’s more like a spectrum. On the fully Agile end of the spectrum there are the small start-ups where they are 100% individuals and interactions, just getting some software working, working with a customer, and responding to change. On the other extreme, you have large infrastructure-based projects, where they do still need a lot of processes and tools, comprehensive documentation, contract negotiations, and they do need to be following a plan of some sort.
Where we notice a lot of the issues and arguments arising in software companies is when they try to go Agile, or implement Agile, because the principles are treated as black and white as opposed to a gradient. Although the Agile manifesto states, “While there’s value in the items on the right, we value items on the left more,” this statement is interpreted by some people as ‘we should only do the principles on the left’.
In practice, if you absolutely have to make a call between one side or the other, err on the left (Agile), but really it’s a list of eight principles which most software companies are going to need some of, at some time.
Why do we fail to get management buy-in?
The most obvious benefits of Agile are to the way that software teams work and develop code, but of course we’ve also got that commercial side of the business where we’ve got to sell something to pay for development, where we’ve got to have some plans, so that the multiple teams and individuals are coordinated towards a common goal… all of which butts heads with the Agile Manifesto (which is not in favor of focusing on plans or contract negotiations).
This is where we can lose the management buy-in.
If going Agile is being driven by the development side of the business, the focus is on the benefit to the development teams, and it can sometimes feel like the commercial drivers of the company are being forgotten about.
From the management perspective they look at it and go, “We can see how implementing Agile will benefit the software development teams but…” It’s not that they think it’s rubbish, but there isn’t quite the buy-in and motivation necessary where management will feel compelled to leap into a huge transformation project. They understand it, and they understand the value, but they’re hesitant, usually because of those commercial drivers that Agile could but at risk, or fear, leaving behind.
Win-win; it’s not either/or
For Agile champions
If you’re the one promoting Agile change in your team or your company, it’s important to make sure that you’re looking at the win-wins for both the software development aspect and the commercial aspect of the company. It’s not a black and white, there’s nearly always a situation where you can get the benefits of both. For example, you can have a plan at a high-level, based on effects, to get you heading in the right direction and still have highly adaptable teams – they’re not mutually exclusive.
For management
If you’re on the other side of this if you’re management thinking, ‘Why did this fail?’ Hopefully, we just hit the nail on the head where you go, “Yeah that’s exactly it. Agile risks losing all these commercial drivers.”
Finding the win-wins
This conflict can be resolved, and management buy-in achieved, by looking at the benefits of both Agile and Waterfall principles, and finding an alternate approach that will get a positive outcome for both the dev team and the commercial arm of the company. It’s not a compromise, you’re not going, “Oh I guess we’ll do that instead,” it’s an alternate option that you can apply that’s going to give you the perfect balance and has a win-win for both sides.
For each instance, the conflict between Agile principles and Waterfall principles come up, management and development need to have the discussion, “How can we look for a win-win, is there an alternative that gives us both?” (Related: How to make win-win decisions)
Summary
So, management buy-in, lack of it comes from either them knowing or having some sort of nagging feeling that something’s being lost in this process and very much forbidding it. at least has a risk to it. and the way that you can move forward with this is to make sure that both parties are working together to ensure this is beneficial for the company as a whole, it’s not an initiative to just benefit one side of the equation.