At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
I coach the majority of my teams by first modeling the behavior that I expect, allowing teams to copy that behavior as I observe and correct behavior so that it matches the modeled behavior. To achieve this a great deal of my time is spent as an active scrum master – and I love it! I love having the opportunity to interact with individuals on teams, but there are times, after literally hundreds of iteration plannings and reviews (and thousands of daily stand ups), where it is difficult to keep things “fresh” or stay motivated, but this is never a problem when it comes to retrospectives, which is what the twelfth (and last) principal refers to.
Retrospectives are my favorite of all the scrum activities because they represent the opportunity to reflect on how we are implementing and to adjust our behavior to be more effective.
I have said to my teams on many occasions that if I were forced to choose only one scrum ceremony that my choice, without hesitation or reservation, would be the retrospective. Without it, how could we ever expect to improve? What essential difference would an “Agile” project have over the many death march projects that teams have come to accept?
There are always better ways of doing business. As a team we must come together frequently to honestly discuss current processes, evaluate potential alternatives and then experiment with alternatives to prove (or disprove) their value.
Since not everything works well for every team, it is important that potential improvements are seen as experiments. It may be that it is the right thing to do, but it is merely not the right time. I regularly tell my teams that we need to be “scientists” in that there are many things that we will try not knowing what the result will be, but it is important to propose a theory and conduct a proper experiment.
I extend this concept of theory, implementation / observation and retrospective to more aspects of a team than just the official retrospective. For example, instead of time “estimates” I propose that we have a theory on how long something will take and that we will test this theory by the end of the iteration. This provides a less threatening way of estimating so we can use real information to adjust our estimates to provide better estimates in the future (since regardless of the methodology people will, quite logically, expect to understand what teams are capable of in the long term).
One thing I have noticed in regards to retrospectives is that teams struggling with Agile transformation will often drop the retrospective ceremony (while keeping all the others though I have noticed a tendency to sit during stand ups as well). There are a number of possible reasons for this. One reason is that the organization is so addicted to a top down problem solving approach that management does not value identification and solving of problems at the team level so the meeting is quickly dropped. In these organizations honesty is rarely valued. Without honesty a proper retrospective cannot occur. One team I coached referred to their organization’s “more than healthy aversion to reality.”
I have run into organizations that have a misguided desire to track team experiments. These “best practices” shops think that if we only identify what works for one team then we can codify this practice and force all others to adopt this practice. This is a misunderstanding of Agile. While there may be “best practices” that work for all teams, this approach flies in the face of self-organization and ignores the fact that each team will mature at different times so the practice that works for one team may be completely inappropriate for another. I certainly do not have the same expectations for my seven year-old that I have for my twenty year-old.
Tracking experiments at the organization level also makes it more difficult to experiment, producing a chilling effect on teams. Instead of trusting that the team(s) will attempt experiments that are best for their particular circumstance, there is one more hoop to jump, one more monitoring, one more instance of distrust and more business as usual. As a result, teams experiment less, progress stagnates, the team experiences disincentives and any real change is exchanged for “acceptable” window dressing. After experiencing a few retrospectives under these constraints it is not difficult to see why teams choose not to pursue more retrospectives.
Three are times when teams have just not had coaching or training on how to properly conduct retrospectives. Some retrospectives become little more than glorified bitching sessions with no substantive changes discussed or attempted. This happens frequently when organizations tell teams that they will be agile but do provide real support in removing the systemic obstacles to team success. For every problem identified in a retrospective there should be a corresponding action – even if that action is the need to escalate this item to management. Once something has been escalated to management, it is important for management to be held accountable to the team and, from time to time, to report to the team on the progress of removing the impediments.
More importantly, since many problems may be systemic and beyond the ability of the team to change, it is incumbent on the scrum master to keep the team focused on the problems that can be solved. It is best to start small with things like meeting times, rooms, etc. Fixing “small” things that are in the team’s power can go a long way in helping them to “gel” as a self-organizing team.
As to the retrospective meeting itself, there are quite a number of folks who have interesting facilitation techniques. Personally, I find most of these “team building” techniques forced, gimmicky and condescending to adults. If they work for you, fine, but they are not my way.
Here’s how a typical retrospective meeting goes for me, I encourage everyone to try out my process to see if it works for your team. If it doesn’t, then try, try again!
I keep my retrospectives simple and generic in asking:
- What went well?
- What could be improved?
- What actions can we take? (To ensure more of the first and less of the second)
Gimmicks trade style for substance and if I do a good job of the “vanilla” retrospective, I find that I can keep it interesting and people engaged without tricks. The content of the discussion wins the day!
And I start each meeting with a simple statement of our intent, usually including something like Norm Kerth’s Prime Directive, assuring the team that the purpose of our discussion is to improve our work as a team and nothing is personal.
The second thing, that is often forgotten and is critical to retrospective success, is to take some time at the beginning to review what was discussed and actions undertaken in the last retrospective.
This way we can hold people accountable for delivering on the changes promised and not constantly tread over the same issues again and again. Of course, if the same problems persist and it is a good jump off for discussion, there is no rule to say that we cannot re-discuss or re-emphasize something from a previous meeting. Without this follow up step I have witnessed a great number of teams with great intentions, but poor execution.
The next thing that we do is to go over the three columns:
- For each thing that we identify as going well (or not so well) the team is encouraged to come up with some kind of action that will help us continue the good and improve on the not so good.
- For every action that is taken, someone (or a group) is assigned to be accountable. If need be, a retrospective action can be planned during iteration planning to make sure there is time to get the work done.
- The meeting ends with a statement of appreciation for the team’s honesty and courage in improving their work.
As far as timing of the meeting, I generally make sure that the retrospective is held in advance of the iteration planning so, as I mention above, any stories or tasks necessary for completion of retrospective actions can be accommodated.
Just as we try our best to eliminate work-in-progress for stories, we do the same with retrospective actions. Trying to do too many things at once is a recipe for disaster. Small incremental progress is the key.
While it is the last principle, as you can tell by the amount of commentary I have written around it, it is certainly not the least.
In fact, I contend that a team cannot achieve sustainable agility without the frequent feedback and course correction that team reflection provides.
And finally, keep on the look out for my new and improved ebook! I am adding the principles to it, so it will be full of great Agile information for anyone interested in transitioning to Agile or needing a refresher.
Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Android | RSS
, tells us that people are motivated by AMP (autonomy, mastery and purpose) and not surprising, self-organizing teams provide a healthy dose of all of these while receiving piecemeal work from “experts” is not at all motivating. No wonder that the best architectures, requirements, and designs emerge from self-organizing teams.
