Every been asked to do the impossible? I remembered a troubled project I was brought into. The prior manager had been relieved, and there was three months left on this project. By “three months left”, I mean “this is completed or scrapped by July 15th.” No pressure.
On that project, I didn’t use traditional project management or the waterfall method of development. You know how waterfall goes, you gather requirements, then you design and write specifications, then you implement in code, then you validate your code, then you put into production and maintain… three YEARS later. If the requirements change in those three years, well, you’re taking costly DCRs. Or maybe just borked. Remember the Standish Group’s Chaos Report? Waterfall development is organized, predictable, serene, and stately. The results can also completely miss the point (particularly if no real project manager is involved).
Enter “The Manifesto for Agile Programming”. It was pretty new back then, and I had gone through a seminar on XP (Extreme Programming). The premise of agile read like the Jedi Code:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
With two developers and a government-provided database administrator, we tackled the project. It was quickly divided up into modules (Larry, Moe, Curly, Schemp and Joe), each programmer assigned to the areas they worked in best. I worked the database side and interacted with the client, bringing work for acceptance daily and getting weekly signoff. Did finish on the agreed time-frame? Yes. Was the customer ultimately satisfied? Yes. And, most importantly to me, did I get paid and also get an excellent reference? Oh, yes.
It might not have turned out that way. The resources were the same. I had two great, if a little temperamental, coders. We used good system design practice, which is to say “loose coupling, well defined interfaces” and so on. Lots of projects have those and still fail. What was different was how we approached doing the project. We eliminated overhead, white-boarded specifications, increased customer interaction and rapidly responded to change. Every day, work products were shown to the customer; if something wasn’t right, it was fixed by the next day. It was thrilling. And terrifying. And it worked.
These days, I find myself using Scrum a lot. This is an overview. This is the website of the creators. Finally, if you were looking for Certified ScrumMaster® certification (which, a few years ago, you couldn’t get a development PM contract job without), head over to the Scrum Alliance.
Before I close, a couple of cautions. I’ve seen plenty of development organizations declare “we’re agile!” and use that as an excuse to do what I call “water-fail.” Huge, predictive and stately development projects on specific timetables that use NONE of the design practices of waterfall because “we’re agile!” Meanwhile, sprints are multi-month long, communication is lacking, specifications are non-existent. Don’t do water-fail. And even if you avoid that trap, watch code velocity vs. stability and react appropriately. You’ll thank me later.