Officially author unknown, but I heard it from my mother, more than once.
Reading Better People, Better Process may make it seem like I’m one of those touchy-feely “people over process” types. I confess I have a fondness for people but I’m also a big fan of process. Luckily, people and process don’t exist as either/or. People and process exist as both/and. Here’s a process that can both improve your other processes your people, and the process itself.
Another Multiuse Model
This model is another Multiuse Model. This process tells what to do in a retrospective. Retrospectives occur when we stop, think, and decide what to do next. We call a one person event “introspection”. A software development team may have a facilitator for their retrospective. Retrospective permutations abound. Here are the steps for a successful retrospective.
- Set the stage – get focused
- Gather data – create a picture of what happened
- Generate insights – why? And what could be done differently?
- Decide what to do – what one thing to do, and what is the first step?
- Close – decide how to document and plan for follow-up.
You can learn more about this process by reading Agile Retrospectives. If you are a person who would like to go from good to great, and/or work in/with teams and/or organizations who you’d like to go from good to great, stop reading now and order the book. I’ll wait.
Back already? Wonderful.
So why do a retrospective? Retrospectives involve the Learning Loop. By continuously learning to improve our process, we can learn to improve ourselves. As we improve ourselves we can improve the retrospective process. A conscientious facilitator does a their own retrospective for every meeting they facilitate. George Dinwiddie and I facilitated a two day product owner release planning meeting. After each day we met to discuss what happened that day, what it might mean for the product owners (and us), what we could do to improve, and what changes we would make for the next meeting.
Hints and Suggestions – Three Possibilities
As a bright shiny new ScrumMaster, my retrospectives always included: “And what one thing would we like to work on to improve during the next sprint?” As I prepared for one retrospective, I thought, “Wow. All I ever do is ask what they’re doing wrong. What would happen if I asked about doing more of something they’re doing good?” Based on the what the Gather Data and Generate insight steps reveal I vary the question to focus on:
- Improve (change) something you’re currently doing. Based on their retrospective, one team decided they were making too many assumptions and needed to get the product owner’s input.
- Do more of something you’re doing well. One team noticed the developers were finishing the sprint in good shape while the testers struggled to complete the manual and automated tests. The team decided to have developers work with the testers earlier in the sprint to increase the teams over all velocity.
- Add something you’re not doing. I worked with one team that decided to schedule a meeting with the product owner mid-sprint to update the product owner with new information and verify the team had the spriint goal still in focus.
For the most variety ask the team to create possibilities for all three categories.
Only One Thing
Choose one change to work on. I’ve observed a some details over the years:
- Teams generate many possible change items.
- In a team of equals, some team members are more equal than others. This may be due to experience, longevity, or just plain loudness. I deal with this by giving each team member two votes and then call on team members for their votes making sure not to call on the “more equal” team member first. The item with the most votes gets proposed for the “do this” for the next sprint.
- Any change can create instability. Too many changes at once will push the system to instability and dilute the change impetus pretty much ensuring nothing really gets changed.
Buy In
The team needs to buy into the decision. I recommend using the team’s norm for group decision. I’ve seen the “Fist of Five”, “Roman Thumbs”, head nodding, and probably a couple I’ve forgotten. The point is to get everyone to agree with the decision. If the whole team doesn’t commit to make the change happen, it probably won’t happen.
Follow-up
Pay attention to the change during the sprint. If I don’t see evidence the team is working on the agreed change, I ask a question at the end of the daily meeting about how the team is doing with the change. During the “gather data” portion of the next retrospective I include a question about how the team feels they did on their change idea. Failing to follow up on the topic teaches the team that constant improvement isn’t important. All you get from then on is grand ideas and lip service.
The Unaimed Arrow Never Misses
If you’re the facilitator, structure the retrospective as neutrally as possible. This is easier said than done if you also serve as the team’s ScrumMaster. It’s critical for the team decide what change they’re going to attempt. Structuring the retrospective or guiding the conversation to your predetermined result will result in less commitment if not out right rejection from the team.
What’s Next?
The basic cycle is do, inspect, adapt. Doing starts the cycle. So do something. Then inspect, adapt, and repeat as necessary.
If you don’t have Agile Retrospectives I’d suggest you start by reading the book.
I’ll be leading a session at this year’s AYE Conference involving Introspection. The conference still has 8 openings.