Ever try to convince a manager to adopt an agile project approach and failed? That happened to me recently. A new manager came onto the project and pulled out his MS Project clone. “All we have to do is plug our deliverables and tasks into this program and I’ll be able to track the project’s progress.”, he said. I smiled at him and asked if he had heard of Scrum. When he said no I started explaining the methodology to him. After two sentences he stopped me and said “I’ve worked like that sometime ago in the 90s and it didn’t work then.” That, as far as he was concerned, was that.
You could argue that someone with this attitude can not be convinced and I would agree with you. But it doesn’t hurt to think about how you can best go about convincing someone that agile is the best way to run a project., even if that doesn’t work for some people.
Recently I was writing a software development plan for a project. The project manager was open as far as development methodology goes, so I decided to try to convince him to go agile. I started the plan by listing a number of principles that the plan was based on. They were:
- risk-driven development (do the most risky items first)
- prioritizing (order functionality by business value delivered)
- flexibility (be flexible for scope or priority changes)
- transparancy (openly show your progress and delivered software)
Pretty reasonable-sounding principles, right?
My next paragraph declared that, if you value these principles, an agile software development methodology is the way to go. Then I listed the features of an agile methodology (Scrum in this case) and for each feature I described I referred back to which principle guided this feature. For instance:
- start validating assumptions with working software from the first iteration (risk-driven development)
- work in short iterations, allowing for new priorities (flexibility)
- demonstrate working software at the end of an iteration (transparancy)
- update the planning at the end of each iteration (transparancy)
- do the most highly valued functionality first (prioritizing)
When reading this document, the project manager said: “You know, this agile really makes a lot of sense in our context.” Done! 
Of course there is nothing really specific in our context that makes agile such a good fit. Rather, by starting from a set of principles that everyone agrees are a good idea and showing how agile realizes those, it makes it a lot easier to sell the approach.
