Somewhere out there are developers who learn about Agile development methods early in their career. They adopt them without much knowledge of anything else, implement them smoothly, and go from day to day in the bliss of a sustainable pace, clear communication, and realistic expectations. Not me.
My journey to Agile started in earnest only three years ago when I had just achieved my MCSD.NET certification, transferred to a new job, and was handed the biggest application rewrite of my career. I was so excited! I had a team of four full time Software Engineers and two QA Leads, a motivated Manager, plus other part-time technical help. I knew my company's Product Life Cycle and the Microsoft Solution Framework and was going to do everything the way the Waterfall model said I should, even if it killed me. Which it nearly did.
As project lead I did everything right. Honest. This rewrite had been six years in the making and we gathered over a hundred requirements. We met with every customer who had submitted a request and prioritized everything from one to one-hundred and twelve. We had two months of design work, architecting a loosely coupled n-tier web application based on an internal implementation of Microsoft's Enterprise Library. We produced document after document. All of them a mirror image of what we wrote and tested. Then we went into implementation. And everything fell apart.
The first stumbling block during development was that there was no common ownership of tasks. I assigned rigid roles based on an expectation of working independently on different layers. PersonA got the GUI, PersonB got the Middleware, PersonC got the Reports, PersonD got the Database. It was the traditional team model and guaranteed that if a single person got stuck, at least one other person would come to a screeching halt.
Then there were the inherent weaknesses of Waterfall. There was no way to measure team velocity and estimate schedules. I'd guesstimate task time based off past experience when I had no working experience with the actual area owners. Slip after slip ensued. I'd re-schedule some part of the project, someone would get stuck, and everything would need to be rescheduled. Our alpha version of the project shipped nearly five months later than expected.
Then the horror of horrors for the Waterfall model burst forth: Validation. It still gives me goosebumps. Some eight months after we prioritized those requirements, six months after writing all of those beautiful design documents that nobody read, our customers finally got a look at the product. And they hated it. It was 55,000 lines of C# and T-SQL that absolutely didn't make anyone happy. We'd haggle over the requirements and eventually agree, yes, it did work the way they asked, but not the way they'd hoped. And this was a rewrite, remember. Asking if the brand new version worked the same as the old version became a taboo subject. Of course it did. But it didn't work the way it should.
I was 15 kg lighter and completely spent. And I'd done everything right. Honest. Every step of the way I did everything that Waterfall, my company's PLC, and MSF said I should. At this point my management was asking if finishing the project was worth the investment.
We were close enough that some heroic technical work, performance tuning, and promised point releases pushed us over the finish line. Three years later the app is stable, heavily used, and benefiting from that good design. And it's something I never, ever want to do again.
Next up: eXtreme Programming gets its day.
Technorati tags: Waterfall Agile