One of the techniques people in the agile community argue for is retrospectives. A retrospective refers to a meeting held at the end of an iteration where teammates reflect on what they experienced and recommend improvements. In Scrum, such improvements are factored into the plan for the next Sprint. As part of the retrospective, the team focuses their discussions center on answering the following questions:
- What went well during the Sprint?
- What could be improved?
- What will we commit to improve in the next Sprint?
In Scrum, the Scrum Master facilitates the conduct of the meeting and acts as the scribe. The meeting itself is time-boxed to last one hour or less. Its aim is to discover what practices did and did not work. In addition, velocity, defect and Backlog metrics are often gathered to be used in the planning the next Sprint as they establish the current pace and provide a to-do list of deferred items, i.e., both user stories and defects.
When used for an agile-at-scale effort, retrospectives are still held at the iteration level. However, as shown in Figure 1, the team and sometimes a team of teams participates. Again, meetings are time-boxed and focused on developing recommendations for improvement. The Product Owner, Scrum Masters, team representations and invited outsiders (management, marketing, customers, etc.) attend. In this scenario, the Product Owner takes charge to drive the generation of improvement stories at different levels of the organization, i.e., team, team of teams and enterprise-wide. Besides recommendations for improvement, the team determines whether the iteration’s goals have been met and collect metrics for use for future planning and process improvement.
Guidelines for all three levels of retrospective appear in the agile literature. Some are agile methodology specific, while others are not. Most tips that are offered focus on either how to conduct the meeting or identification of issues. For example, topics typically discussed at the team of teams meeting include:
- Are products and/or product lines being generated per plans and, if not, why not?
- Are the teams working well together and are their efforts synchronized so products can flow?
- Are teams interfacing and working with stakeholders (users, customers, etc.)? Are they taking their comments seriously? If not, why not?
- Are the “Agile Communities of Practice (a group of individuals who share areas of like interests or concerns)” working and are their products useful?
- What is the current product delivery pace, is it increasing and can it be sustained?
In a program level retrospective, the systemic and organizational issues above the team or a team of team levels are explored and addressed. If remediation requires enterprise-level attention, they are elevated for action. Topics that are typically discussed in such a retrospective include:
- Are there process issues that are causing problems in how teams operate? If so, what do we do to fix them?
- Are there organizational issues that are causing problems in how teams operate? If so, what do we do to fix them?
- Are there programmatic issues that are causing problems in how teams operate? If so, what do we do to fix them?
- Are the Product Managers, Product Owners and/or Architects positively influencing getting the job done?
- Is there anything else we can do to positively impact behaviors and outcomes?
All of these tips and guidelines are great. Besides helping you run a great meeting, they gather information that you can use to improve how you run your software development efforts, programs and/or business. Unfortunately, this is where many such efforts end. There is often no follow-though or follow-up to see whether the recommendations and information gleaned through these meetings is put to use operationally. For example, while teams may take recommendations from one sprint to heart in another, it is up to the individual team member to carry a lesson learned forward when they get assigned to a new team. As another example, process and programmatic issues often do not get fixed in a timely manner because the corporate group tasked to fix the problem does not have a sense of ownership or urgency when comes to the solution.
The bottom line is organizations need to put processes in place to facilitate sharing. Besides being easy to use, developers need to be motivated to use these processes. Else, the databases that are provided will remain unused. All improvement will then remain an individual responsibility.
When I worked with the Air Force years ago, they had a requirement for every program to capture lessons learned when they were completed. The programs that I worked with faithfully carried out this mandate and developed reports that were put into such databases. However, there was no requirement to review them either in anticipation of new starts or to make necessary corrections. As a result, the suggestions and experience that they contained was lost. Let’s see what we can do to fix this at each of the levels of retrospective.
When addressing results at a sprint retrospective, some simple things that you can do include:
- Yes, do all the things recommended by the agile experts.
- Besides time-boxing the meeting to an hour or less, focus on summarizing the results and what the issues were.
- Along with the issues, have participants tell you what went right, what went wrong, and what they would do differently.
- Plan to groom the backlog (see my Technical Note1 on this).
- While collecting metrics is important, focus on fact-finding rather than a performance measurement when you do this.
Make the significant findings known across the teams by:
- Keeping the group size manageable by having the teams elect a few representatives.
- Kicking the meetings off by introducing the teams and key players.
- Along with recognizing contributions by team members, make the meeting fun.
- Plan to use the meeting (also time-boxed to an hour) to celebrate key deliveries, encourage feedback and build your total team.
- Thinking about putting a blog in place to communicate major issues and fixes. Have a volunteer (or maybe an intern) do this monthly.
- Considering posting major issues and fixes on the walls of your team war or meeting rooms. Use banners of different colors to increase visibility and the effect.
- Mulling over posting the issues and fixes in a monthly e-newsletter. A volunteer could do this if so inclined. If not, the task could be done by team leaders on a rotation basis.
- If ambitious, create and tie a knowledge base which links these issues to things developers use. For instance, if lessons effect programming standards, have a pop-up appear when a section is browsed with the pertinent lesson. Also, put them in as examples of practice.
- Hold brown bag discussions to communicate important information and details.
- Remembering that real leaders mingle, listen, and get involved as needed to facilitate getting the job done. Those that get involved only when there are problems are followers. Be a leader.
At the enterprise level, build the corporate infrastructure to make lessons learned work for the firm by:
- Taking advantage of the existing infrastructure whenever possible. Recognize that the teams reworking processes and pursuing other initiatives can be your ally.
- Considering having a major program pay for the effort. Besides having the funds, they need the help. Partner with them to make the effort “win-win.” Provide them support perhaps on a cost-sharing basis to get their buy-in.
- They can pilot the materials and provide testimonials about how well they work.
- Gathering the lesson learned information at the source, i.e., where they happen. It does not matter how you collect the information. What counts is how the findings are filtered, packaged, communicated and made available to those who potentially can use them.
- Story telling is a good mechanism for capturing and communicating results.
- Reports and databases should be avoided because few people actually will look them.
- Use of the lessons in training is a plus especially if there is a mechanism that is put into place to access them via the courseware.
- Consider using Sharepoint2 or an alternative web-based resource to continuously capture and make lessons learned available. Then, highlight the availability of this resource during your all hands meetings
- As with the teams of teams, another way to get people to take advantage of lessons learned is using them as you frame company practices and guidelines. This sounds nice. However, someone has to do the work. My suggestion is to have interns do it as a summer project.
While we provided you with some of the things you can do, there is a lot more guidance in the literature and on the agile web siters3, 4, 5. However, beware, it has been my experience that formal approaches to retrospectives like that advocated by the Project Management Institute6, 7 and others like my Air Force example do not work. They are just too cumbersome and time consuming. Instead, view use from an agile mindset and the following core values and principles consistent with those listed in the Agile Manifesto8.
- Value individuals and interactions over processes and tools.
- Using lessons rather than documenting them.
- Frequent delivery of “useful lessons.”
- Collaboration between “authors and users.”
- Support, trust and motivate the people involved.
- Enable face-to-face interactions.
- Take advantage of lessons as the development proceeds rather than after the fact.
- Regular reflections on how to become effective.
Retrospectives provide you with an ability to make systematic improvements that can help you to improve the way that you conduct your business. Be sure to “act” to take advantage of them when you can. However, realize that stimulating such action requires individuals to buy into any processes or mechanisms you put into place to support their behaviors.
1 D. J. Reifer, Maximizing the Value of Backlog Grooming, available from author, Sep 2018.
3 See: https://www.agilealliance.org.
4 See : https://www.scrumalliance.org.
8 See: http://agilemanifesto.org.