Many traditional waterfall software/product development teams often find themselves working late nights and weekends just to keep pace. Despite meticulous planning, their schedules frequently prove insufficient to address all planned tasks, as project requirements are in constant flux.

For Agile teams, these challenges and impediments seem to be broken down. But how? While the Agile Manifesto outlines only four core values and twelve principles, guiding us to adopt an Agile mindset ("Being Agile"), how do we apply Agile in practice ("Doing Agile")? The answer lies in frameworks built upon Agile. In this article, we'll explore how to implement Agile through one of its most renowned and widely adopted frameworks: Scrum.

I. What is Scrum?

Scrum, the most popular Agile methodology, is a foundational framework designed to approach and develop complex work/products rapidly and efficiently. Experience from implementing projects with Scrum suggests that for maximum effectiveness, teams should consist of a minimum of 3 and a maximum of 9 members. (For larger groups, Scrum of Scrums, which will be discussed in another article, can be used to divide them into smaller Scrum teams). While understanding Scrum is relatively easy, applying it effectively in practice is quite challenging. Scrum comprises a set of practices, roles, events, artifacts, and rules designed to guide the team throughout the project lifecycle.

II. Roles in the Scrum Team

Each Scrum team will have three roles with corresponding responsibilities and clear authority, helping to optimize work. The three roles of a Scrum team include: Development Team, Product Owner and Scrum Master. And when these three components combine, we get the complete Scrum team.

Each Scrum team consists of three distinct roles, each with clear responsibilities and authorities to optimize workflow. The three roles within a Scrum team are the Development Team, the Product Owner, and the Scrum Master. When these three components combine, they form the complete Scrum team.

1. Development Team

These members directly participate in developing specific features of the software/product.

Development Team members are self-organizing, meaning they are empowered to manage their own work. Scrum also encourages each member to be cross-functional, capable of performing more than one specific role as needed to complete the work, such as analyzing, designing, building, and testing the software/product.

2. Product Owner

The Product Owner helps the team understand customer/user needs, enabling them to build the most valuable product/software.

The Product Owner is responsible for maximizing the value of the product/software by managing the Product Backlog, or the prioritized list of work to be done. This includes ensuring backlog items are continuously updated and prioritized, and helping team members understand the features and requirements listed in the Product Backlog and why users need them. This is a crucial task, as it helps the team build the most valuable product/software possible. 

The Product Owner is also responsible for ensuring that customers/users and the team share a common understanding of the project vision, project goals, and the details of the work to be performed, so the team can effectively plan and execute work items. Although the Product Owner holds ultimate responsibility for prioritizing and updating Backlog items, the Scrum Master or Development Team must also support this process by sharing information regarding estimates (time, cost, resources), dependencies, technical work items, and so on.

3. The Scrum Master

The Scrum Master is responsible for helping the team understand and effectively use Scrum.

Scrum may seem simple, but understanding it correctly isn't always easy. That's why a Scrum Master is essential within a team. This individual oversees all activities from planning and task assignment to organizing meetings, helping the Product Owner, Development Team, and the rest of the company implement Scrum accurately and effectively.

The Scrum Master is a leader (hence the term "master" in the title). However, the Scrum Master embodies a very specific type of leadership: the Scrum Master is a servant leader. This means the person in this role dedicates their time to assisting (or "serving") the Product Owner, Development Team, and everyone across the organization, helping remove any impediments to execution and facilitating their work, including:

• Helping the Product Owner find effective ways to manage the Backlog.
• Communicating the project vision, project goals, and Backlog item details to the Development Team, helping the Development Team understand specific Scrum activities and perform them if necessary.
• Helping the rest of the organization understand Scrum and collaborate effectively with the team.
• Facilitating the adoption of Scrum not just within a single project but across the broader organization.

III. Sprints in Scrum

As we know, Agile divides projects into iterative cycles called Iterations. Similarly, Scrum breaks down projects into multiple Sprints. Each Sprint corresponds to a repetitive segment or phase in the software/product development process, also known as a timeboxed (time-limited) period. Typically, each Sprint lasts one, two, or four weeks, depending on the team/company. Within each Sprint, changes that affect the Sprint goal are not permitted. The project scope can be clarified or re-negotiated as new information emerges, but if a change requires the Development Team to perform new work, it will not be executed within that current Sprint.

A Sprint can be terminated before the timeboxed period ends if the Sprint goal becomes obsolete due to changes in business direction or if technological conditions are no longer relevant. However, only the Product Owner has the right to end a Sprint early. When that happens, any unfinished Backlog Items will be re-evaluated and returned to the Product backlog.

The sequence of activities within each Sprint includes Sprint Planning meetings (performed at the beginning of each Sprint), Daily Scrums (performed daily during a Sprint), Sprint Review meetings (at the end of the Sprint)), and Sprint Retrospective (after the Sprint Review).

IV. Scrum Events

Scrum events include: Product Backlog Refinement, Sprint Planning Meetings, Daily Scrum, Sprint Review, and Sprint Retrospective.

1. Product Backlog Refinement:

This is a meeting where everyone comes together to discuss and update the items in the Product Backlog. It involves updating details and prioritizing each backlog item, helping the Product Backlog become "refined". This, in turn, facilitates smoother execution of tasks, maximizing focus on creating the best possible product/software.

2. Sprint Planning Meetings:

Conducted at the beginning of each Sprint, in Sprint Planning Meetings, everyone decides which features to implement, assigns tasks, breaks down those features into smaller tasks, and plans how the work will be executed during this Sprint.

The Product Owner updates Backlog items, and the team (Development Team + Scrum Master) discusses to ensure everyone shares a common understanding of the work item.

Based on estimates, anticipated performance, and past performance, the Development Team forecasts the amount of work they can complete within the Sprint and then defines the Sprint goal. Following this, the Development Team determines how to build the functionalities for the product/software and how they will execute to achieve the Sprint goal.

Sprint Planning Meetings are typically timeboxed for 2-4 hours. The entire team focuses on breaking down and planning work for at least the first week of the Sprint.

3. Daily Scrum:

This is a timeboxed meeting, typically lasting about 15 minutes, held daily to help the team move towards the Sprint goal. The Scrum Master ensures the meeting occurs daily and tracks any impediments identified during the meeting. The Daily Scrum is primarily for Development Team members to synchronize their work and report any issues or obstacles they are encountering. The scope of this meeting is strictly limited, with each team member briefly answering three questions about what they are doing to meet the Sprint goal:

What have you done since the last Daily Scrum meeting?

• What do you plan to do today?
• Are there any impediments or difficulties in your progress?

4. Sprint Review:

The Sprint Review meeting is held at the end of the Sprint with the participation of the Development Team, Product Owner, and Scrum Master (and other stakeholders). In this meeting, the team presents the features they have built during the Sprint to the Product Owner. The Product Owner inspects the work to see if the product/software functions well and is acceptable. The team and Product Owner discuss this increment and the remaining items in the Product Backlog, jointly making any necessary changes to the Backlog.

This event takes place after the Sprint Review but before the next Sprint Planning meeting. The discussion can cover anything that happened during the past Sprint, including issues related to people, processes, and the product. Team members explore what went well, what could be improved, identify opportunities for enhancement, and decide which changes will be implemented in the next Sprint.

V. Scrum Artifacts

During software/product development, the team needs to know about the product/software features they are working on, what they will build in the current Sprint, and how they will build it. The Scrum team uses three tools to manage all this information: Product Increment, Product Backlog, and Sprint Backlog.

1. Product Increment

The incremental feature of the product/software

In each Sprint, members of the Development team will build solutions for the incremental feature portion of the product - the Product Increment. As mentioned above, during the Sprint Review, the team will present and demonstrate the latest Product Increment to receive feedback from the Product Owner and see if this increment truly works well and is accepted. To maximize the chances of a Product Increment being accepted, the team and Product Owner need to agree on the items to be completed, or what constitutes a complete Increment (DOD - Definition of Done) before the team begins working.

2. Product Backlog

This is a prioritized list of project work/requirements to be completed to build the product/software.

Product Backlog items (also called backlog items) can include features, functionalities, requirements, enhancements, and bug fixes for the product/software. This list is flexible; it evolves as the product develops and requires continuous updates.

Product Backlog items are prioritized by the Product Owner and ordered from highest to lowest priority. The team executes work based on this priority order. These work items are progressively refined as the team works, so the highest priority items are the most detailed, and the team will estimate (time, cost, resources) them more accurately. The lowest priority items might not be implemented at all.

The Backlog is continuously refined throughout the project. The process of updating details for each sub-item within the Backlog, as well as estimates (regarding time, cost, resources, etc.), is called "Backlog Refinement." This activity is performed jointly by the Development Team and the Product Owner.

3. Sprint Backlog

This is the collection of Product Backlog items selected as the goal for a specific Sprint.

Along with the Sprint Backlog, the team develops a plan for how they will achieve the Sprint goal. This represents the team's commitment to the functions and features they will deliver within the Sprint. The Sprint Backlog provides a clear view of the work currently underway and can only be updated by the Development Team.

As the team works through the Sprint Backlog throughout the Sprint, members will be assigned to complete tasks in the Sprint Backlog, and this information will be shared with the entire team during the Daily Scrum.

 VI. Scrum Core Values for Effective Work

The five core values of Scrum help the team operate most effectively, including: Openness, Respect, Courage, Focus and Commitment.

1. Openness

None of us wants to make mistakes, especially at work. During the work process, if you encounter a problem, obstacle, or barrier, you can share it with your team so that everyone can discuss, share, and provide feedback to you, thereby helping you complete your work most effectively. That's why everyone on the team needs to share this value.

2. Respect

Trust and respect always go hand in hand. Everyone in the team needs to listen to each other's opinions and offer constructive feedback to better understand each other's ideas. If your teammates disagree with your opinion, they will express their views and analyze what you are doing, but they will still respect your decision.

3. Courage

Scrum teams need courage to take on challenges. But each individual in the group also needs to have enough courage to express their opinion. For example: What would you do if your boss asked your team to complete an impossible goal? What happens if the boss asks the team to meet a two-week deadline for a project, but it actually takes at least two months to complete? At this point, Scrum teams need to be brave enough to stand up and present this infeasibility to their boss.

4. Focus

Every member of the team must focus on the Sprint goal, and everything they do during the Sprint will help them move towards that goal. In a Scrum Sprint, each member of the Scrum team only focuses on the items in the Sprint Backlog and the tasks they were assigned during the Sprint Planning meeting. Each person works on one item in the Sprint Backlog at a time, focusing on only one task in the plan and only moving to the next task when the current one is complete.

5. Commitment

Everyone on the team must commit to delivering the most valuable product/software they can. When the team commits to the project, it means that the tasks they have planned to meet the Sprint goal are the most important tasks they must complete. Each team member needs to recognize that individual success is linked to the success of the project. Not only that, but each person in the group also has to commit to each goal the team must achieve. This is called collective commitment.

And for Scrum to be effective, the company also needs to be fully committed to the project, respect the team's collective commitment to the Sprint goal, and adhere to the rules of Scrum.
So how does a company demonstrate that commitment?

By empowering the team to decide which features will be developed in each Sprint and trusting them to deliver the most valuable product/software possible. The company does this by giving the Product Owner the authority to work full-time with their team.

VII. Definition of "Done" - DOD

In previous sections, we mentioned the concept of "Definition of Done" (DoD). So, how exactly is "Done" defined? Team members work on a Backlog item or an assigned task until it's "Done." But precisely when is it considered "Done"?

• Some members say "Done" after coding a certain product/software feature.

• Other members believe that "Done" is only achieved after testing is complete.
• But some members only consider it "Done" when the customer "gives the nod".

That's why Scrum teams have a "Definition of Done" for every item or feature they add to the Backlog. Before an item can go into the Sprint Backlog, everyone on the team needs to understand and agree on the "Definition of Done"  to not only execute but also truly "Done" the work.

VIII. Scrum Teams need to adapt to changes throughout the Sprints.

Project teams must make decisions every day:

• Which features will we build in this Sprint?
• In what order will we build the features?
• How will users interact with this feature?
• Which technical methods will we implement?

Teams following the Waterfall model have an answer: "All plans were made at the beginning of the project; just follow them." The problem is that at the time the plan is being built, most of those questions don't have answers.

Scrum teams also acknowledge that not every project question can be answered at the start of a project, or even at the beginning of a Sprint. Instead, Scrum teams execute the plan and adjust based on team members' reports during meetings.

Scrum teams achieve this by utilizing Scrum's "three pillars": transparency, inspection, and adaptation.

1. Transparency:

This means everyone on the team understands what their teammates are doing. This involves each individual sharing information (about progress, how work is being done, etc.) on their ongoing tasks with relevant stakeholders.

2. Inspection:

This means regularly checking what the team is building and how they are building it through discussions in the Daily Scrum and other Scrum meetings. It involves monitoring project progress against set objectives and looking for deviations or differences that could potentially affect the Sprint goals.

3. Adaptation:

This means the team continuously adjusts their process to minimize unwanted problems based on what they learn from Daily Scrum meetings and other Scrum meetings (such as adding or removing backlog items from the Sprint Backlog when issues arise).

IX. Summary

In summary, the rules of Scrum are straightforward, but applying them effectively in practice is very challenging. For Scrum to be most effective, the team needs to truly understand the values of Scrum specifically, and the values and principles of the Agile Manifesto in general.

Atoha Institute