Using Scrum to Adopt Agile

Using Scrum to Adopt Agile - AIM Consulting -

Since the publishing of the Agile Manifesto in the early 2000s, organizations have experienced tremendous benefits from adopting agile, including transparency, predictable delivery, and better quality. Agile has generated such a positive impression that it has increasingly been used for non-development-related projects, for everything from managing marketing projects to transforming an entire practice.

For organizations excited to make the transition to agile, the promise is sweet but the reality can be bitter. Organizations unfamiliar with agile processes can face significant challenges, and when projects stall or fail due to lack of understanding or poor implementation, agile gets the blame. To make the transition to agile more smoothly, some organizations have found success with a tactic I like to call “using Scrum to adopt agile.” This concept can be applied with a variety of methodologies (Lean, Kanban, etc.), but as Scrum is well-known and highly regarded, I will use it to illustrate how this is done.

What it means to use agile to adopt agile

People learn best by doing, where new behaviors and practices stick by virtue of having learned them in small pieces and walked through them once. Using Scrum to adopt agile essentially means that the team treats its agile adoption as a “project” using the Scrum framework, so that the team has to apply Scrum roles, ceremonies, and artifacts to accomplish its adoption goals.

Using an incremental approach, the team focuses on 1–3 aspects of the framework at a time. This prevents the team from getting overwhelmed and frustrated when trying to absorb and change too much at once. Additionally, when the team can focus on a couple things at a time, the new behaviors and practices have a better chance of becoming habit and part of the culture.

Ideally, the team would run its agile adoption project concurrently with a development project.

Here’s how it works:

1. Form the Scrum Team

Decide who will be the product owner, scrum master, and “adoption” team. Refer to The Scrum Guide for definitions of these roles. The adoption team will likely be the individuals working to get processes and tools in place that the development team will use to manage the product backlog and tasks, facilitate communication, and perform development/test/release activities with greater agility. This is a great opportunity to appoint different roles to team members that they normally wouldn’t play. Stakeholders should be invited to participate in all project ceremonies as well.

2. Create a product backlog

When using agile to adopt agile, create a prioritized list of agile practices, procedures, tools, and other tactics the team wants to adopt. Keeping in mind that a product backlog is never really done, improvement opportunities can be added as the team conducts regular retrospectives. The product backlog might include items such as bug triage guidelines and procedures, user story pointing guidelines and procedures, automated deployments, defining the team’s DoD (Definition of Done), designing the team’s workspace/environment to be more collaborative and conducive to self-forming teams, and identifying and implementing task management tools such as Jira and TFS. Begin by creating a list, prioritize it based on importance, and prepare to tackle 2–3 items at a time.

3. Determine sprint duration

Decide how long your agile adoption sprints will be. I suggest longer sprints. Most likely, the items in your agile adoption product backlog won’t follow a typical dev/test/deploy model; therefore, the task work can be vastly different from one item to the next. Keep in mind too that it takes almost four weeks to make something a habit, so plan sprint durations suitable for the team to adopt new principles and practices.

4. Start the first sprint

Once the team has assigned roles, identified its product backlog, and agreed upon a sprint schedule, it’s time to start the first sprint. During the sprint planning meeting, the team chooses an item from the product backlog to be completed in the sprint, how the work will proceed, and the overall goals. I suggest following the basic guidelines from The Scrum Guide for facilitating a sprint planning meeting. This video and blog post offer some good suggestions as well.

Here’s an example of how this might work:

• The sprint goal: Provide complete transparency into what the team is working on and the estimated time to complete
• What the team will work on in the sprint: Implement a task management tool
• How it will be completed:
  • Select 2–3 industry-standard tools and perform a cost/benefit analysis
  • Prepare a proposal to management for purchasing the selected tool
  • Purchase licenses
  • Set-up roles and permissions
  • Customize templates and other settings
  • Train the end users
• The user story might be: “As a team member I want a web-based tool that I can use to create and manage my task work for implementing a feature in [our cool product] so I can stay focused and provide visibility to the rest of the team as to what I’m working on.”
• The acceptance criteria might be: “Tool is web-based, features are customized based on team needs, and end-users are trained.”

During sprint planning the team may decide this story is too big and needs to be broken down. For example, the customization of the tool might be its own user story. Once broken down, the team assigns story points to each user story and then identifies, estimates, and assigns the tasks needed to fulfill it.

By the end of the planning meeting, the team should have a clear and common understanding of the task management tool it plans to implement and how it will be delivered.

5. Daily Scrum/Standup

Have a daily meeting to discuss progress, next steps, and any actual or potential impediments toward the sprint goal(s). Keeping with the example above, the team members may share that the proposal for the tool was approved and the licenses have been purchased, and the next measure is to perform the set-up and configuration steps. The impediment may be determining the configuration settings. To get unblocked, team members could decide to have a meeting to discuss this and make decisions. A meeting to deep-dive into configuration settings would be performed separately from the daily standup meeting.

6. Sprint Review

At the conclusion of the sprint, the team and stakeholders gather to review the progress made toward agile adoption. In this example, the team might demo its new task management tool and show how it supports its agile adoption journey. The team should present and demo the tool and other completed work by stepping through the acceptance criteria of each user story to get agreement and acceptance that the user story is complete.

The sprint review is also a good opportunity to discuss next steps. Now that the team has a tool to track its work, perhaps the goal for the next sprint would relate to adoption and usage, providing the team with the basis for its next sprint planning meeting.

7. Sprint Retrospective

The final ceremony in each cycle is for the team to inspect itself to determine what went well in the sprint and identify opportunities for improvement. Perhaps the team felt the user stories were broken down to an appropriate level. Additionally, maybe it decided to analyze work items better to reduce the amount of unknowns during the sprint. Items identified as areas for improvement should be incorporated into the next sprint.

8. Rinse and Repeat

Sprints are cycles that repeat. Instead of creating a product backlog, the product owner and team “groom” it by adding/changing/removing items. The team picks the next item prioritized at the top of the product backlog and holds a new sprint planning meeting to determine how to complete it. Because the notion of “inspecting and adapting” never ends, the agile adoption project might run for an undetermined amount of time. New agile principles, practices, processes, and tools can continually be added to the product backlog, strengthening the team’s agile principles gradually over time.

Learning is a Process

Keep in mind that no team will be perfect at this at the beginning and to apply patience and continual nurturing of the project as it proceeds. Ultimately, each team defines their own success factors, such as faster time to market, quality improvements, and overall team health (turnover, engagement levels, job satisfaction, and so on).

Agile principles and practices can really be used to accomplish anything in your organization. Learning by practice provides tactile involvement and structure by breaking things down and allowing you to bite off unfamiliar processes piece by piece. As long as your team has a vision and is willing to take an incremental approach, using agile to adopt agile can help your teams boost their agile capabilities from the inside out.