The software industry includes many different methods for developing and publishing code/software, including waterfall, prototyping, spiral and so on. Software development is like Baskin-Robbins ice cream — there are 31 flavors.
OK, maybe not exactly 31, but there is a wide diversity of software development methodologies. Rather than go into each one and touch on the pros and cons, I just want to briefly talk about agile development at a high level. It may be necessary to choose your software development life cycle (SDLC) flavor based on the size of the project and the complexity of the requirements. If you decide to practice some form of agile development, which is a strong possibility, then there are some things you should be aware of.
The agile software methodology is an incremental and iterative approach to developing projects and, much like software development life cycles, in general, it has a variety of diversity and practice. It focuses more individuals and interactions where those elements are more important than processes and tools. In some cases, in an agile approach, developers are required to have extensive knowledge and past experience developing systems as well as be co-located with the actual end-user as much as possible.
The customer or end-user needs to be just as knowledgeable as the development team, providing constant feedback, due to the ever-evolving requirements. Requirements in an agile approach are not initially well-defined, and for the most part, are incomplete at the outset of the project. Requirements rapidly change through end-user feedback loops and evolve over time as the project progresses.
There are many advantages to agile programming, the biggest of which is minimizing project risk due to developing an evolving product with minimal initial expectations. Constant end-user/stakeholder feedback grows the product into what is actually requested and at any point in the project, an actual functioning prototype exists.
Traditional waterfall methods do not provide that advantage; rather, the end-user’s involvement is mainly prevalent in the requirements phase and product-acceptance phase. Basically, the end-user provides a set of requirements, and the rest is up to the interpretation and understanding of the project team.
It is silly to assume or even believe that requirements are never going to change during a project. It’s the way of life for any project in any industry. If the outcome isn’t what the end-user requested, then one can end up in a costly situation. Agile methodology mitigates that risk by slicing the project life cycle into smaller more manageable milestones, with the end-user reviewing the product at the end of each milestone and providing feedback. Rework at this point is not as costly, since the product has yet to evolve. Lower-risk release cycles promote better design and communication.
Another benefit is that the end-user actually has a working product in their hands during the initial stages of the project as opposed to the traditional delivery near the end of the project. This gives not only the end-user but also the project team a sense of good progress.
One of the best practices for agile software development is to focus on the task and not the individual status. Focusing on smaller tasks, instead of the overall status of the project means more focused, smaller and more frequent releases, which ultimately equates to a feeling of accomplishment and progress. Smaller tasks are easier to track, and progress is measurable. Win-win all the way around.
In summary, the agile methodology is powerful. It offers a different style in managing and executing projects. Better communication, more sound expectations, greater flexibility and improved task-monitoring are only some of the benefits to being agile. There are plenty more SDLC methodologies out there. But, they aren’t all sunshine and rainbows, either. There are also consequences to adopting the agile methodology that fuel many great debates about which methodology is best.
As I stated earlier, there is no one-size-fits-all approach, and, often, the choice is driven by the need. Up to this point, West has been consistent in our approach and application of the waterfall methodology. But over the years, I have been involved in many projects that have progressed iteratively that have ended successfully. As we place more emphasis on better speed to market, there may be good reason to tweak our methodology. We don’t have to go all-in on agile, but we can always become more agile, in general.