Mad, Glad, Sad retrospectives

I help my first retrospective for a while recently (that’s not to say the team hasn’t been retrospecting, just that others have been doing it in my stead!) and the team wanted to do the Mad, Glad, Sad exercise.Image

Shockingly, I didn’t know it. Or at least, I didn’t think I did.

The exercise starts with everyone writing on three different coloured posts-its the things that made the mad, glad or sad during the sprint. We then stuck them all up on the whiteboard under an appropriate picture.

We all studied it for a while, but I couldn’t really work out what the difference was between mad and sad. The idea of a retrospective is that you inspect and adapt. Look at what you did, how you did it and change things if they need improving. The idea of mad and sad should be things that, affected us negatively that we want to change in future sprints.

But what is the difference? I asked the team. They didn’t know either.

So, we set about trying to decide what each thing meant. In many retrospectives in the past, we’ve realised that there are things that went wrong, didn’t work or just plain sucked that we could fix and there were things that can be classed as ‘Shit Happens’. Stuff that, while we might expend some effort in fixing them, are unlikely to occur anytime in the near future, so we draw a line under it and move on – there are always more pressing things to deal with.

So, using this idea, we renamed Sad to “Get stuff off my chest” and Mad to “I’m not going to take it ANYMORE”.

Image

This means, we can highlight things that annoyed, frustrated or saddened us, but that, realistically speaking, there isn’t a lot of value in dealing with and then the stuff that REALLY got under our skin and we have to deal with.

Once we’d renamed them, we then re-sorted the post-its we’d stuck under the two columns and found that, things we might have dealt with as a real problem and spent time working on, were no more than just people wanting to have a rant, and real problems might have been overlooked as they hadn’t been applied with enough gravity. Perhaps the team member feels that it’s just something bothering them and doesn’t want to make an issue of it.

We worked through all three columns and, during discussion, decided to move some from Sad to Mad and vice versa as we discussed the pros and cons of each. In the end, we had a good, solid list of things that ‘we’re not going to take ANYMORE’ which turned into a list of definite actions.

So, if you run this exercise with your team, check their and your assumptions about what Glad and Sad mean – you may be met with blank looks – and make sure you all have the same understanding to make a good exercise into a great one.

Scrummaster? We don’t need no steenking Scrummaster!

Sad Face :(
A Sad Face by Emmaline

I discovered something strange today. I recently left one development team to go work for another (that’s for a seperate blog post all together) and I was chatting to some old team members today who had just had their Scrum Sprint Review/Retrospective and they mentioned one of the things that had come out of the Retrospective was that they aren’t going to have a Scrum Master for this sprint, or, it seems, any sprint.

“Huzzah!” I hear you cheer! “They must be self-managing!”

No, no they are not. It’s far, far worse than that. They’ve decided they don’t need a scrum master as, in their experience, the scrum master is useless. With no power to help the team make decisions and one team member describing the Scrum Master as “a puppet of the business”, then it’s quite clear that scrum, at this company, is broken.

It’s a sad day for me as ever since I heard about scrum about two and a half years ago from a colleague (@garethholt), I realised it’s potential. I’ve tried hard, arguing the point with colleagues, management and everyone who’ll listen. We’ve tried different length sprints, staggered sprints, digital backlogs, analogue backlogs, all sorts. Inspected and adapted and now it’s all for nowt. At every turn, the business said “No, I’m not confident enough to try scrum properly.” or, more accurately, “I don’t want to surface the organisational dysfunction.”. The team realises that the business cannot let go of the reigns.

It’s all about trust.

They all seem like the wind has been taken from their sails and it’s sad and dissapointing. Especially as they have an ‘Agile Manager’ and a ‘Product Owner’ who is also a director. Even the people employed to support scrum don’t seem to have confidence in it. Now THAT is a problem.

I might go home and cry.