Quarterly Team Reviews and Retrospectives

Perhaps a review of Kaizens over the past 3 months?   The Team can discuss what worked, what experiments failed, and potentially stimulate conversation around additional ideas for improvement.



Also, such a checkpoint serves as a good opportunity for the Scrum Team to reflect and see the incremental changes they've taken to get to a better place than where they were 3 months ago.   Sometimes, that isn't easy to see when the changes are small.

Take for example fully reviewing the Definition of Done.

There’s something right there. Not just reviewing the DoD itself, but also why it isn’t being “fully” reviewed every Sprint, the technical debt that incurs as a result of any deficit, and how inspection and adaptation of the DoD can perhaps become timelier.

There’s something right there. Not just reviewing the DoD itself, but also why it isn’t being “fully” reviewed every Sprint, the technical debt that incurs as a result of any deficit, and how inspection and adaptation of the DoD can perhaps become timelier.

Indeed!

Not to say it hasn't been considered at each Sprint end, it just hasn't been warranted given the stability of this particular team. If something seems out of process or is something new for the team, or a situation didn't quite fit with current DoD during the Sprint, it's addressed at that time (if not earlier) and showcased during Retro. 

What I'm really wondering about is about the non-reactive reviews. Has anybody taken separate time for the team to take a deeper dive into their current process to find areas where accommodations were once made (even from a system/dept level), and assess or build strategies to further bring them closer to the ideal? 

I am going to start this out with a statement. I am not bragging in my response. I reread it and I felt it could be interpreted that way. I attribute it to the fact that I have been fortunate to work with some great people that came to value teamwork and the values of using agile practices.

My teams have never found any value in extra reviews of any kind. A couple of them have suggested them only to quickly ask that they be discontinued when undertaken. The teams have been very open and honest about what needs to be discussed. They have all been very willing to discuss anything at anytime.  The DoD has been under constant review and refinement. Experiments are identified and discussed immediately following to determine effectiveness, any adaptions needed or whether to abandon and start over.  Product changes are scrutinized at every opportunity.  All of this occurs based on the time boxes of Sprints in the Scrum Events at a minimum.

The core of agile practices is the constant inspect and adapt loop. If you wait for a special occasion to inspect and adapt then the practices loses their value. Since the Sprint Retrospective is specifically identified for the purpose you are discussing, why is there a need to add another? 

But I didn't do this on my own.  These were team decisions.  We didn't start like this, we inspected and adapted to this. You didn't really state that there is a need for it, just that you feel it would be a nice thing.  I applaud your ambition and dedication to finding ways that could help your teams improve but remember that in the long term you are a Scrum Master and your job is to help the Scrum Team improve in Scrum practices and adoption.  So if you feel that adding an additional quarterly review is warranted, ask your team how they feel about it and what they would like to accomplish in that review.

Thank you Daniel for the insight. I totally agree that these are team decisions. I would never bring this onto them without first asking if they think it would be valuable and is something they'd want to participate in.

You are correct, there currently isn't a need for this activity. I was just curious to see if teams have had any fun looking back on the quarter/year, and what's worked. Do any teams find checkpoints useful, if they choose what criteria to use? 

I guess now that I've thought about this more, the value I'm trying to achieve would be to further bring the team together, so perhaps instead I find an opportunity to showcase their successes, accomplishments, and recognitions perhaps at the start of the new year.

Why wait until the start of the new year?  If you have a mechanism to showcase success, do it anytime there is something done that is considered a success.  Focus the recognition on what is delivered not something like "This team has completed all the stories in their Sprints for the last 4 months".  Stretching here for a suggestion but how about something like "Team A delivered 8 iterations of a single product feature that ultimately lead to 40% of our customer base renewing their contracts". Show how the work they did lead to customer satisfaction and how that satisfaction helped the company to see value. Or another one is "After 3 iterations on an experimental product enhancement, the team determined from customer feedback that the enhancement was not going to be used so the experiment was canceled."  They saved money in a relative short amount of time and shows return on investment. 

Showcase any kind of "win" as frequently and often as possible as a means of providing transparency into what the team is doing.  Include the Product Owner and Development Team in the delivery of these showcases even let them to make the presentations.  Or if you have an internal stakeholder, include them also. It might be good for a Sales member to show how the Scrum Team was able to take a suggestion that turned into a profit or avoided a outlay of resources that would have been a waste.