Agile works because it is designed to help teams adapt to changes in direction. Agile is designed to minimize the pain of changing requirements. Agile proponents believe the premise that requirements will change and no amount of upfront planning will impact that. They believe that the requirements simply do not exist until after something has been built, because users don’t know what they want. Agile processes save a lot of time by not doing big upfront requirements gathering or design work. They also don’t involve big up-front planning. They do small planning work. And they do it again and again, throughout the project. This works because they minimize wasted planning effort.
Agile’s biggest strength is based on minimizing wasted planning effort.
Agile’s biggest weakness is that they minimize forecasting. Most companies today, when they commit to a million dollar project, want to know what they get for their money. They want to know when they get it too. And they want to know before they sign the check. The less planning you do at the beginning of a project, the less you know about the end of the project. This is hard for non-Agile companies (or executives) to swallow. By minimizing the upfront planning, Agile teams minimize their ability to forecast the pending results.
Agile’s biggest weakness is based on minimizing upfront planning effort.
Ready, Fire, Aim!
Planners like this phrase, because they believe it doesn’t apply to them. Aim first, fire second. Duh.
Ready, Fire, Aim, Fire AGAIN!
Agile teams might think of writing software like duck hunting. Until you do something (like fire) to flush the ducks, you don’t really have any good targets. It’s the second shot that counts.
Ready, Fire, Fire, Fire!
Thanks Steve Pavlina for this great phrase! Agile teams would argue that the initial aiming is pointless, so a waterfall project is really just firing a lot. An incremental process aims after every shot.
While Ready, Fire, Aim, Fire Again! might make sense, an executive is worried that the team doesn’t know where the ducks are! The executive is probably hearing
“You don’t know what you want yet so neither do we. We’ll start doing stuff (and you’ll start paying us money) until you figure it out. We can’t tell you when we’ll be done, or how valuable it will be, because we don’t really know what it is yet.”
This is very scary for an executive.
Would you buy a house from a builder who said
“We’ll decide on the foundation after we see the lot. Once you see the foundation, you can decide how many rooms you want.”
The end result might very well be a house that makes you happier than one you design up front, but its hard to imagine signing the mortgage.
Its a matter of trust. Executives have to take a leap of faith to agree to fund a project that promises to deliver what they want, without defining what it is that they want. Personal relationships matter. A good salesperson matters. There are a lot of ways to build trust – a couple come to mind. Make the executive want to trust us. Religion works this way. Using anecdotal data is tough – do you compare a successful project to the failed project that didn’t happen? Direct comparisons are limited. I think sales is the key here.
If you’ve sold an Agile project to a sponsor who has never experienced one before, how did you do it?