The Agile Manifesto
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:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
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:
Agile Frameworks and Methodologies
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).
What Is Scrum?
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:
- 1) Lightweight
- 2) Simple to understand
- 3) Difficult to master.
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 of Scrum
Three pillars uphold every implementation of empirical process control:
- 1. Transparency: Transparency requires teams to be open about all aspects of their work including tasks to be done, the required effort, and ongoing progress.
- 2. Inspection: Inspection means that Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances.
- 3. Adaptation: Adaptation provides Scrum Teams the opportunity to adjust their process on a regular cadence. It’s critical for all scrum teams to understand and commit to the three pillars of Scrum.
Successful use of Scrum depends on people becoming more proficient in living the five Scrum Values. The five Scrum Values are:
- Commitment to the Scrum Values is required by all team members.
- Courage is required to do the right thing and work on tough problems.
- Focus on the work for the Sprint and the goals of the Scrum Team.
- Openness is required from all team members regarding the challenges with performing the team’s work.
- Respect for each individual and differing opinions is essential to the Scrum Team’s success.
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.
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:
- 1) What can the team deliver in the next sprint, and
- 2) How will the team build the product increment.
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:
- 1. What did I do yesterday to help the team complete the work in the Sprint?
- 2. What do I plan to do today to help the team complete the work in the Sprint?
- 3. What blockers or impediments am I facing which prevent me from completing work for the Sprint?
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:
- 1) Percentage of committed work completed
- 2) Number of defects reported, and
- 3) Progress completion on the overall project.
In addition, the scrum master will facilitate a discussion using questions such as:
- 1) What went well during the sprint?
- 2) What didn’t go well?
- 3) What do we want to improve?
- 4) Action items for the next sprint which are tracked.
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 at Scale
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.
Agile at OutSystems
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.