Discover Scrum and learn how to deliver build better, higher-quality applications.

Agile programming has gained significant momentum recently by changing the way in which organizations develop software. When I was first introduced to agile programming a few years ago by a colleague, I politely listened to his enthusiastic description, but it really did not resonate for me. The more I learned, the more fascinated I became. Now, our organization is in the process of moving to Scrum, which is a well-known agile programming methodology.

This article will introduce you to the basic concepts of Scrum development and help you determine if Scrum is right for you. Scrum terminology is probably rather different from what you currently use. Although some of the terminology maps closely to what you may do today, much does not. While Scrum tends to talk about "products" a lot, Scrum is equally appropriate for both IT organizations and ISVs.

Let's start by talking about how we determine what should be worked on.

Stakeholders and Product Owners

Scrum identifies a stakeholder as anyone who has a business interest in a particular product (or business application). Product owners are responsible for assessing  the needs of all stakeholders and making sure that those needs are met. The product owner role is often filled by people who have been business analysts, senior developers, or programming managers, though the role is rather different from any of those jobs. In product-oriented companies, they often come from the ranks of product managers. While the product owner must work closely with all the stakeholders, priorities are not set by committee; they are set by the product owners. Product owners must be skilled at working with stakeholders from various disciplines.

Product Backlog

The product backlog is the mechanism for ensuring that stakeholders get what they need. Product backlog consists of Product Backlog Items (PBIs) that are constantly "groomed" by the product owner based on changes in priorities that exist in any organization. The higher the item is in the product backlog, the more time should be spent on refining that item. As changes are frequent in most organizations, the product backlog is also subject to frequent change. This aspect of Scrum marks a fundamental difference from waterfall development approaches.

Teams and the Scrum Master

With Scrum, work is performed by teams, which  differ from teams using other traditional development approaches. A Scrum team consists of individuals with skills needed to realize items in the backlog. These individuals will be cross-functional and multidisciplinary. Not describing these individuals by job title is intentional here. Scrum teams are also self-organizing. This is probably one of the more radical, and perhaps least obvious, concepts at first glance. The dynamics of how this type of environment works are beyond the scope of this article, but the one common result reported by organizations with high-functioning teams is dramatic improvements in terms of both quality and volume of delivery. Teams commit to work as a whole, not as individuals.

To keep teams operating smoothly, the Scrum Master is present to eliminate any barriers to the team performing at a high level. The role in some ways is similar to an expeditor role on a manufacturing floor or a traffic cop.

Sprints

A sprint is a time-boxed iteration during which  a team fulfills a specific set of product backlog items. The team decides collectively what they can commit to deliver from the backlog.  The team can only accept backlog items in priority order from the product backlog. Only the product owner can set or change the priority of items in the product backlog. So if the team has chosen seven items from the product backlog, those items are, of course, the top seven items in the backlog. Those seven are now referred to as the sprint backlog.

Sprints have a relatively short time period; two to three weeks is common. The end date (or time-box) never changes once a sprint has started. Sprints typically remain the same length for each iteration. In some cases, the sprint commitment may not be met; if that's the case, the missed sprint backlog items or defects found during the sprint should be placed at the top of the product backlog, to be worked on as the top priority items in the next sprint.

Sprint progress is measured  by a burn down chart (see Figure 1). This is easy-to-understand chart allows all team members  to track the progress of a sprint. If the actual line (in blue) is below the plan line (red), the team is ahead of schedule; if the actual line is above the plan line, the team is not on target. In Scrum, when the team is not target, a team meeting should be called to determine if any changes can be made to stay on track.

Figure 1: The burn down chart tracks the progress of a sprint.

Scrum assumes close communication among the team members. Scrum recommends teams be arranged in close proximity to each other.  The sprints are often facilitated by use of sticky notes on a wall in thecommon team area. Purpose-built software can also perform a similar role.

Key to a sprint's effectiveness are a specific set of meetings: before the sprint starts, during the sprint, and after the sprint ends. Once the sprint starts, there's a daily Scrum or stand-up meeting of no more than 15 minutes that consists of only the following input from each team member: What did I do yesterday? What am I doing today? What is impeding my progress??  It is the Scrum Master's role to eliminate those impediments.  The retrospective meeting at the end of the sprint includes a demo in which the product backlog items must be demonstrated to the satisfaction of the product owner and any interested  stakeholders. Any other interested parties are strongly encouraged to attend these.

Since the team has signed up to build specific product backlog items as defined by the product owner, the product owner should be in the same  location as the team to answer questions that my arise during the sprint.  While the product owner should be actively engaged with the team during the sprint, he or she cannot add to or change the sprint backlog during the sprint.

Potentially Shippable and Done

At the completion of a sprint, the entire product (or application) must be in a potentially shippable state. This is the responsibility of the whole team. While the business may make a decision to not deploy the product or application to the end of the sprint, all product backlog items must be complete for that sprint. Potentially shippable means that each item in the sprint backlog must be done. What done means is the often the subject of much discussion and negotiation among the team, the Scrum Master, and the product owner during the initial adoption of Scrum. In Scrum, there should be no defects at the end of a sprint. If there are, they should be the placed at the top of the backlog product log to be worked on during the next sprint.

What Does Scrum Not Do?

Scrum tends to discourage some existing practices and is silent about others. It is not a project management system. You will not see Gantt charts in Scrum. Scrum would discourage these as it implies fixed long-term commitments, which do not exist. Instead, in Scrum, you have burn down charts for the current sprint, and the product backlog is representation work to be done after the current sprint is complete.

Agile programming and Scrum are platform-neutral. This was not obvious to me at first. It seemed like something for those other, non-IBM i teams, but that certainly is not the case.

Scrum is not something you can decide to implement just as a team member or as a development manager.  As you must have all roles filled to do effective Scrum, you must have commitments from parts of the organization that you would draw stakeholder and product owner roles from. Executive  commitment is also needed due the interdepartmental nature of Scrum.

Scrum is silent on who manages the development. The Scrum Master serves a facilitator/expeditor role and specifically cannot be a staff manager of the teams.

How Do I Learn More?

Scrum has achieved a wide level of acceptance in our industry. As such, it has manifested itself with two main advocacy bodies: the Scrum Alliance and Scrum.org. There are also other resources, such as local user groups, international conferences, pundits, classes, certifications, articles galore, and online communities. Furthermore, you will also find many other Scrum-like approaches  to agile development that include elements of other development methodologies or give more direction in areas where Scrum is silent. 

Software products, whether single-purpose agile-only focused products or Application Lifecycle Management (ALM) products that include Scrum and agile capabilities in their overall set of capabilities, can help with the implementation of scrum projects and eliminate some of the more tedious manual aspects. 

In Summary

Explaining Scrum in one short article is rather challenging. I suspect you may be left with more questions than answers. Certainly, my first exposure left me a bit confused about some of the concepts. Hopefully, there has been enough here to whet your appetite and encourage you explore the topic more.

At the end of the day, Scrum has been used successfully in both small and larger organizations around the world to deliver better, higher-quality applications that meet the needs of their stakeholder community. At the same time, Scrum allows teams to do what they enjoy doing: build better applications.

Marty Acks joined MKS in 1998 and plays a strategic role in defining the company's product direction for Application Lifecycle Management offerings. Mr. Acks is an authority in the area of software configuration management and change management. Prior to MKS, Mr. Acks held a variety of technical and management positions with Professional Computer Resources (PCR) and Pansophic Systems and co-founded Silvon Software.

Also Read

The Power of Writing Code in a Low-Code Solution

TechTip: Let’s Have a Date, Part 2

Going off the Rails