About a year ago, I proposed to our team that we should adopt a continuous approach for our retrospectives. One of the questions that came up was whether this should be a replacement for regular weekly (or once per sprint) retrospectives.

After a year, I’ve come to the conclusion that you probably need both.

I came up with the idea of a continuous retrospective to fix a specific problem with regular retrospectives: halfway through the sprint, you realise that something is a problem, but by the time you get to your end-of-sprint retrospective, you’ve completely forgotten about it.

Another advantage of continuous retrospectives is that, in theory, they can shorten the turnaround time for resolving problems, so points of friction don’t linger throughout the sprint.

However, I’ve found over the past year that continuous retrospectives have one particular flaw: they can easily lose momentum. It’s all too easy to get complacent about continuous improvement, to end up having your retrospective board sitting neglected in a corner with nobody ever adding anything to it, and before you know what’s happened, you’ve gone from sub-optimal retrospectives to no retrospectives at all.

If you’ve bought into the 37 Signals/Basecamp/whatever they’re called this week “meetings are toxic” ethos, the idea of having one less meeting may sound attractive. However, the ceremony and formality involved in regular retrospective meetings gives them an inertia that keeps them going. It forces each team member to be regularly thinking about what is going well and what isn’t. And it provides a forum for the issues to be discussed in more detail rather than coming up with off-the-cuff solutions that may not be properly thought out.

Continuous retrospectives can definitely offer considerable value. But don’t ditch your end-of-sprint (or weekly) retrospectives. Rather than doing one or the other, you’ll most likely get the best value out of doing both.

Posted at 08:00 on 20 June 2017.
Tagged: agile, scrum, retrospectives

The sprint retrospective is one of the most important ceremonies in Scrum. At the end of every sprint, the team meets together to discuss what went well, what went badly, and how you can improve your processes  and working practices.

Effective as it may be, the end-of-sprint retrospective isn’t perfect. It’s very common to encounter problems during the sprint, only to get to the retrospective and  find that you’ve forgotten what they were. On the other hand, you can end up wasting a lot of time complaining about things that you aren’t able to do anything about.

To resolve these problems, we have recently implemented a “continuous retrospective” within our team. Instead of waiting until  the end of the sprint, we can highlight problems as and when they arise, and action them accordingly.

Besides the fact that issues are less likely to be forgotten, there are several other advantages to this approach. It is less formal, and a better use of people’s time. It improves communication. It can also improve visibility and transparency, allowing people to see that you are aware of, and addressing, issues that you are encountering.

A different approach.

This is a different approach from your traditional, end-of-sprint retrospective. For starters, it is less meeting-oriented. You simply set up a kanban-style board in your team’s working area, where you can add Post-It notes for things that are going well, things that need action, and things that need further discussion, perhaps to reach a team consensus.

Write things down as soon as you think of them — don’t wait until the end of the sprint, or even until the daily stand-up meeting. You should aim to discuss them with the rest of the team as soon as possible, and reach a consensus on what action to take. Actions may be, for example:

• Creating backlog tasks for the items you bring up
• Updating documentation
• Communicating problems or findings with other teams or the wider software development community as appropriate (e.g. through email, Twitter, blogs, or forums)
• Flagging issues to raise with senior management.

Don’t just limit items to things that are within your team’s remit. Anything that needs attention or can be improved is fair game — the appropriate action may be to raise it with other teams or senior management, for example.

Do you still need an end of sprint retrospective?

Maybe, or maybe not. It depends on your team.

Some teams may find that a continuous retrospective renders the end of sprint retrospective mostly superfluous. Others may find that the end of sprint retrospective still provides value — for example, by allowing you to check your progress, or to prioritise issues that have proven to be more complex to address.

But regardless of whether we retain the end of sprint retrospective or not, our goal is to make the continuous retrospective, as the sprint is in progress, the main driver of our team’s improvement. Agility is all about keeping your feedback loops as tight as possible, and like continuous integration and continuous delivery, continuous retrospectives are another way to achieve that end.

Thanks to Steven Wade, Vinitha Devadas and Dan Barrett for their contributions to this post.

Posted at 08:00 on 8 June 2016.
Tagged: agile

Agile practitioners have long referred to participants in the software development process as “pigs” and “chickens.” This comes from an old fable:

A pig and a chicken decide to go into business. After bouncing a few ideas around, they decide to open a restaurant. “What shall we call it?” says the pig. “Ham and eggs,” says the chicken. “No thanks,” says the pig. “You’d just be involved, but I’d be committed.”

Thankfully, this was removed from the latest version of the Scrum Guide.

It’s not difficult to see why. When you say “pigs and chickens” to someone these days, they don’t think about a cheesy, inexplicable, unfunny joke about commitment and involvement and restaurants. They think about this:

Somehow, I don’t think the idea of developers stealing the stakeholders’ eggs and the stakeholders launching themselves at the developers with a massive slingshot in retaliation would go down that well with management in many organisations.

Posted at 07:00 on 14 May 2012.
Tagged: agile