Agile and Scrum are two of the most frequently used terms today, not only in software development but increasingly in business management. More and more companies rely on business agility, beyond technology, to drive digital transformation, prevent disruptive obsolescence, and maximize market opportunities.
Because they have come into common usage, Agile and Scrum are frequently, but incorrectly, used synonymously.
Agile is an approach to software development and organizational management which enables teams to respond to change by learning and adapting quickly. It relies on breaking work into short durations, close team collaboration, continuous learning, and frequent feedback on completed work.
Agile can be a noun or an adjective. For example, software development teams may define their process as an “Agile Methodology”, or say “we are an agile team”. In this context, Agile means that teams are following the values and principles of the Agile Manifesto in defining the way they organize and execute their work.
The Agile Manifesto provides a set of four values and twelve principles with the following goal:
“We are uncovering better ways of developing software by doing it and helping others do it.”
Since its creation in 2001, the Agile Manifesto’s following has grown and is increasingly used as a management approach and philosophy.
The four Agile Values which guide the way we work are:
There is value in the items on the right, but we value the items on the left more
The twelve Agile Principles provide specific ideas about how teams work when building software:
While the Agile Manifesto provides an excellent set of values and principles to guide the way we work, it does not describe how teams should organize their work or implement their applications. As a result, many frameworks and methodologies have emerged to describe how to actually implement the ideals of the Agile Manifesto. Teams following any of these approaches describe their methodology of as Agile.
The frameworks and methodologies which emerged under the Agile Manifesto addressed specific questions for software development teams. For example, Extreme Programming (XP) provides many of the guiding principles for technical best practices. Eric Reis’ groundbreaking book, The Lean Startup, provides the basis for much of agile product development frequently used today, including the concept of a Minimally Viable Product (MVP).
The Scrum Guide defines Scrum as: a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. In addition, co-creators Jeff Sutherland and Ken Schwaber describe scrum as:
What does Scrum have to do Agile then? For most teams, the fundamental question about “how to become more agile?” starts with the way to organize their teams and execute their daily work. According to the 15th Annual State of Agile Report, 72% of Agile Teams globally use Scrum or a Scrum/XP Hybrid approach.
The Scrum Guide provides the values, team structure, events, and artifacts teams need to organize and execute their work. Teams across all functions in an organization, well beyond software development, are increasingly using Scrum. Jeff Sutherland, who is also one of the co-founders of Scrum, wrote a book, “Scrum: The Art of Doing Twice the Work in Half the Time” to help them benefit from Scrum.
Three pillars uphold every implementation of empirical process control:
Successful use of Scrum depends on people becoming more proficient in living the five Scrum Values. The five Scrum Values are:
All members of scrum teams and their leaders must be dedicated to following the scrum values in their work and holding their teammates to these values.
Scrum Teams consist of only three roles: the product owner, the development team, and the scrum master.
The Product Owner is a single person who is “responsible for maximizing the value of the product resulting from work of the Development Team.” The product owner achieves this by prioritizing the work to be done, ensuing the development team knows what to do, and validates the value of the work done.
The Development Team consists of all team members working on completing the work. Within the context of a Development Team, individuals are not specialized and do not have titles. Development Teams are cross-functional and non-hierarchical.
The Scrum Master is a servant leader to the product owner and development team. They are responsible for removing impediments for team members and “helping everyone understand Scrum theory, practices, rules, and values.” The Scrum Master can manage one or more teams depending on size and complexity. Unlike traditional project management, the Scrum Master is not the manager of the team as they are designed to be self-organizing.
Scrum Teams organize their work around a series of activities or “events”. The core event is called a Sprint, a time-box period, which typically varies from 1-4 weeks in length. The team builds a "Done", useable, and potentially releasable product Increment” during a Sprint.
Source: Scrum.org
Teams decide as a whole team what they will build in a Sprint during an event called Sprint Planning.
Sprint Planning answers two key questions:
In addition to identifying a list of the items the team will complete during a sprint, the team will define a Sprint Goal which describes the overall objective, functional area, or problem the team wants to solve during the Sprint.
Teams meet daily for an event called a Daily Scrum or sometimes it’s called a “stand-up” because all attendees have to stand during the meeting. The purpose of standing is to keep the meeting as short in duration as possible. A daily scrum is time-boxed at 15 minutes; if topics arise which need additional discussion, they are addressed outside the daily scrum.
During the daily scrum, members of the Development Team answer three questions:
Teams should be presenting their list of work items for the sprint during stand-up and updating the status of each item during the meeting. The Scrum Master actively works to resolve any impediments raised by the team during stand-up.
At the end of each sprint the scrum team, product owner, and other stakeholders hold a Sprint Review to inspect and collaborate on the work they’ve done during the sprint. Teams present the functionality built-in the latest product increment and collect information from the scrum team and stakeholders to identify opportunities to improve the product. New items are added to the product backlog for future development.
The last event is a Sprint Retrospective where teams meet to inspect their performance during the prior sprint and identify opportunities to improve.
Formats for Sprint Retrospectives vary, but teams will often review data about the sprint such as:
In addition, the scrum master will facilitate a discussion using questions such as:
At the start of each Sprint Retrospective, the team should review if they completed the action items for improvement and discuss the impact of those changes. You can learn how to run a Sprint Retrospective more effectively in this blog post.
The Scrum Guide defines three Scrum Artifacts that all Scrum Teams create and deploy. The first is the Product Backlog; a prioritized list of everything needed to build the product. The Product Backlog is “the single source of requirements for any changes to be made to the product”. The Product Owner is responsible for keeping the Product Backlog up to date at all times.
The Sprint Backlog is the prioritized list of all items that a team has committed to completing during a specific Sprint. All items in the Sprint Backlog should meet the project Definition of Ready which ensures that items contain all of the information and no dependencies so the Scrum Team can complete them.
A Product Increment is the product version at the end of a sprint that contains all of the items completed in the current sprint and all of the prior sprints for that product. The first principle of the Agile Manifesto is to deliver value through working software, therefore, the Product Increment at the end of a sprint must be usable. Teams agree on a Definition of Done which describes what usable means and the team confirms those conditions before deciding it is usable. The Product Increment must be usable whether the product owner chooses to release the increment to end-users.
Agile frameworks and Scrum were developed originally to help a small group of small teams design and build software products. As people inside and outside of IT realized Agile’s value, its adoption increased resulting in a need for frameworks to manage a large number of Scrum Teams working on a single, large product or in parallel as part of larger organizational units. As a result, several frameworks for scaling Agile across multiple teams have emerged. Some of the most well-known are: SAFe, Nexus, Scrum at Scale, LeSS, and Disciplined Agile Delivery. SAFe, Nexus, Scrum at Scale, LeSS, and Disciplined Agile Delivery.
For more information about Agile at Scale, check out this blog post.
OutSystems has developed its own Agile Methodology which uses a variety of techniques described in this article. OutSystems’ approach has evolved over many years and, while based on Scrum, is not pure Scrum. The OutSystems Methodology is specifically designed to address the specific needs of development teams working with a modern app dev platform in order to maximize the benefits of the technology.
