How to Handle Retrospective Suggestions that Challenge Agile Practices
Two major tenets of agile are self-managing teams and continuous improvement. Both tenets come into play during the scrum Retrospective, where part of the discussion involves ways to improve team performance. Inevitably, someone recommends a continuous improvement suggestion that challenges one of my core scrum values.
The Scrum Master is the agile scrum expert and facilitator. The Development Team decides how best to work together. What if the Development Team feels strongly that working more efficiently means throwing out an important aspect of scrum? Should the Scrum Master push back or allow the team to implement the new working agreement? Not an easy call.
I know where I stand and how I want to encourage my teams to practice agile scrum, so I recognize my boundaries. My internal alarms flash when my core values are challenged. I always push back. But, I have been known allow the team to proceed in a manner that seemingly goes against my better judgement.
It’s Not Always about Right and Wrong
Because I have completely embraced the agile mindset, I realize that everything is not always right or wrong. I have learned that you can slightly pivot the rules, allow changes to team behavior and still keep the intent of the original agile practice. When you can achieve, then you are truly agile.
One of my new agile Development Teams decided that they did not need me to facilitate their grooming sessions. At first I saw red. Whaaaaat?! It’s my job to ensure the Stories are properly formatted and sized for Sprint Planning. I tried to talk them out of it. I couldn’t. They voted and I lost.
This happened at the first Retrospective. I knew that if I did not permit this improvement to be adopted, I’d lose all credibility with the team. However, I am the Scrum Master and enforcer of all things agile. I allowed the team to adopt the change, but only if they proved that they could meet the criteria for proper Story grooming on their own.
In the next sprint, I setup a Wiki page that outlined rules proper for Story writing, grooming and sizing.
At sprint planning, I reviewed all sprint candidate Stories for correctness:
- Story Requirement
- Acceptance Criteria
- Story Points
If the Story did not meet the criteria, I had the right to demand it be immediately updated or I could put it back in the Backlog.
And you know what? The process worked. The Development Team was able to work independently to design and write their own Stories and I was able to enforce my core scrum practice of well -groomed Stories. Win-Win.
Some Recommendations are Just Wrong
In the real world, some suggestions are just wrong, but you may have to allow them to be adopted anyway. Why? Because I know a secret: Within the realm of continuous improvement lies continuous learning and more opportunities for continuous improvement.
Some lessons can only be learned through direct experience.
Not all bad decisions have to last forever.
Lucky for us, every Retrospective, the team has the opportunity to revisit all team practices at the end of every sprint. So, as a Scrum Master, I can revisit any adopted change and work with the team to reverse bad behavior choices.
I had another Development Team that decided at their first Retrospective they did not want to Standup every day. Of course, I knew this was a terrible idea. Again, I could not talk them out of it.
You know what? The outcome was textbook perfect: the Development Team completed half the number of Story Points in the second sprint as in the first sprint! Every other day was not frequent enough to keep their eyes on the prize.
At the next Retrospective, I was able to show the Development Team their error in judgement and we returned to daily standups. Yay!
Lesson Learned
As you can see, being a Scrum Master is not the same as being a waterfall Project Manager. It’s not about getting the team to complete tasks in a project plan, it’s about getting the team to work better together, work happier and get more stuff done.
Cynthia Kahn
CynthiaK@gsd.guru 503.799.5500
This couldn’t have come at a better time as I am experiencing push-back on a key system configuration. I already know the outcome if they do what they want to do, which is going to leave me right back here implementing what I think they should do now.
It’s not Agile, but it was a good reminder for me that the last say isn’t the most important that lessons for learning are always around.
That is what makes scrum masters different from traditional project managers. We practice servant learning and not assigning tasks. It’s certainly a hard mindset shift.