Contents
- The Epic
- User Story 11.1: Create Experimentation Training
- User Story 11.2: Train [Team Name] on Experimentation
- User Story 11.3: Coach [Team Name] on Evaluating Experiments
The Epic
As Agile teams, after adoption of the Agile system, we want to experiment with changes one at a time, to balance the need for a systematic approach with the need for team empowerment.
Long before Agile methods were born, scientists had already proven the value of highly empowered individuals and teams, especially self-directed or -managed teams (those without team leaders). The Agile principles around self-organizing teams and trusting individuals call for this empowerment, but in practice many organizations merely lay Agile terms over the same old team management approaches. An easy way to balance true systematic transformation with true empowerment, while building management willingness to let go of control, is controlled change. The concept pre-dates Agile to the earliest days of modern management theory. Frederick Taylor was calling for an experimental, incremental approach to change more than 100 years ago, a method he in fact called “scientific management.” Though “Taylorism” has downsides tied to its era, it also led to practices now the norm but then radical, like work breaks and shorter working days, selective hiring, and standardized processes.[1] And Six Sigma, dating to the 1980s, is explicitly based on the concept of controlled change through experimentation while ensuring other performance standards continue to be met.
Most of the “Customize FuSca™” page of this site applies to any continuous improvement effort. It covers the justification for, and an overview of, careful experimentation to make changes in a way that ensures you get the benefits you want—for the reasons you think you are getting them!
This epic assumes that whatever system you chose provided, or led you to create, performance standards related to Agile (like the Agile Performance Standards in FuSca). For purposes of this backlog, as soon as a team has met those standards three sprints in a row—the minimum needed to establish a trend—teams are free to begin customizing the system. The only requirements are that they:
- Continue to meet the performance standards of the system.
- Make only one customization at a time.
- Identify and coordinate with any of the team’s stakeholders who could be impacted by the change.
Nothing prevents teams from making changes to their practices before this point in the project. After all, constant improvement is the goal of the reflect-and-adjust principle in the Agile Manifesto! Prior to this epic, though, the changes must be made within the system, still doing everything the system prescribes. Once the team proves it has learned the system via the standards, with this epic it can make changes to the system.
User Story 11.1: Create Experimentation Training
As the change leader, I want to create team experimentation training materials, so each team can begin experimenting as soon as it learns the system.
Despite the popularity of Six Sigma and other improvement systems that call for careful experimentation, the vast majority of business teams have not yet been exposed to the process. The change leader/coach cannot assume people know how to experiment. You can find information online, but the FuSca experimentation steps are generic enough to apply to any system and situation. If you’re not using some version of Scrum, just replace the Demonstration and Retrospective sessions in those steps with your equivalent team and program-level meetings. Be sure to include in the training the justification discussed under this epic’s heading. As emphasized throughout this site, people are more likely to support an approach if they understand why it is important.
The training is intended to be short and introductory, fifteen minutes at most. Plan on delivering it at the start of a Retrospective or team/program meeting. You then will coach participants through their first experiment.
Suggested tasks:
- Draft the experimentation training materials and script.
- Schedule a meeting with the sponsor and Change Team, including a link to the draft presentation and requesting written feedback from those who can’t attend.
- At the meeting, deliver the presentation, read out any written comments, and facilitate consensus on changes required to the materials or words said.
- Update and publish the materials.
User Story 11.2: Train [Team Name] on Experimentation
As the change leader, I want to train the [name] team on conducting process experiments and evaluating changes so it will be able to isolate change effects.
Monitor the progress of all teams on achieving your system’s performance standards. When a team hits them three sprints in a row, or two months in a row if not using sprints, create a copy of this story for the team. Arrange to meet with the team at the start of a Retrospective or team meeting to provide the training, and then to coach them through the steps to start the experiment.
Suggested tasks:
- Arrange to deliver the experimentation training at [team name’s] next Retro/meeting.
- Deliver the training and coach [team name] in creating its first experiment.
Note: It may seem redundant to put the team name in each task, but this is helpful when doing the same task for more than one team in the same time period.
User Story 11.3: Coach [Team Name] on Evaluating Experiments
As the change leader, I want to coach the [name] team on evaluating changes, so it will only retain system customizations supported by evidence.
Make a copy of this story for a team after you have provided the team’s training, and arrange to come to the start of the next appropriate meeting to coach members on evaluating the impact of the change. A key is to ask what other events during the time period could have caused the results, regardless of whether the results were negative or positive. Make sure all of the possible factors are considered.
At the meeting, be sure to note whether the team missed any of the performance standards during the experimentation period. In that case they can retain the change for one more period, but should not make another change immediately, and need to roll the change back if the problem remains during the next period.
Suggested tasks:
- Arrange to attend [team name’s] next Retro/meeting.
- Coach [team name] on evaluating the change based on the evidence, ensuring any impact on performance standards is considered.
↑ A Process for Agile Transformation | ← Epic 10 | → Agile for Entrepreneurs
Full references are in the Agile Transformation bibliography.
[1] Williams 2017.