How can I increase management buy-in of Agile adoption?

Question

In my current role we manage our web development using Scrum. This has been really successful within our team (improving productivity, spotting issues early and increasing collaboration) but outside of the team, management still expect to see more 'traditional' measures of project progress, specifically documented milestones with exact delivery dates. I can (and do) work towards these, using our backlog and velocity to calculate the likelihood of delivery on these dates.

However, I would like to see the organisation embrace agile more widely, not least because it will reduce the amount of time we spend 'translating' from one methodology to another.

How can I effectively sell Agile to non-technical, senior staff who favor more traditional methodologies?

Answer 1

What Management Wants

In my experience, what executives most want is more control over a project. "Control" in this case doesn't necessarily mean micro-management (although it often devolves into this); rather, it means more dials to twiddle in order to adjust the project on the fly.

Of course, they don't always know that they want this. Part of a Scrum Master's job is to educate senior management on how the framework provides increased opportunities to review progress, adjust priorities, and shift strategic directions at predictable intervals.

What Management Fears

Most people--not just the ones on Mahogany Row--fear change and loss of control. Trying to sell Scrum based on "self-organizing teams," or on the benefits of having teams limit work-in-progress to what they can complete within a time-box, is inherently doomed to failure unless the tone at the top is already pro-agile. Then again, if senior management has already drunk the Kool-Aid, then you wouldn't need to up-sell the value of agile practices in the first place.

What Management Needs

No matter what the company does, or what methodology its projects follow, increased transparency is the number-one tool for improving any organizational process. Transparency gives senior management more knowledge and insight into the project, allowing them to twiddle dials in a more-informed way.

Of course, transparency comes at a cost. It means that organizational roadblocks and poor management decisions are made visible, too. It's not only successes that are visible to anyone who cares to look; it's the failures as well.

Smart executives already know these things intuitively, and they also know that the benefits of transparency usually outweigh the political pitfalls---except in highly-toxic organizations, of course. When they see how the agile inspect-and-adapt cycle increases transparency while reducing political risk, the whole thing often sells itself.

Closing Thoughts

Give senior management what they want, ensure they get what they need, and avoid stirring up what they fear. It works for marketing everything else from micro-widgets to jumbo jets, and it can work for agile methodologies, too.

Just remember, you aren't trying to sell senior executives on anything. Instead, you're offering your organization a chance to buy success by investing in process engineering.

Answer 2

Generally, treat this as you would any other change management project. By identifying and engaging your stakeholders, getting them to a shared vision, working with them to define a solution that adds tangible business value, and then moving towards implementing the change you will all get to a better place together.

Some more specific suggestions:

• Accept that this will take time and needs tailoring. You won't get by-the-book Agile tomorrow, so don't set this as a goal because you will set yourself up to fail. Figure out with the stakeholders what will work for your organization and go with that.
• Provide realistic estimates of benefits and costs. You will get business buy-in when you give them a solid business case for the change. Look at the dollars and cents objectively and convince yourself that the business case is there. If you can't look at it objectively get someone you trust to do it, otherwise you run the risk of presenting a poor business case and embarassing yourself.
• Avoid labelling it as Agile or anything else. You want to minimize resistance to change, so why give resistance a buzz-word to focus on and unite against? Much better to promote the change as a "business process improvement" or something similar.

Answer 3

For me, Doug B's comment "Accept that this will take time and needs tailoring" is arguably the most important starting point - at least in terms of your mindset as you embark on this form of process change.

I would add one thing: don't approach this formally at the outset. In one company I was with, a few of us "quietly evangelised" for several months. In meetings, we would mention that there was "another way to approach that issue"; in reports we would recommend "agile-like" processes; one of the guys took the opportunity to give a lunch-time lecture (as part of a broader knowledge-improvement intitiative within the organization) on agile, who used it, and why.

By setting the scene like this it gave the initial, more formal, entreaties some context, and made them much less scary for management. It was time consuming, it was not 100% successful in getting Agile methodology used on all projects, but it did see buy-in that legitimised adoption of Agile by a number of our projects.