The “sticky shotgun” retrospective

I’ve been meaning to write this since early last week, but my first two weeks at Betfair have kept me fairly busy. After a nice chilled weekend, I finally have the time to get this down!

So I started a new job at Betfair at the beginning of April and have gradually been introduced to a few different ways of doing things. On my second day, we had a retrospective for the team’s previous sprint – which obviously I didn’t participate in, so I had the benefit of seeing how they do their retrospectives before being actively involved in one. The approach was subtly different from what I’ve done before, and I thought it worthwhile to share with others that work in a Scrum team.

Martin explained how it worked (for the benefit of a few of us that hadn’t done it their way before) and used the term “sticky shotgun” – which I think describes it quite aptly. Here’s how it works…

Everyone is given a marker and a pad of PostIt notes (or “stickies”) and writes down whatever comes to mind from the previous sprint. When they’re done, they all go up and stick them on the whiteboard in the correct zone (hence the term “sticky shotgun”). They use five zones: Start, Stop, Keep, More, and Less.

After the sticky shotgun, the stickies are clustered together into groups of similar issues. As you might expect, there are bound to be a lot of similar issues raised, as everyone has worked on the same user stories within the same team for the last two weeks. Instead of going through each individually, grouping them speeds up the process. To make sure nothing has been misinterpreted, they are always checked with the author to ensure that they’re put together in the correct group. We then briefly discuss the issues and try to identify what needs to be done to solve them; or in the case of the “keep” issues, what was done that makes the item worth keeping.

After the grouping and discussion, everyone is allowed to select their three most important groups. This helps rank the groups in order of importance so the team knows what needs to be addressed first.

This approach seems to provide a few distinct advantages over the way I’ve done retrospectives in the past:

Firstly, it allows a greater degree of participation. Not everyone is comfortable voicing their opinions in a group – particularly when they’re talking about the areas that need improvement. Allowing each person to note their thoughts down independently ensures that their opinions are heard.

Secondly, it speeds up what can be a very time-consuming meeting. It is very likely that a number of people have similar issues. This method allows everyone to voice their opinions without needing hours of everyone’s time. It also clearly identifies those opinions that are shared by a large number of people on the team.

Thirdly, it prevents snowballing. Quite often, one issue sparks off another and another – and before you know it, you’re not really focusing in the right direction. The point of the retrospective is to raise the issues, not to solve them. This approach provides for a relatively short period of problem identification, followed by a short period of problem definition, followed by a final short period of problem prioritisation.

Overall, it was very interesting to see a different slant on retrospectives, as they seem to be the quiet brother/sister in the Scrum family that no one talks about. There are hundreds of discussions over how we write user stories, how we estimate and assign story points to our user stories, how we sell Agile to customers – but I don’t recall seeing as much discussion over retrospectives.

Ultimately, it is the retrospectives that help us to see what we’re doing right or wrong and where we can improve. So it’s definitely a topic worth talking about.


Opposing views on the UML {xor} constraint

During my last lecture week at Oxford, a debate arose over the interpretation of the xor constraint within UML class diagrams. We were divided over two differing opinions, but were unable to reach consensus on which was correct. I’ll put forward the two views and give my opinion on the matter, but would be interested to hear if anyone knows the correct way to interpret this constraint.

This is the class diagram I’ll use as a reference for the opinions explained below. I’ve deliberately used simple names for the classes to avoid misinterpretation, as I’ve found that people often get distracted by the “real world” application of the diagram rather than the semantics of the notation – which is what we’re really trying to understand here.

Opinion A: the xor constraint applies to the association
In this case, we say that the xor constraint applies to the association itself, which means that the multiplicity of the association remains in effect. In other words, one of the following must be true (but not both):

  • EITHER: An object of type A may be associated to zero or more objects of type B
  • OR: An object of type A may be associated to zero or more objects to type C

Opinion B: the xor constraint applies to the link (the association instance)
In this case, we say that the xor constraint applies to the link between the objects, which means that the multiplicity specified on the association is effectively ignored. Regardless of the multiplicity specified on the association, the xor constraint requires that one of the following must be true (but not both):

  • EITHER: An object of type A must be associated to exactly one object of type B
  • OR: An object of type A must be associated to exactly one object of type C

According to UML 2 Toolkit (OMG Press), page 108:

The xor constraint specifies that objects of a class may participate in, at most, one of the associations at a time.

From what I can tell, this appears to support Opinion A above, which is also what I believe. This quote appears to be further reinforced on page 303.

It seems unnecessarily restrictive to apply the xor constraint to the links, as this substantially limits the usefulness of the constraint. In addition, Opinion A allows for the modelling of Opinion B by using the xor constraint with multiplicities of 1. So, given that Opinion A may be used to model a much wider range of possibilities, I don’t see how Opinion B would be very useful. Opinion B also opens the model to miscommunication, as the multiplicities would no longer make sense and should be disallowed when the association is used with the xor constraint.

That said, this is simply my opinion based on what I feel is logical. I don’t actually know for a fact which is correct. I completely understand why holders of Opinion B see it their way – I just don’t see how such strict semantics would be useful in this case.

Does anyone else have a different opinion on this? Or perhaps know the correct answer?