Home › SI Blogs › Joe's Blog › Scrum Illuminated

Scrum Illuminated

by Joe Friedman on March 13, 2009

At Soft Illuminations we use the Agile methodology of Scrum in seeing our projects through. Scrum is a simple set of rules that can be applied while managing software projects. By requiring Project teams to adhere to these very simple rules, Scrum creates an environment of collaboration, innovation, and synergy. Be aware that Scrum does not teach new and innovative ways to develop software. It only defines the rules of engagement.

Communication Breakdown; It’s always the same…

Scrum was created to address the difficulties that project managers, developers and stakeholders often encounter during the life cycle of a project. I’ll use Waterfall in reference to what I call a “traditional” approach to project management. In Waterfall, progress is often impeded by a breakdown in communication. Although lengthy requirements documentation seeks to maintain order in such a project, we often realize that these documents do little in the way of fostering productive communication. In the time that passes between planning and implementation in most software projects lies fertile ground for change in which adaptation may be required to alter the scope of a project. All too often, teams find themselves with a product that is either of little value anymore, or requires a completely new set of features. Precious time and valuable resources have been wasted and the morale of your team is severely affected. Sound familiar? Wish there was a way that you could almost guarantee projects on-time, while enhancing the productivity of your team? Usher in Scrum.

Scrum in Sum

Scrum differs from traditional project management styles in many ways. Most obvious, and of great importance, is the focus on empirical data to assess a project’s progress and overall success. During the life-cycle of a project in Scrum, stakeholders, product owners and developers all know, with the same degree of visibility, exactly how the project is progressing. Scrum achieves this not through the use of antiquated documentation, but through regular, collaborative participation fostered through a defined set of rules that guide the practice of Scrum. Another tenet of Scrum, which is the empirical view of progress personified, is the way in which progress is measured. In Scrum, progress is measured by the usable software (aka potentially shippable product) produced during a specified time frame. In Scrum, this time frame is known as the Sprint; a 30-day period in which the Team sets out to create a fully functional, pre-selected segment of the project. These segments of functionality are affectionately referred to as “Sashimi”. It is important to remember that the goal of a Sprint is to produce a potentially shippable product. There are three roles in Scrum. The Product Owner, The Scrum Master, and the Team. Each role has clearly defined do’s and don’ts. For a useful reference of these roles click here.

Let’s talk about it

During a Sprint, the Scrum Master is responsible for enforcing the rules of Scrum. One of the responsibilities is to hold the Daily Scrum. The daily scrum is an intense 15 minute meeting conducted everyday during the sprint in which each team member answers three questions aloud; What have you done since yesterday? What will you do today? and what, if anything, is in your way of getting things done? One by one, team members respond to each other. At the end of the daily Scrum, every team members knows exactly what their peers are doing, and how the project is progressing. The Scrum Master is called upon to remove any impediments in the team’s way, and work is resumed. This open forum synchronizes the team so they can develop efficiently, with a high degree of visibility. It also provides a rhythm to the Sprint since the Daily Scrum is held at the same time and in the same place everyday.

Backlogs, Planning, Sprint, Review, Repeat

The master list of requirements for the project, the Product Backlog, is created and prioritized by the Product owner at the initial Sprint Planning Meeting. The Sprint Planning meeting involves everyone and is where the product owner determines what functionality they would like the sprint to produce. Remember, the focus during a Sprint is to create a potentially shippable product based on the requirements stated by the product owner. Next, the team selects the features they will produce during the sprint. These tasks make up what is known as the Sprint Backlog. The Sprint Backlog is comprised of requirements selected from the Product Backlog. Items in the Product Backlog can be added, removed, or re-prioritized at anytime, but only the Product Owner can do so. In contrast, once a Sprint has begun, only Team members can make changes to the Sprint Backlog. The success of the sprint is determined at the end of the 30 days when the Team demonstrates to the Product Owner, that not only have they completed the tasks pertinent to the Sprint itself, but that each bit of functionality is a potentially shippable product. This meeting is known as the Sprint Review. When the product owner agrees that the software performs to the standards they intially set, the Sprint is complete and the Scrum Master asks the Product Owner if the project can proceed. At the end of the Sprint, but before a new Sprint Planning Meeting begins, the Scrum Master conducts a Sprint Retrospective. This meeting is limited to three hours in which Team members, the Product Owner (optional) and the Scrum Master discuss two questions: What went well during the last sprint? and What can be improved on the next one? This process is repeated until the product owner is satisfied.

Additional Reading

Here are a few of my favorite books on the subject. Must reads if you wish to learn more about Scrum:

Agile & Iterative Development Craig Larman, Pearson Education, 2004

Agile Project Management with Scrum Ken Schwaber, Microsoft Press, 2004

User Stories Applied Mike Cohn, Pearson Education, 2004