Conflict to Creativity: Harnessing the Power of Sprint Retrospectives
Hiral Shah
Project Manager | Agile Leadership | Project Delivery | Customer Engagement | Customer Success | Team Leadership | IT Project & Program Management
Sprint retrospectives is one of my most favourite scrum ceremonies. I always try to be more innovative to help my team to open for their concerns and share ideas for process improvement. It helps uncovering a team’s challenges and opportunities for improvement. Conducting an effective retrospective is an art. Active participation hinges on the team's confidence in their Scrum Master.
In one of the retrospectives, the team expressed concerns about the quality of user stories. They highlighted many issues restricting from resource transitions and outdated refinements, leading to unclear scenarios and unnecessary discussions. The team sought a solution to these problems.
In such critical situations, Obviously, anyone remember LORD and So I.
Here LORD meaning: Listening, Observing, Reading, and Dialogue.
As a Scrum Master, it's crucial to protect the team and focus on process improvement without directly confronting the product owner or stakeholders. No one appreciates hearing "Your requirements are unclear" or "The team is complaining about user story quality."
The key is to approach the situation with tact and perspective. Trust with stakeholders and the product owner is very important. It is not only they trust you but we also has to trust them that they will listen with open mind and will help clear team’s doubts. Especially when my product owner was so sincere and conducting meeting every week, this type of scenario was frustrating for her too.
Instead of directly stating the team's complaints, I reflect on my responsibilities and aim to create a win-win situation for everyone.
In addressing the team's concerns about requirement clarity, I empathize with them, acknowledging their courage in voicing their issues. I assure them of my support in resolving these matters with the product owner.
This approach reminds me of a childhood story which my father used to narrate: "Who will tie the bell to the cat?" It highlights the importance of personal and character ethics. Trust is built and nourished through consistent, genuine actions.
Understanding stakeholders' personalities is equally very important. While some prefer straightforward feedback, most appreciate respectful communication. Here's how I navigated this situation:
First I had a one to one informal meeting with product owner. Discussed her views on project, timeline and asked feedback for team. Any process improvement is a collaboration and two-way street. I acknowledge her views on productivity impact because of resource transition, knowledge sharing, budget constraints, other projects are organizations priority, etc. Then I shared team's feedback in best possible constructive way. I did enough homework on scenarios and lacking information in user story. I assured that yes, team must be more proactive in refinement session.
After 2 days, I facilitated product backlog refinement meeting. In my mind I was very positive. There was fear in my heart but I had done enough homework to lead the conversation and set the right dialogue.
I set the agenda saying very positively that, this meeting is to think how we can be effective in weekly collaboration for requirements clarity. I appreciate team's courage and coach them to ask many questions providing them psychological safety. I appreciate product owner who is so open mind and happy to help the team to make the requirement clear.
When you speak all the positive words of their interest, it is natural and as expected, everyone was so attentive,
I took a pause and added that this meeting is all about understanding difference in perception, difference in expectations and let us be more creative in our approach for product backlog refinement and be 100% clear while committing sprint goal.?
So, lets be more creative and together we will articulate the story better and will improve the process. Now, everyone was guided what must be done, how has to be done and we all will do it together.
Everyone sounded positive, felt heard and ready to take accountability. At the end, team asked many questions, product owner was supportive and answered all of them, made sure they all are on same page now.?
Whatever I said or shared in either on-to-one meeting or in team meeting, nothing was superficial or on surface.
Focusing any techniques from any book only works if you live it day in and day out and that is authenticity, and more of a character ethics then personal ethics.
In summary:
Reflecting on this experience, I realized that effective communication is not just about words or good English vocabulary. Infact Effective communication is more about awareness of situation, understanding team, stakeholders, management and genuinely take interest in improvement.
Any such improvement is not possible only by reading books or by applying scrum ceremonies, but the real art lies in our perception, belief, and ability to inspire action in others. Setting the context as a collaborative effort for clarity, appreciating the team's and product owner's contributions, and fostering an open-minded environment made a significant difference.
My strategy involved listening with an open mind, empathizing with their pain points, and empowering them through genuine appreciation. This authenticity and focus on personal ethics facilitated a productive and creative collaboration, ultimately leading to process improvements and a stronger team dynamic.
This experience shows how design thinking helps when you see conflict as an opportunity to be more creative with others.
Design thinking is in Intellect’s DNA and this article is part of series on my experiences as a scrum master and how design thinking is helping me.
Whatever experience I am mentioning in this book is not only from Intellect-SJP but many of them are my previous experiences too. This disclaimer will help my LinkedIn family to be non-judgmental while reading.