The ability to change course as circumstances dictate is the strength of the project management philosophy we’ll look at now. Agile development is based on the idea that development is an iterative process that uses cross-functional teams to solve problems and develop solutions. Adaptability is the name of the game.
In our current XML publishing project, we’ve split the initial development phase into several parts. Different teams are focusing on different parts of the system: content modeling, authoring, content management, and composition. Each group is responsible for research and requirements gathering. By splitting the tasks between groups of experts, we’re speeding up the whole project, but still are able to delve deeply into each topic.
Contrast this with our previous project, which used the traditional waterfall methodology. In that project, everyone worked on everything. Time and personnel alone imposed limitations on the project. Instead of small groups working in parallel, we had one big group lumbering along, taking on each issue in sequence.
It’s kind of like the old christmas-tree lights where if one burned out they all stopped working. What a revelation when they came out with the ones that kept working despite one burned out light.
There are dangers with agile development of course. One of the groups could go off the deep end or down a rabbit hole, or fall victim to any number of cliches as the project wears on. Different groups may have slightly different ideas of what the project is all about. For this reason there still needs to be a strong project manager who’s in charge of it all–a benevolent dictator who has the authority to say “no, that’s not what we’re looking for.”
So far, on our project, this methodology is working fairly well. Each group is able to spend ample time researching their area of responsibility. We’re getting better information than if we were all lurching around together. It’s nice not having to have every aspect of the project in your head at all times. I never learned how to juggle, after all.
At certain points, though, we all have to come together to compare notes and make sure we’re on the right track. Inevitably somebody puts together a presentation that gets shown to the management sponsors of the project. Words of encouragement are offered, opinions are aired, and we move on.
As our project continues, I’ll be keeping track of any good or bad aspects of agile development. I’ve never worked on a project to completion using this methodology before. I’m curious to see if it really will help us deliver a better system when we’re done.
Filed under: XML |