Employment retrospective

Today was my final, working, day at my current employer. I'll not be starting at my new position until January 14th, even if I'm spending half a day at Fritidsresor in december, so I'll really have some time to think back and have my own retrospective. I'm going to follow my favorite five exercises for the Agile Retrospective book. The objective is to learn what I should try to improve at my new position.

So, now I'm just going to relax for a couple of weeks and then I'm doing a bit of research to prepare for my coming position. Well, I've already started! Me and the son is heading for Gran Canaria for a week's fun in the sun. And I'm collecting some domain knowledge too.

Giving a retrospective for another development team

Yesterday, I helped my husband and his development team at Concordia Bus IT to have a retrospective. I used some of the exercises earlier discussed on this blog, staring up with some emotions, drawing a time line, prioritize with dots and appreciations.

It was really interesting watching another team during a retrospective and it's really something I recommend to anyone being responsible for a retrospective. Not being a part of a team or a project changes how you view upon the whole experience and the exercises. I also think it can be a good thing for a team to have an outsider hosting a retrospective: they can all focus on the retrospective.

It was a really good and interesting experience and I'm happy to have been given the opportunity to participate.

Spice up your retrospectives

Even if I believe in having about the same tasks on a sprint retrospective, sometimes you should spice it up with some new stuff. And if there is a project retrospective or a release retrospective, you should really spice things up. Mark Levison gives some really good advice on both Info-Q and on his blog on some fun activities which real objectives.

Team goals

Goals and objectives are important. For me, anyway. When making up a product backlog, I find it important to have a product vision or product statement: how can you otherwise specify business value.

Having read about team goals, I've come to think the same about teams and impediments. If you hold a retrospective and for example use Prioritize with dots to decide which impediments the team should work on, how can you do this effectively if you lack a team objective?

Some Q & A on retrospectives

How do I select a time for a retrospective?
When it comes to sprint retrospectives, I want to have the retrospective on the same day as the demo. People going home and coming back the next day don't have that sprint in mind anymore. Most people forget how they felt the day before and that feeling is important to catch.

When it comes to a project retrospective, it's a good idea to have that on a separate day, but if the new project is up and running the day after, try having the retrospective before the other project starts.

Who's holding the retrospective?
The first rule is that the person should come prepared. The person should also understand or be able to read the participants. And the person should have the time and the personality to document the result and present it to stakeholders.

It's also easy to get lost during a retrospective. People can get into these long discussions and the rest of the crew get unintested or you don't have the time to finish the meeting. You need to be able to draw the line. Here I believe it's important to "park the question" instead of just dropping it. I tell the persons having the discussions that they can bring it up after the meeting or at a time that fits them. Of course this must be treated with care: some discussions are such as they cannot be dropped and have to be solved.

Who should participate?
This is a tough question. Of course, team members should participate but should other stakeholders participate? Depends on how free team members feel to take up their issues if for example a boss is present. The experiences of the participants should also be connected - it's no use drawing a time line if none the participants understands the other one's notes.

As a product owner, I've participated and I've been there just listening. Now I participate but stuff that does not involve the team's tasks are not presented. That should also go for part time resources - talking about details in the other project is of no use but if the other project affected this one - write a note which says "Other project".

Should you come up with solutions during the meeting?
This is also a tough one. Sometimes the solutions are easy to find but it's often easier to get into a long conflict driven discussion which ends with a really bad solution. If there is nothing obvious pops up, I tend to give people in pairs the task of coming up with one or a few solutions on a subject. It's best if everyone gets a task, but the most important thing is that the solutions should not always come from the same persons.

We have so many meetings, I don't think the guys wants more meetings...
There are few meetings that are directed at solving problems for the team as such, not the company, not the product, but their situation. The retrospective is for the team. Therefor it should be fun and there should happen something with the result of the meeting. If there are ideas and solutions from retrospectives which are never implemented, then out goes the retrospective.

My suggestion is start with a short, active meeting. Perhaps just drawing the time line. Then, always act on the suggestions of the team. The most important thing about retrospectives is that if the participants don't believe in them, they are a complete waste of time. And then having a beer and getting people to chat on can be a better option.

Retrospectives

If you're not improving: you are getting worse. So, you should always strive to improve. That does not mean that you should always change: an improvement can derive from continuing on a path already stricken. I've seen multiple examples of stuff going wrong and people feel an urge to change stuff, just to make themself feel better - at least we're doing something.

But I'm getting off track - I was going to talk retrospectives. Why do you hold retrospectives? Well, to know how to improve you need to know the current status and how people feel and think about that. Hence, end different periods with retrospectives. The periods can be anything from a meeting to a whole project: if you're having a retrospective over a meeting the retrospective should not take too long while the retrospective after completing a whole project should take it's time.

If we turn to the classic sprint retrospective, I've found that a one hour meeting is appropriate. I make a mental note of 1,5 hours if it was a troublesome sprint.

Then I come prepared: Agile Retrospectives is a good cookbook when selecting stuff to do. But selecting tasks can be a hazzle. My rules are: make sure there's a flow. That you use the stuff from one exercise to the next. This rule may not apply to the check-in exercise.

There are a number of exercises published online but I do recommend the complete book: even if you shouldn't change the exercises every time, you need som change too. I have the rule to only change one exercise at the time. This way there is something new but you don't have to explain everything before each exercise. Explaining an exercise takes away from a much needed flow.

I also include exercises where people are up and running: for example placing postits using Timeline or Prioritize with dots.

And finally: use the last exercise for something positive. Appriciations is the best exercise for me. - ending with everyone saying something positive is wonderful. But make sure that there is not apprications for everyone but one (if it is not called for) - being singled out as the only one not appriciated is not the best way to end a project.