Waterfall, Agile and the transition

Waterfall and Agile development methodologies have their own strengths, this article covers a bit of Waterfall, more on Agile and the transition from Waterfall to Agile.

In a Waterfall model, the design, implementation and testing of all features of a product happen in a sequence. Changes in specifications, or defects reported by testers, could add significant costs to the project and is usually proportional to the impact of change on design, code and testing.

There are number of Agile models, however, Scrum is the most popular. In Scrum, products are designed, built and tested in iterations or sprints, with the Customer providing feedback on the deliverables after each sprint. So, the impact of change is comparatively less in Agile.

For the benefit of readers new to Scrum, let’s look at the core concepts in this model. The Product Owner prioritizes the Product Backlog which is a list of features that need to be built into the product. These are progressively elaborated as they move up in priority. In the Sprint Planning meeting the scrum team arrives at the Sprint Backlog - a set of features usually in the form of user stories to be developed in the next sprint. Design, coding and testing of the features happen within the sprint, and any change in specification or defect found during a sprint is handled within the sprint. Spill-overs or pending features are included in the next sprint. Sprints are usually between 2 and 4 weeks in length.

The Daily Stand-up meeting or Daily Scrum lasts no more than 15 minutes and the scrum team consisting of approximately 7 members who individually provide an update on what they did since the last meeting, what they plan to do on that day and highlight any issues they are facing. The Sprint Review meeting is to review what is done, what is not yet done and confirm the sprint deliverable. The Sprint Retrospective meeting is to review processes and identify areas for improvement.

It is a fact that Agile methodology has had a huge impact on how projects are run, but Waterfall still makes sense where the development of a product is not too complex or where requirements are fixed and customers are unlikely to suggest too many changes. Following an Agile model like Scrum in such a scenario would be more of a ritual and the daily stand-up and other meetings would be a liability rather than serving the intended purpose.

The Transition within organizations from Waterfall to Agile, requires a lot of focus and attention. Many organizations have understood, evolved and matured in the implementation of Agile principles, however, in some organizations there is still a tendency to manage scrum teams and assign tasks, rather than allow them to be self-organizing and self-regulating. The Scrum Master is expected to remove bottlenecks and facilitate continuous collaboration within the team rather than seeking ideas or alternatives only during meetings. This is the primary reason for co-locating scrum teams.

For Agile to succeed in any organization the team should be empowered and erstwhile managers and leads need to let go of the reigns to see the team evolve and transform in to a high-performance team. The performance of teams and that of individual team members need to be tracked for reward and recognition in a fast-paced environment.

Gaming would help, but that’s a topic for another day !!

Featured Posts
Recent Posts
Search By Tags
No tags yet.
Follow Us
  • Facebook Basic Square
  • Twitter Basic Square
  • Google+ Basic Square