Agile and Scrum: A Comprehensive Overview

Scrum is an agile team collaboration framework commonly used in software development and other industries. If you are just getting started, think of Scrum as a way to get work done as a team in small pieces at a time, with continuous experimentation and feedback loops along the way to learn and improve as you go. Scrum helps people and teams deliver value incrementally in a collaborative way. As an agile framework, Scrum provides just enough structure for people and teams to integrate into how they work, while adding the right practices to optimize for their specific needs.

Understanding Scrum

Scrum prescribes for teams to break work into goals to be completed within time-boxed iterations, called sprints. Each sprint is no longer than one month and commonly lasts two weeks. The scrum team assesses progress in time-boxed, stand-up meetings of up to 15 minutes, called daily scrums. At the end of the sprint, the team holds two further meetings: one sprint review to demonstrate the work for stakeholders and solicit feedback, and one internal sprint retrospective. Scrum teams should be cross-functional and self-managing. Unlike sequential approaches, scrum is an iterative and incremental framework for product development. Scrum allows for continuous feedback and flexibility, requiring teams to self-organize by encouraging physical co-location or close online collaboration, and mandating frequent communication among all team members.

The Origins of Scrum

The use of the term scrum in software development came from a 1986 Harvard Business Review paper titled "The New New Product Development Game" by Hirotaka Takeuchi and Ikujiro Nonaka. Based on case studies from manufacturing firms in the automotive, photocopier, and printer industries, the authors outlined a new approach to product development for increased speed and flexibility.

In the early 1990s, Ken Schwaber used what would become scrum at his company, Advanced Development Methods. Jeff Sutherland, John Scumniotales, and Jeff McKenna developed a similar approach at Easel Corporation, referring to the approach with the term scrum. Sutherland and Schwaber later worked together to integrate their ideas into a single framework, formally known as scrum. Schwaber and Sutherland tested scrum and continually improved it, leading to the publication of a research paper in 1995, and the Manifesto for Agile Software Development in 2001. Schwaber also collaborated with Babatunde Ogunnaike at DuPont Research Station and the University of Delaware to develop Scrum. In 2002, Schwaber with others founded the Scrum Alliance and set up the Certified Scrum accreditation series. Schwaber left the Scrum Alliance in late 2009 and subsequently founded Scrum.org, which oversees the parallel Professional Scrum accreditation series. Since 2009, a public document called The Scrum Guide has been published and updated by Schwaber and Sutherland.

The Scrum Framework

The Scrum framework is fairly simple being made up of a Scrum Team consisting of a Product Owner, a Scrum Master and Developers, each of which have specific accountabilities. The Scrum Team takes part in five events and produces three artifacts. Scrum co-creators Ken Schwaber and Jeff Sutherland wrote and maintain The Scrum Guide, which explains Scrum clearly and succinctly. The guide contains the definition of Scrum, describing the Scrum accountabilities, events, artifacts and the guidance that binds them together.

Read also: Learn Forex Trading

People often ask, “Is Scrum an acronym for something?” and the answer is no. It is actually inspired by a scrum in the sport of rugby. In rugby, the team comes together in what they call a scrum to work together to move the ball forward. In this context, Scrum is where the team comes together to move the product forward.

Scrum is an empirical process, where decisions are based on observation, experience and experimentation. Scrum has three pillars: transparency, inspection and adaptation. This supports the concept of working iteratively. Think of Empiricism as working through small experiments, learning from that work and adapting both what you are doing and how you are doing it as needed.

One critical Scrum Team characteristic that binds all of the elements together is Trust. If Trust is not present on a Scrum Team, there will likely be tension and bottlenecks in the way of getting work done. The Scrum Values are also critical for Scrum Teams to adhere to as they help to guide how you work and drive trust. The Scrum Values of Courage, Focus, Commitment, Respect, and Openness, are all important elements that Scrum Team members must consider when working together. The Scrum Values are particularly important in environments where experimentation is core to making progress.

In a nutshell, Scrum requires an environment where:

Increments of valuable work are delivered in short cycles of one month or less, which are called Sprints.
Ongoing feedback occurs during the Sprint, allowing for inspection and adaptation of the process and what will be delivered.
The Scrum Team has a Scrum Master, a Product Owner and Developers, who are accountable for turning the selection of the work into an Increment of value during a Sprint.
The Scrum Team and other members of their organization, business, users or customer-base known as stakeholders, inspect the results of the Sprint and adjust for the next one.

To be effective with Scrum requires something more than just following the mechanics and fundamentals of the framework. Sometimes Scrum Teams fall into the habit of simply going through the motions. Professional Scrum requires mindset changes for ways of working and thinking, and an environment that supports it including trust. It also requires you to embrace the Scrum Values in your work.

Read also: Understanding the Heart

Core Components of Scrum

Scrum consists of:

Accountabilities
Artifacts
Events

These core components, along with a few simple rules, work together to create a cycle of continuous improvement and adaptation, ensuring that the teams and the organizations can respond swiftly to changes and deliver high-value products effectively.

Scrum Accountabilities

Scrum has three accountabilities (previously called "roles") ensuring that every aspect of the shared work is managed effectively.

Developers: Professionals in the scrum team who work together to create any aspect of the product. They create the product increment(s) during the sprint. People with any skill needed to build the product take on the accountability of a developer. Depending on the nature of the product, the skills will be different.
Product owner: The product owner develops and communicates the product goal, owns the product backlog, and ensures the team is always addressing the highest value work. They also balance the needs of stakeholders, customers, and the team. They know and understand the domain, the market for their products, and they are passionate about delivering results that customers and users want and need. The Product Owner is in charge of prioritization as well as feature approval.
Scrum master: The scrum master leads and guides the organization in its scrum adoption and practice. The scrum master helps the team build the product and become the best team they can be by guiding them to use scrum and embody agile principles. They coach the team toward effective use of the events and artifacts. Their day may include helping the team manage impediments, and they are often essential to the growth of the team as a whole as well as individuals. There are also many ways scrum masters serve the organization, including coaching the organization and stakeholders in scrum adoption and empiricism. The Scrum Master is responsible for making sure the team is as productive as possible.

The scrum team is made up of these accountabilities. A team has one scrum master, one product owner, and the developers. The size of a scrum team is usually fewer than 10 people. The team is self-managing and cross-functional. Many responsibilities of a traditional project manager are divided between the accountabilities while other project management responsibilities may become unnecessary.

Scrum Events

There are five events in the scrum framework. These events are valuable opportunities to inspect and adapt the product or the way the team works together (and sometimes both).

Read also: Guide to Female Sexual Wellness

The sprint: The core of scrum, a timeboxed period (less than one month long and frequently 1-2 weeks) during which one or more increments are created. The sprint contains all of the other events. Sprints are short timeboxes during which the team turns ideas into working product. The team works in “Sprints,” typically two-week focused periods.
Sprint planning: The entire scrum team establishes the sprint goal. The developers forecast what work they believe they can accomplish during the sprint to support the goal, and how the chosen work will be completed. Planning should be timeboxed to a maximum of 8 hours for a month-long sprint, with a shorter timebox for shorter sprints. Based on the sprint goal and the forecast, an initial plan is also created. The scrum team may invite other people to sprint planning to provide advice or input on relevant work. At the start of each sprint, a sprint planning meeting is held, during which the product owner presents the top items on the product backlog to the team. The team selects the work they can complete during the coming sprint.
Daily scrum: During daily scrum, the developers inspect the progress toward the sprint goal and adapt plans as necessary. It's a brief daily event led by the developers to inspect and adapt. It is timeboxed to 15 minutes. Daily scrum is not the team's only opportunity to adapt their plans; they often communicate about needed pivots outside of this event. In daily scrum, the team may synchronize their daily work, identify blockers, and discuss collaboration that needs to take place. Daily scrum helps the team understand if their latest plans will get them closer to achieving the sprint goal and they pivot if needed. Each day during the sprint, a brief meeting called the daily scrum is conducted. Daily Stand-Up meetings ensure team alignment. This meeting helps set the context for each day’s work and helps the team stay on track.
Sprint review: The entire scrum team inspects the sprint's outcome with stakeholders and determines future adaptations. Stakeholders are invited to provide feedback on what that scrum team has achieved so far and on the future direction of product development. The product backlog is adapted based on these conversations. Conducted at the end of a sprint, a sprint review is a meeting that has a team share the work they've completed with stakeholders and liaise with them on feedback, expectations, and upcoming plans. At a sprint review completed deliverables are demonstrated to stakeholders.
Sprint retrospective: The conclusion of the sprint, the retrospective is the team's opportunity to inspect their own interactions, collaborations, processes, tools, and any other factors they deem relevant to their ability to continuously improve. At the end of each Sprint, the group holds a review, called a Retrospective, to discuss ways to improve the next one.

Product backlog refinement

Refinement is a continuous activity used to prepare product backlog items for the upcoming sprint plannings. Teams may adjust details such as description, order, and size. It is not a scrum event. Some teams prefer a recurring meeting, usually done once or twice per sprint. Other teams prefer to refine backlog items as needed. While the product owner is ultimately accountable for the state and the content of the product backlog, they can delegate product backlog management to others (but cannot delegate the accountability). The buck stops with the product owner. Backlog refinement is a process by which team members revise and prioritize a backlog for future sprints. It can be done as a separate stage done before the beginning of a new sprint or as a continuous process that team members work on by themselves.

Scrum Artifacts

Scrum artifacts enable transparency, inspection, and adaptation. They provide visibility into the work being completed so that anyone-the team, stakeholders, managers, etc.-can inspect the results and identify areas where an adaptation may benefit the product.

Product backlog: An ordered or ranked list of everything that might be needed to improve the product, along with the product goal. The product goal is the commitment to the product backlog and is part of the product backlog. The product backlog is a prioritized features list containing every desired feature or change to the product. The product backlog is another tool. The product backlog is the list of the functionality that remains to be added to the product. On the left, we see the product backlog, which has been prioritized by the product owner and contains everything desired in the product that’s known at the time. The product backlog is a breakdown of work to be done and contains an ordered list of product requirements (such as features, bug fixes and non-functional requirements) that the team maintains for a product. The order of a product backlog corresponds to the urgency of the task. Common formats for backlog items include user stories and use cases. The product backlog may also contain the product owner's assessment of business value and the team's assessment of the product's effort or complexity, which can be stated in story points using the rounded Fibonacci scale.
Sprint backlog: It consists of the sprint goal plus the set of product backlog items the product owner and developers have forecasted they can complete during the current sprint (they may not finish them all), plus a plan for delivering the increment and achieving the sprint goal. The sprint goal is the commitment for the sprint backlog and does not change during the sprint (while the “scope of work” may actually change). As the plan changes (during the sprint or during daily scrum) those changes are reflected on the sprint backlog. On the first day of a sprint and during the planning meeting, team members create the sprint backlog. The sprint backlog can be thought of as the team's to-do list for the sprint. The sprint backlog is the subset of items from the product backlog intended for developers to address in a particular sprint. Developers fill this backlog with tasks they deem appropriate to fill the sprint, using past performance to assess their capacity for each sprint. The scrum approach has tasks on the sprint backlog not assigned to developers by any particular individual or leader.
Increment: When a product backlog Item is completed (as per the quality attributes defined for the product - captured usually in the Definition of Done) in such a way that it delivers value and is usable, it becomes an "Increment." Each increment is additive because it does not break what has been previously completed and will continue to work indefinitely into the future when new PBIs are completed. At the end of each sprint, the team produces a potentially shippable product increment - i.e. working, high-quality software. An increment is a potentially releasable output of a sprint, which meets the sprint goal and the definition of done.

Scrum Artifact Commitments

In the scrum framework, each artifact is accompanied by a specific commitment that ensures the work focuses on delivering quality and value.

Definition of Done for the increments: The Definition of Done establishes the quality measures for the product that the product backlog items must meet to be considered complete. Once a product backlog item meets the definition of done, it becomes an increment. A team's "definition of done" is a checklist of what needs to be completed for work to be considered "done". The definition of done does not necessarily guarantee that the work is ready to be released, as doing so early on in development may not be feasible, instead it represents how close the team can reasonably get with their existing capabilities.
Sprint goal for the sprint backlog: A specific and singular goal for the sprint that clarifies the sprint's purpose. The sprint goal is the commitment to the sprint backlog. This goal helps everyone focus on the essence of what needs to be done and why. The sprint goal must allow the developers to be flexible about the exact "scope" of work that is done. The sprint goal brings cohesion to the work done during the sprint.
Product goal for the product backlog: A clear understanding of the product's overarching objective is essential for teams to effectively organize the work. The product may have multiple product goals over its lifetime, but only one at a time.

How Scrum Works

Scrum accountabilities, artifacts, and events work together within the sprint. The product owner defines the direction of product development with a product goal using information from stakeholders and users. They identify and define pieces of value that can be delivered to move closer toward the product goal.

The product owner ensures that the product backlog is ordered so that the team knows what is most important. The developers can help the product owner further refine what needs to be done, and the product owner may rely on the developers to make trade-off decisions. This is where refinement becomes an important practice for the scrum team.

During sprint planning, the scrum team collaborates to create the sprint goal. Based on the sprint goal, the developers pull work (usually from the top) of the product backlog and decide how they will complete it. The team has a set time frame, the sprint, to achieve the sprint goal. They meet at the daily scrum to inspect progress towards the sprint goal and plan for the upcoming day. Along the way, the scrum master keeps the team focused on the sprint goal and can help the team improve as a whole.

The scrum team shares its sprint results with stakeholders in sprint review. They may adapt the product backlog as part of that review and in sprint planning. The team has a sprint retrospective to discuss what went well and what didn't go well during the sprint. They may discuss collaborations, tools, communication, and practices that supported or hindered their ability to achieve their sprint goal. They develop action items based on what they discussed in order to improve future sprints.

In sprint planning, the team chooses the product backlog items for the next sprint and the cycle repeats.

Getting Started with Scrum

While the framework defines the bare essentials, here are some considerations to get started:

Define the "product" and the "boundary" of the product
Form new scrum teams
Define product goal and a few product backlog items
Create a definition of done

Transitioning to Scrum

Transitioning to an agile framework such as scrum requires a new mindset and overall cultural adjustments. And, like all change, it doesn't come easy.

The Scrum Values

Commitment: The scrum value of commitment is essential for building an agile culture. Scrum teams work together to support each other in their pursuit of the product goal and sprint goals. This means that scrum teams trust each other to follow through on what they say they are going to do. When team members aren’t sure how work is going, they ask. Scrum teams only agree to take on tasks they believe they can complete, so they are careful not to overcommit.
Courage: The scrum value of courage is critical to a scrum team’s success. Scrum teams must feel safe enough to say no, ask for help, and try new things. Agile teams must be brave enough to question the status quo when it hampers their ability to succeed.
Focus: Every member of the scrum team focuses on the work at hand to support the sprint goal.
Openness: Scrum teams consistently seek out new ideas and opportunities to learn. Scrum teams are also honest when they need help and open with their team and stakeholders about the challenges they face.
Respect: Scrum team members demonstrate respect to one another, to the product owner, to stakeholders, and to the scrum master. Scrum teams know that their strength lies in how well they collaborate and that everyone has a distinct contribution to make toward completing the work of the sprint.

Scrum and Agile: Understanding the Relationship

Agile is primarily a project management philosophy centered on specific values and principles. Scrum is an Agile project management framework that helps teams organize and oversee their work through values, principles, and practices. Scrum encourages teams to learn through experience, self-organize while working on a problem, and reflect on their successes and failures to continuously improve.

When it comes to Scrum vs agile or Scrum in agile contexts, it helps to think of agile as an umbrella. So, Scrum is agile. But just because a team is agile, doesn't necessarily mean they are using Scrum project management techniques or a framework that fits the Scrum definition. While Agile is considered to be more of a mindset, Scrum is one of the frameworks to implement Agile.

How Scrum Aligns with Agile Principles

Scrum operates on core elements that make it exceptionally suited for handling complex, evolving projects. This framework facilitates a balance between structure and adaptability, enabling teams to efficiently tackle changing demands and deliver quality outcomes. Through its elements, scrum provides a lightweight set of enabling constraints for teams to follow as they work through uncertainties and aim for continuous improvement in their work.

Agile originated from a group of 17 tech experts aiming to revolutionize software development. Agile prioritizes individuals, working software, collaboration, and adaptability while acknowledging the value of processes and tools, documentation, contracts, and plans.

Scrum's Foundation in Empiricism and Lean Thinking

Scrum is based on empiricism and lean thinking. Empiricism says that knowledge comes from experience and that decisions are made based on what is observed. Often used in tandem with Kanban boards, lean thinking reduces waste and focuses on essentials. Scrum theory refers to these foundational principles-empiricism, lean thinking, and iterative improvement. When done correctly, this guides the structure, practices, and continuous improvement of Scrum implementations.

Agile Methodologies Beyond Scrum

While Agile and Scrum often get most of the attention, there are other methodologies you should be aware of.

Waterfall: Waterfall project management is another popular strategy that takes a different approach to project management than Agile. Waterfall works well for small projects with clear end goals, while Agile is best for large projects that require more flexibility.
Kanban: Kanban project management is a type of Agile methodology that seeks to improve the project management process through workflow visualization using a tool called a Kanban board. A Kanban board is composed of columns that depict a specific stage in the project management process, with cards or sticky notes representing tasks placed in the appropriate stage.

Adapting Scrum

Scrum is frequently tailored or adapted in different contexts to achieve varying aims. A common approach to adapting scrum is the combination of scrum with other software development methodologies, as scrum does not cover the whole product development lifecycle. Various scrum practitioners have also suggested more detailed techniques for how to apply or adapt scrum to particular problems or organizations.

Scrumban: Scrumban is a software production model based on scrum and kanban.
Scrum of scrums: Scrum of scrums is a technique to operate scrum at scale for multiple teams coordinating on the same product. Scrum-of-scrums daily scrum meetings involve ambassadors selected from each individual team, who may be either a developer or scrum master.
Large-scale scrum: Large-scale scrum is an organizational system for product development that scales scrum with varied rules and guidelines, developed by Bas Vodde and Craig Larman.

Potential Pitfalls of Scrum

In September 2016, Ron Jeffries, a signatory to the Agile Manifesto, described what he called "Dark Scrum", saying that "abuses are almost inevitable until people really learn Scrum’s principles and values".

tags: #agile #and #scrum #overview