In Scrum: The Unity of Knowing and Doing, I discussed the two basic abilities of human beings: knowing and doing. In terms of Scrum, inspection is about knowing, adaption is about doing, and transparency unites knowing and doing. From a team perspective, knowing is in the form of consensus and doing is in the form of flow. Specifically, the Scrum retrospective is a great platform for inspection and adaption, or knowing and doing. Know yourself and adapt to the world.
Retrospectives don't fall into the "best practice" category — something that you think of as a golden rule and are eager to advocate to the world. Your team is different from any other. Your practice benefits you the most and should be maximized for your own values rather than being sold to the world. Nor is a retrospective a lesson learned — something that is condensed at certain milestones of a project and probably will only be reawakened at certain checkpoints during the next project. Rather than seeking lessons from old projects, a retrospective focuses more on people, on people's learning — immediate inspection and adaption. A retrospective is, again, a unity of knowing and doing: You know yourself, your team, the team process and way of working, and then adjust your behaviors accordingly. Know yourself. It's the beginning of everything, and then you'll be able to know the world.
Knowing and doing are, in fact, one thing. A Chinese proverb puts it this way: Be fond of what is beautiful; dislike what smells foul. To see what is beautiful is to know; to like what is beautiful is to do. The liking immediately accompanies the seeing. It is not after seeing something that you begin to like it. Such is the original nature of the unity of knowledge and action. To know is to resolve to do; to do is to put knowledge into practice. Knowing is the beginning of doing, and doing is the realization of knowing. The unity of knowing and doing is the realization of intuitive knowledge that everyone has.
But to make it easier to describe, I'd like to share my understanding and experience of retrospectives from the knowing perspective and from the doing perspective separately — although by nature they are not separate. I will also talk about retrospective processes, methods, and themes that my team has used and found successful.
From the knowing perspective
The retrospective enhances individual and team identity: who I am. In the retrospective, we spend time showing the team name, team members' names, a team photo, and the sprint name. For the team name, our approach is to make the name link to everyone; for example, the team name contains the first letter of everyone's first name, or is something that's in everyone's immediate frame of reference. In addition to the sprint number, we give each sprint a special name that everyone is interested in and that is suggestive of what's needed. For instance, we recently named our sprints after the names of the Chinese "five phases", or elements: metal, wood, water, fire, and earth. With a clear understanding of "who am I," this helps tackle the question of how I should behave.
The retrospective enhances the sense of achievement and meaning. We spend time showing the sprint goal, both the manual and electronic burn-down chart, and a picture of our whiteboard with a big "DONE" written on it. We sometimes discuss the product vision, its big picture, along with market trends and customers' needs so to have a better understanding of the meaning of our work. Meaning, after all, is one of a human being's basic needs.
The retrospective maintains a sense of sanity for both the individual and the team. The nature of the retrospective is learning, inspecting and adapting. People can feel free to express their observations, thoughts, and feelings and to give feedback regarding the team's way of working. Nothing is scored in the retrospective. We are there only to analyze improvement of the process and growth of individuals and the team. Naturally, people like the sense of controlling themselves rather than being controlled and commanded.
The retrospective enhances the overall sense of satisfaction, motivation, and celebration. Without celebration, life is only a series of Wednesdays. The retrospective serves as the "birthday" of a sprint. The team sometimes brings some snacks to the meeting, and we spend time praising ourselves. Recognition from external world is a bonus, but our self-recognition is more important. People's motivation generally comes from right behavior itself — as long as we recognize that it's right behavior. With understanding of the meaning of our work, and of right behavior, we all feel an internal satisfaction that lasts longer than any praise from the outside.
The retrospective creates a sense of membership and belonging, and it cultivates consensus. We hold a "thanksgiving" period in each retrospective. People write on cards to express their appreciation of each other and of the team. I find that the team is active during this period, and that shows its value. The retrospective also provides a natural means of practicing consensus. It's about learning, with no schedule pressure or conflict of benefits. People stay together to add to or multiply each other's good ideas, generating great ideas.
The retrospective is about learning. In the retrospective we can learn more about each other's perspectives, learn the team process, and learn to better understand the organization. For example, the development team and the support team have different perspectives on the software development environment. Inviting support people to the development team's retrospective can help the two teams better understand each other's needs and points of view.
Knowing about ourselves, and about the team process and environment, we’re then ready for doing.
From the doing perspective
The retrospective promotes action motivated from within. The team inspects itself and the process thoroughly. Then any action taken comes from inside; there is buy-in from all team members.
The retrospective serves as team self-coaching and facilitates growth. In other methods of working, feedback always comes from the manager. After receiving feedback from the leader, most people feel some pressure, and a lack of command and control. In Scrum, feedback comes from team, and it's about process and behavior. Because each team member is equal in terms of power, such feedback doesn't hurt anyone's dignity. It serves as team self-coaching and can help both individual and team develop a sense of capability.
The retrospective creates a sense of flow. Through the retrospective, the team members learn more about themselves as individuals and as a group, and more about the team process and environment. Just as you carefully study the map before you go somewhere new, you'll have an easy journey with the team once you have that sense of flow. The retrospective creates a mental map for what to do next.
The retrospective puts value on immediate action. Regarding actions growing out of the retrospective, we normally divide them into two different groups. The first group contains those things that can be converted into a story or a task and put into the product backlog or sprint backlog. With the backlog, we won't worry about forgetting the action. The second grouping we make visible on the team whiteboard. It can be a working agreement, a reminder, or something else of that type. Once it's visible on the whiteboard, people see it daily and behave accordingly with regularity. Maybe one day we'll hit the point where we have a third group of actions, that don't need to be written down and that people simply begin doing or continue to do because they are right behaviors.
Now I'd like to discuss the processes and methods we use in our retrospectives, along with some examples. The process we use is called the "brainstorming retrospective." It has four steps:
- Brainstorming: As the retrospective happens just after a sprint and demo, we don't need time to review the data. People can and do simply start generating insights. We've found that post-its are great tools at this point, especially for those of us who are Chinese or from elsewhere in the East. Otherwise, if we just ask people to open their mouths, it's not always easy to get input. Some people are more comfortable beginning with post-its to express their ideas.
- Sorting: Next the team sorts the ideas into groups.
- Consolidating: Here we let the idea "owner" explain the idea, and everyone joins the conversation. People get a deeper understanding of the idea as a result of this discussion.
- Refining: At this point, the team can generate solid actions based on the ideas.
The typical methods we use are as follows:
- Most common retrospective format: We post the ideas into three groups. These are the things we believe went well, the things we need to improve, and the ways in which we give thanks for our team members and the team as a whole.
- The retrospective with an ad-hoc theme: For example, once we focused only on quality. People discussed the quality issues we faced and figured out actions to improve that quality — and we didn't discuss other topics.
- Special methods: Sometimes we follow a new format. For instance, in some retrospectives we have to use pictures rather than words to express our ideas. In these retrospectives, people have lots of fun and learn a great deal as well.
These are just different ways our team has handled retrospectives. The key point to remember is that knowing is when the world comes to your mind; doing is when you come to the world. The world is your mind and your mind is the world. It's one thing; it's you. The retrospective provides a great platform for this unity of knowing and doing.