an entry from

Piotr's R&D blog

This speaker promises to explain how his organization migrated from a plan-driven (waterfall) development process to an agile one. He starts out by defining plan-driven and agile processes, including a good analogy: plan driven is like building a bridge, agile is like exploring where and how to cross a river. The difference can also be characterized by the tradeoff between YAGNI and DOGBITE: You Ain't Gonna Need It vs. Do it Or you'll Get Bitten In The End.

There follow lots of details about how to convince stakeholders to accept an agile process, and how to set up the process to have the best chance of success. I won't bother scribing all this stuff; if the slides aren't posted eventually on the ICSE site, you can probably get most of the same information from books.

Lessons learned:

1. The strongest motivator by far to switch to agile development is failure in previous projects.
2. Expect resistance from Software Engineering Process Groups (in large organizations). (A solution: rotate staffing of SEPG.)
3. The traditional procurement approach -- write requirements specs, invite for tender, select cheapest offer -- does not work for agile development. (Anecdote: WTO contracts prohibit requirement writers from bidding on the project, and limit with bidders!)
4. Completely discarding change request processes would be like throwing out the baby with the bath water. (Suggesting to have a lightweight feature request process to avoid duplication and repetition.)