An HBR article inspired me to try out a new way of finding ideas for improvements in Scrum or Kanban retrospectives. In the article is described how a company motivated frontline employees. One of the activities was what I call ongoing experimentation. Not a new idea for sure. Still I thought this might be an interesting approach as an alternative to define improvements per sprint in the retrospective.
Pick an Experiment & Learn
From the HBR article
That is the relevant quote of the article:
Incorporate a spirit of play by encouraging experimentation.
To drive performance with play instead, we wanted to focus on increasing experimentation. Experimentation fosters curiosity, allows for novelty, and sets the pace of learning — all of which are important components of play.
To encourage experimentation, each store maintained an idea board that tracked the primary challenges the store had to solve, as well as ideas for solutions. For example, in one store, a challenge was how to get more walk-in customers. Colleagues could add any ideas they had, whenever they wanted. The challenges themselves were used to focus ideation on what mattered the most.
Employees were asked to choose an idea on the board and experiment with it. Every person was expected to have at least one experiment that they owned at a given time. They learned about hypotheses and about how to reduce an experiment to its minimum effective dose to get a useful result. Each store also had a weekly 45-minute meeting for teams to review their past performance and experiments, without shame or blame, in the spirit of generating new ideas.
There were rules. Experiments had to be doable on the job using only the budget, tools, and time already allocated to each store. Colleagues learned how to focus on creating low-risk experiments (experiments that were “above the waterline” so as to not sink the ship). Once an experiment ended, lessons were systemically captured and shared. There was no pressure for an experiment to work as long as something was learned. If an experiment didn’t work, the team wouldn’t throw it out, but instead would seek to understand why and launch a different experiment.
In retrospectives the team gathers data about the last sprint, generates insights out of the data and then selects improvement activities from a generated list of ideas how to tackle them. So basically this is very similar. My idea now is to do more or less how it described in the article and use the retrospective timeslot in order to do the 45-minute meeting as described above:
Each store also had a weekly 45-minute meeting for teams to review their past performance and experiments, without shame or blame, in the spirit of generating new ideas.
This will update the “progress” and generate new ideas. Then each team member decides about his experiment for the sprint (they are free to continue an experiment or choose a new one. Generally team members can also complete an experiment during the sprint and choose a new one but the retrospective ensures that people keep going).
Looking forward to try this out 🙂
More Retrospective Activities
- Retrospective Activities: Retrospective Poker Cards
- Retrospective Activity: The 12 Principles Ice-breaker
- Retrospective Activity: Lego Perfection Game
- Retrospective Activities: retrospectivewiki.org
- Retrospective Activity: Snakes and Ladders
- Retrospective Activity: GameStorm
- Retrospective Activity: A Lego Retro by Richard Atherton
- Retrospective Activity: Lego Retro by Dominic Krimmer
- Retrospective Activity: Lego Retrospective by JayAllenM
- Retrospective Activities: Luís Gonçalves