Agile: convincing stakeholders

Agile: convincing stakeholders

Yesterday I attended BarCamp Agile Wellington, and although I had to leave early, I thought the event was a great success.

In keeping with the theme of BarCamp I thought I’d share my notes from one of the sessions: an unmoderated group discussion on Agile advocacy in large organisations, and how to convince stakeholders to adopt it.

Problems

  • Unfamiliar jargon.Terms like Agile, Scrum and Extreme Programming can be unfamiliar and scary to those who don’t understand them. What was wrong with regular programming?
  • Agile can’t guarantee certainty. A CIO’s job is to manage risk, and having watertight specifications locked down before projects commence is one way to combat it. Agile may appear riskier by leaving too much room for change, particularly in the public sector.
  • Getting the customer on team. Heavy time commitments and taking a burden of responsibility for the project’s success may not be attractive to customers.
  • Agile is not about playing cowboys or cutting corners. Agile is actually more disciplined than traditional waterfall-style frameworks.

Solutions

  • Hold the jargon, please. Don’t mention Agile, Scrums, Extreme Programming, or the Agile Manifesto by name. They aren’t really that important anyway. Perhaps ‘Agile: Everything but the name’ would be a good mantra to adopt?
  • Agile produces a self-managing team. With greater involvement from team members and customers, the traditional project manager role becomes redundant.
  • Lock it down. Sell a fixed timeframe with a fixed budget, but leave the scope open. Focus on the overall end result of the project rather than individual requirements. This way the size of your project box will be limited, but the blocks that fill it can be swapped and rearranged as you go.
  • Sell it inside out, from the bottom up. Instead of trying to convince CIOs about Agile (who more-likely-than-not will see any change as risk), focus on the people who will actually use it. Change and new ideas are interesting to developers, but scream risk to stakeholders.
  • Don’t tell upper management. Do they even need to be aware about Agile before it can be used? Do they even know what current frameworks their organisations use? Trying to convince them on the benefits of Agile may be a complete waste of time. Sell them on completion of a successful project instead.
  • Just get on with it. Why bother convincing people about Agile at all? The evidence is there, so just get on with it!