Experience Report On Retrospecting

I wanted to just do a quick experience report of some work I’ve been doing recently. This is around a retrospective, or a form of retrospective. It was really great to hear a lot of our retrospectives tonight about that continuous learning.

What we can see here is the team, as I first joined the team. We can see this is a pretty common wall that you’ll see in a lot of development teams. You’ve got design or analysis design, ready for dev, in dev, dev done, tests, test. Of course, look how long that board is. They’ve got several boards.

When you give somebody a load of a big boards, they want to fill every last inch of those boards. They spread everything out really wide, and it was all really good. To be fair, this team are pretty good anyway. They’re delivering software every two weeks. Good quality, what more do you need?

What we did, I had to get the team into a good way of retrospecting, or what I consider a good way of retrospecting. The team were doing retrospectives, but the board wasn’t changing, or it was a lot of kind of noise around retrospectives but there was no real action. There’s nothing tangible that you could really put your finger on.

First thing I had to do was redraw the board for them. It kind of, analysis here, then you’ve just got this to-do backlog. Down here, we’re all the way to done, but what does done mean? Brace yourselves, all right, here we go. This is my style of board.

What we did is, this was their old done column, and this is their old backlog column there. If you think about, we’ve now taken, what is it, that whole board and we’ve compressed it all down into less than a single board. The first thing we do now, we’re encouraging them to limit their work in progress, giving them some physical columns which to work in.

Actually, what’s all of this here, and what’s all that stuff down there? This is all the hidden stuff that was causing them a lot of confusion or vagueness. When they say done, what do we mean by done? Is it live yet? When we explored downstream about what is live, we suddenly find out there’s what they call an RFC, request for change process. We have to go and speak to some distant team in some other location in the country, put a request in, give them a load of paperwork, give them a release package. Talking about , and this isn’t feeling very agile anymore.

Then we’re ready for live, but on what delivery stream? Which product are we talking about? Actually, how do we manage that all the way into live? That’s the first thing we did. We then went upstream and we said, how does stuff get into the backlog? We have to go and test user needs, we have to do a lot of UX type stuff.

We created a UX stream here, because up until that point, this was overlaid with this works, you had a bunch of people all kind of falling over each other, metaphorically speaking, then trying to measure their throughput and velocity based on two completely different value streams or different delivery streams.

Actually, when they test user needs here, sometimes things did actually go past done here, and would appear in the downstream work, in other words we’d validated the work that had been the user needs, so it does need to be developed. Otherwise it’s just very lightweight prototyping, very use-tested needs.

Let’s move onto the retrospective part of this. Actually, this gave us even more problems because now we’d sorted out what the end to end value stream was, and got real clarity, the big pushback was Jira doesn’t support this, can’t do that in Jira. You kind of can.

No, you can’t. Yes, you can. What we did is we took different chunks of the board, and even though it’s one continuous set of statuses in Jira, we sort of split it up into different boards in Jira. Just a quick note on that one, okay. We can still go into different areas of the board. They kind of overlap. This column here is the same as that column there, so you should see them. They don’t quite match at different times.

Retrospectives. There’s one part of the board, right at the bottom end of the board, over on the right there. See this, right over there? This is a real time retrospecting area. The way that works is as follows. Look how much stuff is in their done column. This was after three weeks. They’d got that much stuff improved, and done, and identified. I just gave them the mechanism in order to do that, and I’ll share that mechanism with you now.

What we do is a retrospective. At the end of their sprint, they’re doing two week sprints, they come around the board. They get everybody from this end of things, including stakeholders for even how this stuff get into here, product owners, various stakeholders. They get people from operations downstream, they get development team, they all crowd around this board. They all grab a bunch of post-it notes, and then they start to analyse what areas of this system can we improve.

What we’ve done is we’ve visualised their end to end system. Remember, one of the Toyota, or one of the lean principles is that you work on the system to improve the system. We need to improve this.

This one here, for example, probably said something like, ‘Well, it’s a big vague how we prioritise stuff to go into the ready backlog.’ Okay, that’s what we’re worried about, let’s put that in the options for improvement. We need to get clarity and get the right people together. Maybe there’s some stuff around the release process down here, we need to improve that.

How does stuff get into this backlog here? They’ve got various backlogs in this team. How does stuff get into the UX demand columns? Excuse me. Again, what you get from doing this is a set of everybody collaborating, looking upstream, downstream, putting ideas and bringing it to life a lot more.

Then all you do is you simply take all of those tickets, and they go into your options for improvement on your real time. Then at the end of every daily stand up, the team, once they’ve finished daily stand up, they all then swarm down here and they all look at what are the things we could improve as we go through the next few days. They’ll each pick a little item and start to work on that.

What that gives is a real focus continuously on retrospecting. I’m finally, they’ve ended up, that was taken yesterday. They’re doing pretty good. I’ve not even been with them quite a few days, so they’ve just been on their own. Even real time, they won’t wait until the retrospectives. Sometimes they’ll find things and put it straight into the options for improvement column. Again, it just keeps at the forefront of everybody’s mind on continuously improving. Thank you.