Today there are a number of software methodologies and depending on your bend (and amount of scarring) you’ll likely lean in one direction or another. From waterfall to agile and everything in between, software methodologies create a lot of discussion, heated debate and confusion. If you’re in an influential position or at least in a position to comment, it’s important to be open, avoid the fads, take a measured approach and remember the lawyer answer, “it depends.”
Software methodologies are working models that continue to evolve over time. I know folks that were convinced the waterfall process was perfect when they were first exposed to it. I believe that selecting the best software methodology is situational depending on the organization, actors and product/project. Many professional service firms have a four or five stage variant of the waterfall process i.e. (Discover, Define, Design, Develop, Deploy) or (Discover, Architect, Build, Deploy). This makes sense, as most of their engagements are projects with a start and stop around a fixed set of requirements. Once the project is complete, they move on. Conversely if an organization is managing a software product, they have ongoing product management activities that can be tough to manage with waterfall. Agile may be a much better fit for organizations that have fixed development resources, continuous development needs and more variable business requirements.
Even in a professional services capacity I’ve seen an agile approach work great when there weren’t any defined requirements and a short deadline. It provided the client a way to quickly prioritize and understand implications of their decisions. You don’t have to practice agile to appreciate short meetings where people ask what was accomplished, what will be accomplished and what are the risks. The 37signals team follows a very light approach that enables them to make quick iterations on their products. While that approach doesn’t exactly translate for larger organizations with a large number of stakeholders it doesn’t preclude larger organizations experimenting with iterative methodologies. The danger is taking a polarizing position where a methodology becomes ideology.
We should standardize for the right product, project, process and organization but not to the point of exclusion. Experiment with the methodologies and associated tools that make sense. All methodologies change over time but remember it is just a means to an end.
“Don’t let your ego get too close to your position, so that if your position gets shot down, your ego doesn’t go with it.”
-Colin Powell
Reference and Further reading
http://en.wikipedia.org/wiki/Waterfall_model
http://en.wikipedia.org/wiki/Software_development_process
http://versionone.com/Resources/AgileBenefits.asp
Leave a Reply