“Today should always be better than yesterday” – mother of Gabby Douglas, the first African American to win individual all-around gold and the first American to win gold in both the individual all-around and team competitions in gymnastics.

A retrospective provides the opportunity for teams to get together and tweak “something” so they can achieve better results than before. Teams use retrospectives for joint learning, making a decision, choosing an action or strengthening a common bond. In Scrum, retrospectives are held at the end of each sprint. Kanban is non-prescriptive about retrospectives, but most kanban teams end up doing retrospectives at a regular interval or as-needed basis.

Some teams resist the retrospectives and lose them entirely. Why does that happen and what is the impact? Well that’s another article for later.

Here we look at the positive, and how agile teams use retrospectives to their advantage. This list is just a small subset of many possibilities on what agile teams can do in a retrospective!

10 valuable lessons for agile retrospectives

  1. Discover team strengths, weaknesses and opportunities: Retrospectives help team members discover what the team is doing well and where it can make improvements.
  2. Raise the bar on team performance: Based on the strengths and weaknesses, agile teams inspect and adapt. They either improves their performance or helps them adjust to new situations and stay on course.
  3. Review data, important trends: Scrum Masters and other team members may collect important data and trends and review with the team during the retrospective. The data can be a generic trend or related to a specific issue that the team would like to resolve or anything else relevant to the team. Looking at the data together usually produces new insights for all team members. It helps finding better ways to resolve the problem.
  4. Prioritize problems that the team must address: Teams usually identify multiple issues and areas of attention during the retrospective and then they narrow down to the most important ones for them to solve.
  5. Solve difficult problems: Sometimes teams may already know of a problem that must be solved. In retrospectives, teams may deploy various problem solving techniques, such as root cause analysis or five whys, or even discussing the results of an A3 process together.
  6. Ask for organizational and leadership support: Depending on the organization, some problems may be beyond the team’s sphere of influence. By prioritizing and discussing possible solutions, the teams can make a case for change that would impact them positively.
  7. Cheer, appreciate, express gratitude: Retrospective can be a forum to celebrate success on completion of a hard initiative, or a specific activity that the team undertook. Teams can utilize retrospectives to bond together and appreciate each others’ strengths and contributions and thank each other for critical help in completing or making progress towards a goal.
  8. Support each other: A healthy team harnesses and extends ideas from its members. Retrospectives are an opportunity to strengthen some of the beliefs and the ideas that team members want to adopt. In that process team members support each other and make progress on what they think is important.
  9. Challenge each other: Not only are the retrospectives meant for supporting ideas, they are also meant for challenging ideas. Challenging ideas helps the team narrow down to one or few ideas that the team wants to try.
  10. Experiment: Teams, Scrum Masters and facilitators can and should experiment with how they conduct retrospectives. They can vary the format, agenda and results they want from the retrospective. They may also just use the retrospective to have a conversation to make changes that are needed.

Lastly, even if you are a Scrum team, please do not wait for a sprint-end retrospective to have a conversation with your team about important issues that you need to solve.


Ugh… increase Velocity? That question again?

In a discussion forum I came across this comment that “Velocity is an awful term and one that is often weaponized like it has been in this thread by asking how to get more. It’s the wrong question because the goal is to become predictable much more so than faster.”

I do not agree that velocity is an awful term, but I do agree that it is often misused (and even weaponized). If you intend to use velocity the right way, and are interested in using it as a tool to understand and improve your work outcomes, this post is dedicated to you.

I would like to note that some of my friends are passionate about #noestimate. Whether you go that route or not, is your choice. The important thing is that is the team performing or worrying about numbers and metrics. If velocity discussions are weighing down the team, that is usually a sign of a different problem.

As you go through this post, keep in mind that increasing velocity may not be your real and only problem, and should definitely not be your main goal.

Addressing the “Real Slim Shady”…

If you want to address the issue genuinely please understand there is never really an end.

If the team is rapidly delivering customer value, communicating well and learning from its experience you may only have limited leverage on what the team itself can do. The team may need support from its ecosystem to take it to the next level. At the same time there will still certainly be things that can team can do to make improvements. and is improving velocity the end goal? Or is it delivering customer value rapidly?
Lets address that.


Step 1. Who is asking?

Before you go any further it is important to understand who wants to increase the velocity. Many a times someone higher up in the food chain may want to know how you will improve the velocity. It may also be a software developer on the team, the whole team, the product owner or the scrum-master (is that you?) who is interested. Or it may be a stakeholder, project sponsor or anyone else as well. Understanding who is concerned about improvement in team’s velocity can help you in several ways in the steps that follow.

Step 2. Why are they asking – their motivation?

Before you jump into a solution, identify why they are asking the team to increase its velocity. What’s in it for them (who want the team to improve)? As you dig deep into the reason for asking, you will likely discover the intent (good, bad, helpful, unhelpful) of the person asking the question. You will become sensitive to their needs and discover their situation. Are they interested in improving communications and flow of value or do they have a personal gain in mind by highlighting the problem? Answering why will help not just with framing the response better but also with taking more informed actions. Whatever the reason is, think about how that can help you drive improvements.

Step 3. Draw insights – Where are the problems, what are the solutions?

Based on your study of your context, would it be fair to say there are potential opportunities for improvement? Where could the team do better?

Imagine a team delivering really really fast but the customers are not responding favorably. Could it be lack of quality or delivery of functionality that customers do not need? In either case, increasing velocity may not be the best solution. We need to think smarter.

Try these questions first:

  1. Is the team delivering new features and improvements frequently?
  2. How are customers reacting to the product deliveries and latest features?
  3. Is the team generally enjoying their work and having fun?

If you spot problems while answering these questions, search deeper. Here are just a few examples of what you could explore.

People questions:
  • Do measures such as velocity drive positive behaviors in your organization? If not what can be done to fix that situation?
  • Are the roles well defined? Is there sufficient empowerment? Are the roles of PO, SM and Development team clearly understood?
  • How is communication between the team members?
  • How strong is the leadership for your team, project and the organization?


Process questions:
  • How do you assess progress towards an important goal? Do you have an objective method?
  • Are team members working on multiple diverging goals and functionalities and have high work in progress?
  • How are releases managed and rolled out – small chunks or big rocks?
  • What is the team doing to continuously learn from its journey?
  • How are (Scrum) meetings running?


Technology questions:
  • How is the team doing on the account of technical debt?
  • Is there sufficient test automation and continuous integration?
  • How is your quality? Do you have a huge bug backlog?

Draw insights together with the entire team to understand all perspectives and see what can be done. Dig into the backlog, measurements that the team thinks are relevant, such as velocity, cycle time, defect trends, automation, build failure rate etc. Looking for problems, and asking why over and over again, should give you new insights on what can be done.

Shortlist a few experiments to try out.

Step 4. Sell, Try, Feedback, Repeat (Go to step 1)!

As you go through this exercise, you may come up with a range of solution(s). Some solutions may require senior management intervention, others may need more involvement from the team.
Now it is time to channel the conversations around the solutions, convince the stakeholders to try them out. Clarify how you will be reviewing the outcome – set a time-frame for that. Try the solution and get more feedback! You may have to repeat this several times, to continually get the results you are hoping for (including but not limited to an improved velocity, as that may not be the real goal you are after).

Good luck!