As a coach, a recurring situation one faces, towards the end of the first sprint after the coaching has started, is the push and shove to the retrospective. After seemingly making the team understand that two key aspect of Agile Scrum are to surface the problems at the earliest and avoiding any kind of waste. I naively expected that the team will be eager to do the retrospective, but wiser now.
The team will be scrambling to wrap up the work and close all stories to meet the sprint commitment made, the sprint will be kept open till the the very end and at times a few hours into the next sprint. The Sprint Planning for next sprint has to start, the Sprint Review needs to happen for stories to be closed, where is the time for retrospective? Can it be done next time?
At times they combine Retrospective and Sprint Planning, which results in speeding through the retrospective and getting quickly into the planning. Add to this the different locations and time zones of the PO and Scrum Team. The retrospective at times is scheduled after Sprint Planning, which is anyway better than not having it at all.
So here is how it goes, the three questions are asked, inputs collated and a mail sent to all stakeholders and the collated inputs made available in a common area. Very less focus on listening to each other and trying to resolve issues.
The way I deal with this is that I share with the Scrum Master and team on how an ideal Retrospective should proceed and leave it to them to get close to it:
– Use post-its to capture what went well, stick on board, have one of team read all of it. Clarify any point that is not clear,
– Same for what did not go well,
– Same for what they would start to do,
– At this juncture prioritize the start to do/action items and brainstorm, starting from top till the time runs out.
This has worked well, teams typically identify one to three items and come up with reasonable details for implementing them. If required I remind them of these mid sprint, some steps are taken and progress made, this helps in them getting into the habit of doing retrospectives regularly.
One more point to note is that a problem that seems “a way of life”, at end of first sprint may get some solutions, in the subsequent sprint. My reading of this is that the problem when noted first is annoying and frustrating, team is mentally tired to work on it. But when the same problem surfaces again, they are able to come up with a solution, as the frustration is vented in past.
Let me share one example. This is to do with a scarce DBA resource causing stories to be re-opened due to delayed inputs/review. At the end of first sprint they made note of this issue and came out strongly on “this how it is going to be”, “we have escalated enough already in past”. The issue surfaced again in next sprint, as it was discussed before, the emotions were in check. One of team suggested that we use the grooming pattern, i.e., plan/do in advance. They figured out a way to deal with it.
Another oft repeating issue is the frustration of not being able to close a story, because just the show and tell (demo) could not happen, or a build and test in correct environment was not completed due to big queue in CM. The team argues for closing the story, they feel that they are loosing story points for no fault of theirs. Here as a coach, one has to reinforce the concept of “Done” and revisit the concept of “Velocity”.
