At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

Discover why regular retrospectives will lead to team and business success and how to overcome a team's resistance to have an open dialogue.

Share This Post

[ Agile Manifesto — Principle 12 ]

Pause to accelerate!

Yes, you read that right. In the dynamic landscape of software development, maintaining agility, constantly adapting to change is a necessity for success. For this you need to adapt. But before that, you must inspect.

Why the 12th Principle Matters

Having put my Scrum Master/Agile Coach glasses on, a Retrospective to me is one of the most important Scrum Events. Why?

Reflection serves as the compass directing teams toward continuous improvement. It’s the mechanism that allows teams to adapt, evolve, and optimize their processes. A (good) retrospective is the catalyst for innovation and growth within a team.

However, unfortunately, a lot of teams seem to skip this meeting or — if it is held — use it as time to rant about others or pity themselves.

What are the reasons why a Retrospective is frequently sidestepped?

1. Complacency and comfort zones: 

Teams, once comfortable with a set of practices, tend to resist change. The familiar becomes the status quo, and the prospect of stepping out of comfort zones generates resistance. Even more so when taking a retrospective seriously could mean opening up, showing vulnerability, and openly criticizing a practice — all of which may lead to confrontation. Not very appealing, right?

2. Fear of confrontation:

There are people out there who do not shy away from conflicts. But (without having this backed by a study but only by my observation over 20 years), most people are not too keen to dive head-on into a confrontation. Team members may fear confrontation or worry about the potential for blame rather than constructive discussion. This fear can discourage participation, leading to avoidance of retrospective sessions.

3. Time constraints:

In the fast-paced world of software development, teams often find themselves chasing deadlines, leaving little room for reflection. The urgency to deliver can overshadow the need to assess and improve. In addition, managers often have little understanding when the team disappears for a non-technical meeting — which they, and some techies alike, hence regard as a non-productive meeting. This way, this serves as a perfect excuse to do some “real work”, instead of sitting in an armchair circle talking about one’s feelings.

“We must never become too busy sawing to take time to sharpen the saw.”

4. Lack of awareness: 

Some teams may not fully understand the benefits of continuous reflection. Without a clear understanding of the “why” we do that and how it contributes to success, teams may perceive it as an unnecessary or time-wasting activity.

5. Lack of facilitation skills: 

Teams may struggle with the facilitation of effective retrospectives. Lots of teams I met had a part-time Scrum Master who was also a developer. With or without a certification, these guys often had no idea what to do except to send out a meeting invitation for a retrospective. Sometimes they put up two flip charts in the meeting room: “What was good?” — “What was bad”? * cringe * What do you think follows after you ask someone “What was bad?” — Spoiler: hardly a constructive discussion.

Without a skilled facilitator or a clear structure for the session, retrospectives can become disorganized, leading to frustration and disengagement.

Overcoming Resentment and Fostering Engagement

As a Scrum Master, overcoming resistance and fostering engagement is a delicate yet crucial task. Here are some strategies to navigate this terrain successfully:
1. Cultivate a safe environment: 

Create a culture where team members feel safe sharing their thoughts and ideas without fear of judgment. This psychological safety is the bedrock for open and honest reflections. Foster an environment of psychological safety where team members feel comfortable expressing their thoughts and concerns without fear of judgment. Encourage open communication and assure the team that retrospectives are a blame-free zone focused on learning and improvement.

It can start so simply (and I am only mentioning this having seen it go wrong gone wrong more than once):

  • A safe environment begins with the room you are in: if you have a meeting room with fancy glass walls, be sure no one outside the room can read information on flip charts or whiteboards. Clean the room afterwards.
  • Be sure people feel safe that everything that happens during the retrospective stays amongst the people that participated in the retrospective (unless they decide otherwise). Whatever topics are being discussed, they should not be passed on to anyone standing at the coffee machine after the retrospective.
  • A safe environment also lives from the language we use. Pay attention to accusations, disrespect, you-messages,… teach people on how to give feedback properly. This is not limited to retrospective meetings, though.
 
2. Lead by example: 

Although we teach Scrum Masters to act as role models, this is not limited to the Scrum Master. The Product Owner as well as the developers are asked to demonstrate the value of reflection by actively participating in the process. Everyone is asked to share their own learnings and vulnerabilities. Creating empathy amongst your peers can unlock the next level of co-working success.

3. Connect reflection to success and highlight the value: 

Illustrate how past reflections have directly contributed to the team’s success, positive changes, improved processes, or enhanced team dynamics. Concrete examples help team members understand the tangible benefits of this practice. Demonstrating the impact of retrospectives on overall efficiency and success can shift perceptions.

4. Time management: 

Acknowledge the time constraints that teams face and emphasize that retrospectives are an investment rather than a time sink. Ensure that retrospective sessions are well-structured and time-boxed to fit within the team’s schedule. Highlight that the time spent in retrospectives can save time in future sprints by identifying and addressing issues early. Sometimes times are indeed crazy-busy. If you feel the team members cannot sit through a 90 minute session and focus — as their brains are stuck in their code, think of a 5- or 10-minute-retro. Improve only one small thing for the next sprint but do not skip the retro. If crazy-busy is your default, well… then you might want to examine that.

5. Variety in retrospective formats: 

Inject variety into retrospective formats to keep sessions engaging. If teams are confronted with the never-changing “what went well? / what could be improved?” — their creativity dies. Experiment with different techniques, such as Start-Stop-Continue, 4Ls (Liked, Learned, Lacked, Longed For), or Mad Sad Glad. Changing the format regularly prevents monotony and maintains team interest. The internet is a wonderful source of ideas for retrospectives. Go and try some!

But before you do… There is one MUST-READ for all new Scrum Masters: “Agile Retrospectives: Making Good Teams Great” by Esther Derby and Diana Larsen. This one is so much a classic as it is filled with retrospective activities that will serve you greatly if you step into the role of facilitating retrospectives.

6. Rotate facilitators: 

Teams without a Scrum Master tend to skip Retrospectives even more. It does not require the lack of a Scrum Master entirely, but starts with the Scrum master being off sick or on vacation. Empower team members to take turns facilitating retrospectives. This not only distributes the responsibility but also brings diverse perspectives to the facilitation process. Providing training or resources on effective facilitation can enhance the quality of retrospective sessions. (also empathy with the work of a Scrum Master 😉 )

I know, I already plaited Scrum into this article. Scrum is my home turf. Having a retrospective at the end of each Sprint is defined in the Scrum Guide. So, Scrum practitioners are familiar with this concept naturally.

Now, let’s explore how the 12th Principle is applied across other Agile methodologies.

The 12th Principle across Agile Methodologies

The 12th principle is a cornerstone applicable to various agile methodologies, each with its unique flavor.

 

Kanban:

Kanban, with its emphasis on continuous flow and optimization of processes, incorporates regular retrospective practices to enhance efficiency and address bottlenecks.
Kanban encourages the establishment of regular cadences for reflection. Teams often conduct retrospectives at predefined intervals, to review the flow of work, identify blockers, and discuss opportunities for improvement.

Kanban boards, which visually represent the flow of work, serve as powerful tools during retrospectives. Team members analyze the board to identify patterns, observe lead times, and other metrics and assess the impact of different work items. Visualization enhances the team’s ability to reflect on their workflow effectively.

 

XP (Extreme Programming):

XP, with its emphasis on feedback and collaboration, incorporates retrospectives as a fundamental practice for continuous improvement. “Improvement” and “Reflection” are two of the principles of XP.

I want to share a powerful paragraph from the book “Extreme Programming Explained: Embrace Change”, by Kent Beck and Cynthia Andres:

“Good teams don’t just do their work, they think about how they are working and why they are working. They analyze why they succeeded or failed. They don’t try to hide their mistakes, but expose them and learn from them. No one stumbles into excellence.”

XP defines regular reflections points such as the end of a quarterly or weekly cycle, but emphasizes that you should not wait for an “official” meeting to reflect on your work or about yourself, but there are many opportunities to do so.

 

DevOps:

I want to mention DevOps, although it is not an Agile methodology per se. But it is extremely popular these days and we mostly tend to see it as automated, connected toolchains to deliver pieces of software fast.

However, DevOps promotes a culture of human collaboration and communication between development and operations teams.

Teams regularly reflect on the feedback received from various stages, including development, testing, deployment, and operations. This feedback is essential for identifying areas of improvement and making adjustments. Regular reflection on the effectiveness of communication channels, collaboration tools, and cross-functional interactions ensures that teams are continuously adapting to improve their working relationships.

 

Lean Software Development:

Lean Software Development, inspired by lean manufacturing principles, places a strong emphasis on continuous improvement. The 12th principle aligns seamlessly with the Lean concept of “Kaizen”, which refers to continuous improvement. In Lean, teams regularly reflect on their processes, identify waste, and make incremental adjustments to enhance efficiency.

These days less popular frameworks and methodologies embrace the 12th principle through practices such as retrospectives, checkpoints, and continuous improvement cycles.

Crystal Methodologies, 

developed by Alistair Cockburn, emphasize the importance of reflection and adaptation. Teams using Crystal Clear regularly reflect on their interactions, team dynamics, and project processes to optimize their workflow.

Feature-Driven Development (FDD): 

Feature-Driven Development, a model-driven methodology promotes regular inspections and adaptations. FDD includes milestones and phase reviews where the team reflects on progress, identifies areas for improvement, and adjusts their approach.

Dynamic Systems Development Method (DSDM), 

is an agile project delivery framework, incorporating regular reflections within its iterative development cycles. DSDM emphasizes the importance of reflection during its frequent reviews and checkpoints. This allows teams to adapt their plans and practices based on the evolving needs of the project.

Adaptive Software Development (ASD),

developed by Jim Highsmith, is centered around adaptability and learning. ASD teams regularly reflect on their work, gather feedback, and adjust their strategies to enhance both the product and the development process.

The Connection to Success

The 12th principle is not just a philosophical concept; it directly correlates with overall team and business success.

1. Enhanced team morale: 

Regular reflection instills a sense of purpose and accomplishment. Acknowledging achievements and learning from challenges boosts team morale and cohesion.

2. Adaptability to change: 

Teams that reflect regularly are more adaptable to change. They embrace new technologies, methodologies, and market demands with a mindset of continuous improvement.

3. Innovation and creativity: 

Reflection sparks innovation. Teams that pause to analyze and ideate find creative solutions to problems, fostering a culture of innovation that positively impacts the business.

4. Increased productivity: 

The insights gained through reflection lead to process optimizations, reducing bottlenecks and improving efficiency. This, in turn, translates to increased productivity and faster delivery of valuable products.

5. Customer Satisfaction: 

Continuous improvement directly influences the quality of the products delivered. Satisfied customers, in turn, contribute to positive word-of-mouth, customer loyalty, and business growth.

Conclusion

Reflection meetings serve as the cornerstone for maintaining agility and ensuring that teams are responsive to change. While often bypassed due to various challenges, their significance cannot be overstated. As a Scrum Master or agile practitioner, recognizing the value of regular reflection and implementing strategies to overcome resistance is key to unlocking the full potential of a team. In conclusion, by embracing the 12th principle, teams pave the way for continuous improvement, innovation, and sustained business success.

We are here to coach you and your team. We’ve got a range of awesome trainings for you to pick from.

THE poster to always have the Agile Manifesto right in front of you. Or simply, to visually enhance a dull workplace. 

Subscribe To Our Newsletter

Get updates and learn from the best

More To Explore

Agile Manifesto

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Unlock the secrets to workplace motivation in Agile development. Explore the vital balance between intrinsic and extrinsic motivation for fostering creativity, engagement, and resilience. Learn how autonomy, mastery, and purpose drive employee performance, while recognition and feedback maintain motivation. Discover how top companies like Netflix and Google exemplify these principles, and understand the cautionary tale of Nokia’s decline due to stifled autonomy and lack of support for intrinsic motivation. Dive into our latest blog article for valuable insights on building projects around motivated individuals to achieve sustained success.

Agile Manifesto

Business people and developers must work together daily throughout the project

Discover why Agile isn’t just a buzzword but a transformative approach to software development, where every interaction, decision, and collaboration counts. We delve into practical strategies, common misinterpretations, and best practices to ensure seamless cooperation and project success.

Are you a fellow Agilista or want to become one?

Get in touch and we'll walk the journey together