I’ve been reading about Agile Software Development this evening. I’ve never really categorized my preferred style of development, but I’d say it closely resembles the Agile style.
Basically, Agile development involves short iterative cycles of development with frequent deliverables. There is minimal planning and the stakeholder is frequently consulted for feedback. The goal is to have a working release at the end of each development iteration with minimal bugs. The iteration is complete when it passes tests. Then it’s time for feedback and the next iteration of feature development. Working software is the primary measure of progress.
It seems that with the Agile development methodology, you are more likely to have a Mission Statement than a Project Plan. You are working toward an end goal, but the path may not be predictable.
I find this quite interesting. In my office, our Project Managers want to have project plans that boil down to: Development will begin on ??/??/???? and end on ??/??/???? and will take X hours. Testing will begin on ??/??/???? and end on ??/??/???? and will take X hours. Deployment will occur on ??/??/????. The end result will contain features 1a, 1b, 1c, 2a, 2b, 2c1, 2c2, 2c3, 2d.
This method of strict project planning isn’t all bad, but it isn’t very darn likely either. Crap happens. Features change. We learn something new. This is why I lean more toward the Agile development philosophy. It makes allowances for unexpected circumstances. Nay, it expects crap to happen.
I’ve worked on many different projects this year. A couple stand out as being particularly complex and high profile. The first one followed a strict project plan. No wiggle room.
“We must have the project finished on this date. Create a project plan that fits this end date, then make sure you hit the date, no matter what.”
So that’s what we did. The business owner started wanting changes almost immediately, but it was too late by then. We didn’t deliver anything for testing until just before the end of the project. There was no time to change/add functionality based on feedback from the stakeholder at the last moment. Had we made small deliverables all thru the development cycle, we could have flushed all of that stuff out before the due date. Instead, it was a single massive deliverable with no room for changes. The software worked as requested, but the business owner didn’t request everything that it needed to do. Now we’re faced with large sets of feature enhancements for an application that just went live in what was supposed to be it’s final form.
The second project had a looser project plan, but still a firm date. It was approached a little differently.
”Here are the goals of the application, and a simple flow chart. Here are the milestone deliverables.”
Instead of working strictly toward the end result, I developed iteratively with the end result always a distant thought. I delivered the first milestone within a few days. It didn’t do much, but it worked. All other functionality would derive from that. Over the next several weeks, I delivered more components of the application in iterations. Each iteration was a working application that was immediately ready for user testing and feedback. These quick iterations didn’t completely fulfill the goals of the project, but each got us closer. And each iteration kept the stakeholder involved and giving feedback. After completing a particular iteration, I discovered the project was done.
We shifted directions a couple times on this second project, but those direction changes evolved from our understanding of the project and requests from the stake holder, and contributed to a successful deployment without a slew of changes shortly thereafter. I attribute this to the fact that the application evolved during the development phase to be exactly what it needed to be.
