When business is lousy, getting projects approved and budgeted is challenging. Which means, tough times are good times to be agile. [This is part of the Tough Times series.]
There was a time when you could propose a project that called for so many months of requirements evaluation, so many months of design, and then development and eventually deployment sometime next year. No longer. Anything even faintly smelling of the waterfall model is increasingly DOA.
Because when money’s tight and the future’s cloudy, most executives are going to be focused on surviving the next quarter, not some big win a year down the road. On top of which, the savvy ones know that kind of project is rarely delivered on time.
But just because times are tough doesn’t mean we’re going to stop developing projects. It just means we have to be agile about it.
The classic Agile approach, where you pick two or three key features, spec ’em out with test suites that involve the business side, build ’em and test ’em, and then think about maybe going back for the next two or three, well, that’s starting to look awfully attractive.
By the way, I just ran across Richard Gabriel’s Lessons From The Science of Nothing At All, which gives a good philosophical overview of Agile thinking, aimed mostly at the non-geek. It might be helpful in making some points to your management chain.
You know who this is probably going to hurt? The big-system “blue-suit” system integrators: Accenture, BearingPoint, and their ilk. They, and their customers, have typically lived and died by the big-up-front-requirements paradigm.
Someone needs to figure out some good contract structures to support outsourced agile development.
And for heavens sake, if you haven’t gotten comfy with Agile techniques and thinking, get on it right now.
Contributions
Comment feed for ongoing:
From: luis (Oct 12 2008, at 22:34)
<i>Someone needs to figure out some good contract structures to support outsourced agile development.</i>
I'm working on a research project in that area at my school this semester and next. It isn't explicitly about agile (the lead faculty members wouldn't know what agile was if it hit them in the face) but it is about software contracting under non-traditional, more dynamic conditions. If you're curious, I'll let you know if/when anything gets published.
[link]
From: Bob DuCharme (Oct 13 2008, at 06:39)
I once worked with a woman at a large company who felt that the way to make a project come in quickly at low cost was to use the word "agile" in as many sentences as possible. I started referring to this as the Donald Rumsfeld school of project management. Since then I've worried that, like so many other technical terms with specfic meanings, "agile" has crossed into trendy buzzword territory where the meaning gets too diluted for too many people.
[link]
From: Jacek (Oct 13 2008, at 12:56)
Good point, Bob. The only way to prevent this is to name it the Cockburn-Highsmith-Sutherland methodology (or something, these are just some selected names from http://en.wikipedia.org/wiki/Agile_Manifesto - I don't know any of the gentlemen). Then its meaning wouldn't be tweaked like it is with a name that's a normal, well-known word. 8-)
Not really joking.
[link]
From: bob (Oct 13 2008, at 20:11)
Agile is great. But what your talking about is the use of "Agile" as a marketing device to internal management.
Doesn't work. It matters not if development is using "Agile" methods when no corporation is setup this way.
Its a gimmick. Corporate structures are not agile, they are waterfall. So if you cant get the sales team to talk to the customer and the requirements team to talk to the sales team and project manager to talk to development and have all gears turning at once. Forget it.
If you can sell a project this way knowing that you cant really deliver anything of value then go for it.
Most software efforts are still waterfall in nearly all companies. Iterative development is still a ways off much less agile.
Keep it real and work in a real company with deadlines and expectations. With Agile you will die only quicker.Buying time is not a strategy...its assumed regardless of the development model.
Agile is just trying to sell "Hello World" for real money.
[link]
From: Pete Lacey (Oct 14 2008, at 07:16)
Tim, have you been peeking at our business model? What you say here and in your "Free-Software Now" post is exactly what we do. "We" being the Collaborative Software Initiative (http://csinitiative.com/).
And to Bob who noted that corporate structures are not agile, our experience has so far been otherwise. Everything changes when a customer sees working software just four weeks after the deal is done.
[link]