Why you are failing with Waterfall – Consider Agile and Scrum
Rick McGuire, Senior Application Development Manager, shares what many development teams are discovering in their effort to build better software: Agile has many advantages over traditional waterfall methodologies.
Surprisingly there are still a lot of development teams clinging to the old Waterfall methodology for software development. This methodology typically requires a team of business analysts to painfully extract functional and non-functional requirements from the stakeholders to generate an imponderable amount of documentation which is then handed off to an architect.
The architect uses this information to produce the design documents based on his or her interpretation of the requirements. Once complete, all the documentation is handed off to the developer to decipher so they can write the actual code months later.
Typically the end result of this approach is a software product that doesn’t meet the business need, may have performance issues, and most likely suffers from a few bugs and/or unintended behaviors. To make matters worse, your project may end up over budget and past the agreed timeline with no real value delivered to the organization. Sound familiar?
The disadvantages of the Waterfall approach include:
- Lack of visibility – You don’t have working code until after the development process, you have no idea what the quality of the software is until all the testing is completed. This is a rather long time to have to cross your fingers and hope for success.
- Risk – Using this sequential process forces the need to anticipate risk until after testing is complete.
- Lack of adaptability – The further you get into the project the less flexible you can be without significant impact to the schedule.
- Business Value – There is no real business value gained until the software is completed at the end of the extensive Waterfall cycle.
So what makes Agile different? Is Agile the silver bullet that solves all these issues? Well maybe not, but there are clear advantages. The Agile movement can be summarized by the Agile Manifesto created in February of 2001. Several leaders in the industry including Martin Fowler, Ken Schwaber, and Mike Beedle came together to identify some common ground and agreed on these four values:
- Individuals and Interactions over process and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The Agile approach allows you to take incremental steps toward building working software. It encourages the business users to weigh in and experience working software after each iteration. This allows for immediate feedback and for the team to consider what capabilities/features will be in the next increment/iteration/sprint, or whether there is a need for more substantial changes. What are the advantages of Agile?
- Adaptability – Since you are building increments over 2-4 weeks you can make big changes without a lot of impact; you can fail faster.
- Improved team collaboration during the entire process.
- Continuous working software that may provide immediate business value.
- Project visibility throughout the entire process.
- Improved and meaningful documentation.
- Risk is always understood and addressed in real-time.
One of the more popular Agile frameworks is Scrum, created by Ken Schwaber. In his own words, “Scrum is a framework for developing complex products and systems. It is grounded in empirical process control theory. Scrum employs an iterative, incremental approach to optimize predictability and control risk.”
Scrum is so simple, yet very difficult to master. There are only three roles in Scrum: the product owner, ScrumMaster, and the development team. There are five events (i.e. ceremonies, meetings) that occur in Scrum. They are sprint planning, sprint, daily scrum, sprint review, and the sprint retrospective. Finally we need to talk about the artifacts that are generated which include the product backlog, sprint backlog, and the increment (working software).
The ScrumMaster removes impediments and is the servant leader for the Scrum team. The SrumMaster is the expert on Scrum. Their job is to ensure everyone understands the process and that all the Scrum events are performed. The Product owner owns the product backlog and works with the business and the ScrumMaster to prioritize the backlog. The development team is responsible for creating the sprint backlog and owns delivering a “done” increment at the end of the 2- 4 week sprint
There is a planned time-box or sprint that lasts from 2-4 weeks where the development team works on the items in the sprint backlog. Every day there is a daily Scrum event to discuss the progress and make adjustments. At the end of the sprint there should be a product increment (working demonstrable software). The working software is then presented at the sprint review with the business owners. The Scrum team follows up with a sprint retrospective meeting to talk about what went well and what didn’t and how they might improve the process for the next sprint.
The longer the development cycle is, the larger the risk that the software that comes out at the end is far from what is needed. In a world full of changing requirements, changing teams and changing technologies, Scrum provides you an opportunity to course-correct throughout the entire development process, rather than only at the end when it may be too late.
This blog post just scratches the surface, but if you are still using Waterfall you may want to consider Scrum for your next project. I would recommend reading “Agile Software Development with Scrum” by Ken Schawaber and Mile Beedle. There is great information at Scrum.org along with the Scrum Guide.
Microsoft Premier Developer has many offerings in this space such as ALM workshops and Agile coaching. Many of the Premier Developer Application Development Managers are ScrumMasters and are able to share their experience and knowledge with your development teams.
Light
Dark
0 comments