After conducting two sprints with a consecutive testperiod, where everything did not end up the way we wanted it to be, we found it to be a good time to do some retrospective. Of course, this should be done after each sprint, and to a certain extent it has. However, we had much to talk about after this delivery. Here’s an example of our retrospective
Background: our customer demands that all production dates are pre-defined. So the question is how much work can be done by then. In our case, we managed to get two sprints and one test period done during this delivery phase. The delivery was completely dependent upon a 3rd party feeding data through distributed components.
Problems:
The well known distributed component problem: the component didn’t work for a number of reasons. 1) the configured address was wrong, the components didn’t have the same version, the component API didn’t satisfy the documentation API, hence our “design by contract” was broken upon contact. In addition, resources on the project had to handle issues outside the project as well, giving an inconsistent development environment.
The result:
A partial delivery, after many days of fixing after production. Not really a success, but not entirely a failure either.
The retrospective:
Every developer who wanted to attend showed up. However, only team members were allowed to speak. Everybody else had to listen (their presence was optional). The agenda had three cases that needed to be followed in sequence:
- Identify the progress of the sprint(s)
- List complaints / success stories
- Make a list of improvement points that could be implemented
To answer case 1, we did a print-out of the graphs and impediment list from our ScrumWorks software tool. It helped us identify the progress of the sprint and what situations had happened. Especially cases where our progress was low we could double check with our impediments list and find out what had stopped us from delivering.
Case 2 was simply to allow some steam or give some credit. In our case much was said and not all of it positive. But nothing was personal. We were doing this as a team, and no individual was singled out. However, in cases were any individuals had been slacking, the team should have handled such an instance earlier. We wrote a two-column list on a whiteboard with negative / positve cases.
This helped us along with Case 3: it’s no use complaining if we can’t improve it. All internal cases we felt we could improve on, was written down and given an “action”. Something we could start doing. Improvements outside the team was written down in a document and handed over to management as a “joint team improvement feedback document”.
conclusion:
The meeting was successful, but in order to have a constructive meeting, we needed to follow the path the three points above led out: 1) Identify the progress, 2) List complaints / success, 3) List improvements. I believe such a retrospective makes us a better organization. However, we still need to make sure that our improvement list is followed and executed.