Why Choose Scrum

Elizabeth Raley Profile Photo
Elizabeth Raley

on

August 1, 2011

Why Choose Scrum

My first post in this series discussed the 3 Elements of Scrum and now I'd like to touch on why I chose Scrum. You can also read the series on how CivicActions implemented Scrum here

Scrum is a buzz word among many Drupal shops and web companies. It may be considered the next trend for web development and some approach it with the caution or apprehension that come with trends. Although Scrum is a popular framework for the Agile process, I wouldn't call it a passing trend, in fact, since the 1990's, thousands of companies have adopted it. It's effective and therefore it's here to stay and worth the effort.  Upon initial investigation into the Scrum framework, most people become excited and endeared to the concept, since it addresses so many of the issues that we face daily in website development: changing business needs, changing technology, high value needs and more. 

I originally started using Scrum because the Waterfall method was not working for my organization and we needed a framework to move over to the Agile process. Scrum was appealing because it addressed some very specific problems that we were experiencing:

  • We had constantly changing requirements, as soon as we got something on paper, the stakeholder would make a change.
  • Our projects were so large, that it was months before anything was deployed (add the constantly changing requirements, and we had a very frustrated team and stakeholders).
  • Team members were constantly being "borrowed" and put on other projects.
  • Project Managers were expected to be subject matter experts and spent a lot of time researching requirements.
  • Quality was hard to measure.
  • Launch dates were constantly being missed.

Scrum has very specific rules that mitigated these issues. It gave the organization a framework to follow so that we could be more efficient and effective. Here is how Scrum addressed the issues listed above:

Constantly Changing Requirements

With Scrum, we address the highest priority items first in the Product Backlog and once a Sprint starts, nothing can be added. This helped with getting the Stakeholders to think through what really was a priority and what was just a nice-to-have. It also gave the team the luxury of not being interrupted during a sprint to focus on a new requirement.  The ScrumMaster simply would say no to anything that was trying to be added mid-sprint. It again gave the Stakeholders an opportunity to think about priorities and to be less reactive and more proactive about what was going to be deemed valuable enough to be in a sprint. 

Timelines

Sprints are short, typically 2-4 weeks long, at the end of which the team is delivering working software. This is a big game changer. By separating requirements and features into chunks of work that could be completed in a short amount of time, it gave the Stakeholders immediate results for feedback and it gave the team a big sense of accomplishment. In order to deliver quickly, we often had to figure out how to build something more efficiently, delivering value right out of the gate. This is great for small and large budgets alike.

Team Members

Since sprints cannot be changed once started, that also means that team members cannot leave mid-sprint. There are roles within the Scrum Team that are less time-intensive, and therefore that person can be on multiple projects, but for a role that requires full-time work, that member cannot be poached during a sprint. Again, by having this in place, management was able to think in new terms of how to prioritize projects and the team was more focused. Part of following the Agile process is having self-organized teams. This leads to happier teams and satisfied management. 

Project Managers

The role of a Project Manager changes in the Scrum framework. There are two roles, ScrumMaster and Product Owner, and there is a clear line between the two. A single person cannot do both roles and this greatly increases the success rate of the projects.

The Product Owner focuses on the requirements and is the subject matter expert. The ScrumMaster is the Scrum coach and facilitator. By splitting the roles you have the Product Owner describing requirements, evaluating the quality of the work, and communicating with stakeholders. The ScrumMaster is then able to educate the organization about Scrum, keep the integrity of the framework (by making sure it's followed!) and can focus on the team.

The role of the Product Owner can be filled by an internal person (consider client relations people, customer service reps, etc.) or if working with outside clients, then a representative from the client side usually makes the best Product Owners (and you have the ScrumMaster to train the client on how to be a Product Owner.)

Measuring Quality

There were always issues with measuring quality - it was hard to keep track even during the Q/A process if a requirement worked, since usually the documentation was outdated by that point. Also we would launch a product without having a process for our stakeholders to review it first, so usually it was the users giving us feedback.

With Scrum we documented as we went, and we only documented things that we knew we needed: Q/A Acceptance tests, training materials, etc. When we finished a sprint, we had our Sprint Review Meeting, and the Product Owner walked through the software, approving it or telling us what needed attention. The Scrum Team was responsible for the quality of the delivered product and there was no longer the issue of unclear requirements (the Product Owner is available to answer questions) or too little time (the Scrum Team commits to the amount of work they can complete).

Launch Dates

The challenge with setting a launch date and missing that launch date usually involved the fact that the date was set without input from the team. By adopting Scrum, it was clear to the Product Owner and to the Scrum Team what would be included in each sprint and at the end of each sprint we had a potentially shippable product. The Product Owner could then decide at what point the product could be launched, and we would work on the most valuable business priorities first. 

 

These are only a few of reasons that I chose Scrum. There are many other benefits that I've enjoyed: the self-organized team, the separation between the Scrum team and management, adaptability, transparency, and more! I welcome everyone who is frustrated by their current process to investigate Scrum.  

This is the fourth in a series of posts about Scrum. For the first, please see The Three Elements Of Scrum.

Share it!

Solid reasons to go Scrum. Love to see more posts about agile in non-profit!