Development Methodologies

Development Methodologies are known to draw strong opinions from developers and managers a like. Many things can come into play when making the decision as to what methodology your team should employ. Some of these decision factors include the core strategy of the company, skill level of the team developers, and central goal of the solution being developed.

1. Waterfall
The waterfall methodology has been around for a long time. It basically involves creating a detailed scope of work, getting the appropriate people to sign off on that scope of work, and then building the solution. The scope can not change and the product is finalized after the completion, unless an additional phase is recquisitioned.

I once worked at a web dev. shop that made its living with this methodology. Most of the projects were fixed price solutions for external customers who wanted to make sure they got their functionality for the guestimated price. The solutions were created in scheduled time frames and once a scope of work was defined and accepted by the client it was rarely changed. Any changes desired by the client would usually result in a phase II, III, or IV of the project.


2. Spiral
The spiral methodology involves taking a small amount of core requirements for a solution and going through the software development life cycle (SDLC) to implement those core requirements. The development team has every intention of going back through to implement additional requirements as they become apparent. This is currently the most used methodology because it allows for quick results, some agility in the requirements, and a team made up of developers at various skill levels. That being said, it is also prone to bugs and usually lacks up-to-date documentation.


3. Agile Development
The Agile Develoment methodology is the newest of the three methodologies discussed here. There are several variations of the methodology, but all share the following core concepts as stated in the Manifesto for Agile Software Development (http://www.agilemanifesto.org/)

- Individuals and iteractions over processes and tools
- Working software rather than comprehensive documentation
- customer collaboration over contract negotiations
- Responding to change over following a plan

This basically allows the development team to be self organized, have less emphasis on documentation (which is usually not kept up to date anyway), have direct access to customers (so that the projects get done exactly as the customer expects), and welcome changing requirements.

This can be a very good approach for teams consisting of self-starting, expert developers that are working on a select number of products for various internal and external customers. The methodology may not be the best for teams that require a large amount of documentation, have a business model that requires fixed prices, or have more junior to mid level developers than experts.

--------------------------------

I have worked at various companies which have put into practice each of these methodologies in some form or another. Each has its advantages and weaknesses and I have come to the conclusion that the best methodology is likely a mixture of three. My next blog will dive into one of the key features of the Waterfall method, the Scope Document.