10 valuable lessons for agile retrospectives

"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!

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 to find 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.

Related:

• 
  
  Goals of a Retrospective


• Agile Retrospective Resource Wiki


• Sprint retrospectives


• Retrospectives: Prime directive 


• There's hope (usually!)


• Agile Retrospectives: Making Good Teams Great, by Esther Derby, Diana Larsen

Rough notes: Misunderstood agile practices

Let us assume management and team have some experience with agile but they only understand parts of it (such as iterative delivery, sprint ceremonies etc.). Have you faced such situations? Which practice(s) and concept(s) did you strive to adopt but were challenged? what tools did you use for influencing the outcomes?
 


Here are some highlights from a LinkedIn discussion I started about misunderstood agile practices.

* In many "traditional" companies agile is seen as a new set of controls to get work done. Old roles are re-labeled.

* Many companies think that they can purchase agile as product also if they have few certified SM/PO on pay roll, company is agile.

* Misconception: Equating testing with quality improvement. Quality needs to be designed in from the get go.

* Try this: Making metrics visible. Nobody can argue with truths, and the truth is a strong motivator of change in group dynamics.

* Conducting honest retrospectives over many sprints is often neglected.

* The biggest mistake that people make is thinking that Agile is a process, and if you do the process, you'll be successful.

* Agile practices could be perfectly implemented but with inappropriate mindset and intention, then practices perfectly implemented in physical and visible shapes will all always be misunderstood.

* Misunderstanding Being Agile vs. Doing Agile: Most people don’t understand the difference between Being and Doing. Agile isn’t something you do. It’s something you are.

* Misunderstanding the proper amount of documentation needed. Reading "Working software over Documentation and Processes" and forgetting the final line of the manifesto, "Although we value the things on the right, we value the things on the left more".

* The problem is with the mindset. A mindset change is more difficult of a change and involves coaching/training/teaching and importantly discussions around what Agile is to the team/department/company.

* Many chickens do not understand the "doing" vs "being" agile.

* Misunderstanding: Many organizations associate agile with tools...like "I am using Jira / Rally / TFS /(any other tool you can think of) and still not able to get the benefits of agile. Looks like agile doesn't work for us"!!!!

* Transparency does not mean micromanagement.

* Misunderstanding: Dysfunctional Waterfall is the same as Successful Waterfall.

* Misunderstanding: If I cut my big traditional programme of x years without any reliable progress indicator into small iterations, that I can reasonable expect precise forecasts / commitments and then still get all the benefits of agile.

* Misunderstanding: Agile methodology is not suitable for products which take multiple years to build.

* Misconception: "Agile is for those who are not disciplined enough for processes", i.e. "You can improve Agile by introducing more rigid processes."

* Try this: Look at your dev / test / staging infrastructure and automation around that. And your engineering skills and practices.

* Misunderstanding: Scrum ceremonies often misunderstood and poorly done, but yes Daily Standup especially. As it returns every day.

* Misunderstanding: "We create user stories ñ try to complete them in two weeks" so we follow agile ...

* Misunderstandings: Originally, there are things like "I can't break down my work that small." Or "our testers are used to being at the end, we can't include them in our current sprints." And the misconceptions just move on down the line as you transform the teams.

* Quote: Wisdom begins when we discover the difference between "That makes no sense" and "I don't understand". --Mary Doria Russell

* My favorite takeaway: It is far better to move ahead with a wealth of misconceptions and the personal and organizational intent to continuously improve than to try and identify and correct the misconceptions first.

Agile managers: Are you listening?

I keep running into situations where managers, with all their good intentions, either misinterpret, ignore, or fail to understand certain agile concepts due to various reasons. Shortcuts provide them immediate relief the long term pain typically aggravates. This impacts not just the outcomes, but also the team and the managers in ways that are usually not positive.

Are you a manager? This is for you...

1. Start right, because if you don't you will put the entire project or initiative in jeopardy. Managing expectations is the key. If your voice is not being heard by higher-ups, do not be a weakling and get help. It could be someone with more influence or with more experience or perhaps a mentor or a coach. Ask yourself - who can help you make a convincing argument and even argue on your behalf? Engaging higher ups is not sufficient. Get your team to appreciate why starting right is in their own interest. Ally with the team.


2. Adapt or Die. If you don't learn from mistakes you will find it hard to survive. This is applicable for you not just as an individual but also for your team. Those who do not learn from their mistakes and from each other, keep running fire-drills. If using Scrum, lack of learning will manifest itself as smells and Scrum-butts. You might even give up parts of Scrum, abandon it altogether, or start using your own "easy-Kanban" method without applying WIP limits or even visualizing their workflow. Are you a leader of such a team or teams? Why do you think this is happening?


3. Be transparent. At times there may seem to be a tendency and perhaps even an incentive not to be transparent about your project and team. There could be many reasons for this situation, organization-created or self-created or just fabricated from fear. When you look into the reasons, think about what is best for you, best for your team, best for your organization and best for the customer - ideally, all the four should have the same answer. If not, dive deeper and ask why is there a difference? Can you do something? If you can't do anything about it, are you at the right place doing the right job?


4. Promote collaboration, simplicity, and excellence. Agile principles talk about collaboration, simplicity and emphasize technical excellence. There is usually nothing more powerful than collaborating to deliver successful outcomes, in small chunks, along with technical excellence, that motivates a strong development team. As a manager, you carry a ton of influence and responsibility to make this happen.


5. Deliver customer value and team happiness. You have demonstrated your success as a manager when your team is delivering functionality that makes customers happy, it is building-in quality into the product, and is proud of its accomplishments. The process may be useful but it is not the goal.

Good luck!