Last Monday, we held the first retrospective meeting on our project. I had pushed for it to take place, and I thought it would go better than the Sprint Review. As it happened, it did not.
First, I contacted people much earlier. For the Sprint Review, I only told the customer on the very same day. This time, I told my onshore and offshore colleagues well in advance. I did keep the customer out of the loop, on our delivery manager’s advice, considering that we were not sure how it would go anyway.
In a Scrum Retrospective Meeting, all the stakeholders (Team, ScrumMaster, Project Owner) get together. Here how it is supposed to go (if I got it right):
- split in small groups, listing positive things that have taken place in the past iteration (“plusses”), plus things that can be improved upon (“deltas”). Hence, the “plus-delta analysis”. Some people also like to add any significant events that have taken place in the past iteration;
- show & tell about their findings to other groups;
- the group members get together again to discuss possible actions;
- show & tell the actions to the other groups;
- finally, voting takes place.
Here is how we did it wrong:
- we first met on our respective sites, discussing only the negative aspects of the past iteration;
- then, we presented them to the offshore manager;
- then, we (onshore) discussed possible actions;
- then, we presented those actions to offshore;
- finally, we published them on the project wiki;
- voting is supposed to take place in the days coming after that (though I have no clear idea when or who will do it).
I was reasonably pleased with our findinds and our actions. Though they were not many, and though we did not list positive aspects, at least the actions were quite concrete and easy to assign.
However, I found that the actions from the offshore team were not very good: actions were not well identified (“we should get more information on what onshore is doing” to which I responded: “we are already doing that, what do you want us to change or do instead?”. They did not say.) Strangely enough, in some cases, they *did* have actions in mind, but did not communicate them. For example, they mentioned that “bug management should be streamlined”. OK… but that’s not an action. Well, after some searching, it appears that the action was to define a process and that it was to be done by offshore. Alright, then!
Much of the conference call was spent trying to explain what each other meant (not easy to make a French team and a Indian team communicate… with each speaking English with a funny accent). Some more was spent on justifying and some (limited) finger-pointing. In the end, only a small portion of the time was really spent on productive activities. Most concerning was the fact that the onshore project manager thought that it was a waste of time (I did my best to explain her that we’ll do better on the next iteration).
Here are some suggestions from Craig for next time:
- do the entire plus-delata analysis and action finding before the proper Retrospective Meeting. The results should be published, preferably on the project wiki, before the meeting;
- show & tell all this to the other team;
- vote (offline).
We’ll see.
