There are numerous approaches to software development that have been used over the years. Traditionally, there has been a division into two competing methodologies, Waterfall vs. Agile.

The Waterfall methodology is largely a sequential method to developing software, where requirements are documented first, followed by the development, testing, and go-live phases of the project. Typically, end-users are the last ones to try out the software, and oftentimes there is a gap between what was delivered and what the user expected to receive. Discovering these gaps late in the process is a risk to project timelines.

The Agile methodology utilizes an iterative approach to software development, delivering smaller features and functions to the end-users on a more frequent basis. This allows for more frequent trials of the software and feedback to the development team, allowing the developers to more quickly address any issues or gaps in functionality.

Scrum is one of several variants of Agile, and is a lightweight process framework used to manage complex product development. The Scrum framework consists of Scrum teams and their associated roles, events, artifacts, and rules. Scrum is simple to understand, but difficult to master.

It can be challenging for teams to start working in an Agile/Scrum approach if they are used to doing their software development projects in a Waterfall manner. Scrum teams are self-organizing and are largely self-managing, which can be a quantum leap for organizations that are used to more tightly managed projects and development teams. There is new terminology used to describe Scrum activities, and it takes time to get used to the language of Scrum and understand the overall process. During Sprint Planning, project work is organized into time-boxed Sprints, which are typically 2-4 weeks in duration. Development teams meet in a 15-minute Daily Scrum to update each other on what they accomplished yesterday, what they plan to work on today, and call out any impediments to progress. Once a Sprint is complete, there is a Sprint Review with the development team presenting their work to the end-users, allowing the opportunity to try out the newly developed software and provide feedback to the team. Furthermore, the development team conducts a Sprint Retrospective at the end of each Sprint to review what worked well, what didn’t, and how they can work better together in future Sprints.

Having recently transitioned from Waterfall to Agile/Scrum, there are some key lessons that I have learned.

  • First, Agile/Scrum is transformational in the way that software development teams work together, and it is important to have organizational buy-in and support from the top.
  • The approach will likely be new to many members of your team, be prepared to fail fast and learn often. Newly-formed Scrums teams need time to learn how best to work together, and early Sprints are typically less productive. Over time, teams become more productive through improvements made coming out of the Sprint Retrospectives.
  • Getting your team members educated in the Scrum framework ahead of time will help greatly in understanding the new terminology, and as a result they will become more comfortable, sooner.
  • It is also important to have a knowledgeable Scrum Master working with your development team. A Scrum Master works directly with each team to help remove roadblocks to progress, and coaches the team on how to approach their work using the Scrum framework. They are formally trained and certified in the Scrum framework, and serve as an invaluable resource to help your team work together successfully in the context of Scrum.

While the initial learning curve may seem steep, over time the Scrum team becomes more empowered and accountable to each other, while at the same time providing working software more frequently to their business users. A definite win-win situation!