When the going gets tough, don’t cancel the Retro

If times are tough on an agile project, whatever you do, don’t cancel the Retrospective meeting.

Let’s be clear, cancelling that meeting is removing an opportunity for the team to inspect the way they have been working, and adapt how they do things so they can improve.

Stop Start Continue

That’s an opinion I’ve held ever since I started working on agile projects back in 2008. It just seems logical to me. I had a conversation this week that reinforced that position.

I was chatting to a couple of members of a development team over lunch about their project.  They couldn’t really stop themselves from complaining about some difficulties their team had been experiencing over the last few months. They highlighted a few issues that they felt could be improved and discussed how they’d like to change aspects of how they work together. My overall observation was – they seemed pretty fed-up.

When I asked if they felt they could discuss these worries in their next sprint retrospective meeting, one of them told me how those meetings had not really helped solve their problems in the past. In any case, their team felt they spent too much time in meetings in general, so they had decided to change their process and only have retrospectives at the end of every other sprint. As a result, they had a retrospective meeting once a month.

I recommended that they have a retrospective as often as possible, given their description of the project. One of the team members stopped me and said, quite matter-of-factly and without a drop of irony, “Some of us, Chris, have a more pragmatic approach”, he shrugged apologetically, “we just prefer action over meetings”.

He looked at me somewhat condescendingly, eyes filled with pity as he considered my misplaced faith in a meeting. How could a group of people coming together to talk about stuff be preferable to actually ‘doing things’?

Somehow I managed to stop myself from slamming my forehead into the table in disbelief. I also avoided making the suggestion that the pragmatist’s preferred action seemed to be complaining about the problems they had, rather than trying to resolve them. I did, however, embark on a robust cross-examination of what was meant by the term “pragmatic”.

My recommendation to the two colleagues (who are good guys, by the way) was to not give up on retrospectives but to talk to their manager/scrummaster/facilitator to see if they can design a meeting together that would help them tackle their problems. And they should definitely have a retrospective every sprint.

I described the kind of retrospective activities that might help surface and explore the issues they were experiencing. A teamwork satisfaction poll, perhaps? Or a Mad/Sad/Glad activity? This seemed to gain some traction with the other team member, who went away to talk to the facilitator earmarked for their next retro.

Teams can label the time they spend in retrospectives as worthless and futile. Often, this is because they’ve experienced some poorly run or structured meetings that have failed to produce valuable, insightful actions. In these cases, I’d plead with a team not to give-up on retros and suggest reading Agile Retrospectives by Derby & Larsen to give their meetings a better chance of success.

Teams have been know to cancel retrospectives if they feel like they are under too much time pressure and are forever racing to reach difficult deadlines. For me, taking time away from your desks to reflect on what is going on when a project feels like it is in a perpetual race against time, is invaluable. To be honest, if you think that having the team in a meeting room for one hour every two weeks is going to make your project fail, then it’s going to fail anyway.

So, if you are on a difficult project and are considering cancelling or reducing the frequency of your retrospectives, ask yourself what the root cause of that drive is. Then consider whether that root cause is something that would actually benefit from a regular, frequent opportunity to inspect and adapt.

Release Wednesdays

This Wednesday, one of the teams I work with shipped a new version of their product – the DLM Dashboard – for the 10th Wednesday in a row. That’s 10 releases in the 10 weeks we’ve had of 2015 so far. Which is pretty cool.

One of the notable things about that release record is that we haven’t shipped on any other occasion in 2015. That’s because we made a working agreement to release only on Wednesdays. Imaginatively, we call this initiative Release Wednesdays. Yes, it’s a thing.

As a result of putting Release Wednesdays at the heart of how we develop and deliver software, we’ve optimised our projects, processes and practices so that we can to release frequently and deliver new features incrementally. Interestingly, in addition to increased pace of delivery and user feedback the weekly cadence gives us, we’ve found many of these optimisations to be beneficial in their own right.

Before I highlight some of those optimisations, here’s a quick synopsis of ‘why’ we have Release Wednesdays:

We release every week because:

  • We want to give our users valuable enhancements as quickly as possible and get timely feedback on the direction we are taking the product.
  • We believe in keeping the delta between releases small and the risk associated with an individual release low.
  • We think practice makes perfect and that the more often you release the less frightening it is to do so.

We only release on Wednesdays because:

  • We want to have a ‘deliberate’ release process, not an ‘opportunist’ one.  An opportunist release process results in an irregular release rhythm; sometimes there might be three releases in a week, sometimes one a month. You release when you can. A deliberate approach to frequent releases means a regular, sustainable rhythm.
  • It keeps us honest. In order to achieve our goal, we need to be able to keep our build ready for release continually.
  • We don’t have to think about when to release. An opportunist release process means that you need to continually agonise over whether ‘now’ is a good time to do a release or not. That decision can take time, effort and (possibly) a great deal of thought. Agreeing to release every Wednesday means that our ‘when should we release?’ problem is solved.
  • We don’t want to drown our users in updates. We think that one release a week is frequent enough for users to get their hands on the latest work we’ve done and give us timely feedback, without the update notification becoming irritating.

How we’ve optimised our approach for Release Wednesdays:

  • The team are responsible for the releases – they decide when things are shipped. In parrallel, I’ve encouraged them to buy into a weekly release cadence and do my best to coach them when they discover obstacles to delivering stories. Without the team being behind this initiative, it was not going to work. Once the team had tried it and liked the momentum we achieved, the approach was here to stay. Now, getting then current story done in time for next Wednesday is hugely motivation for the group.
  • We’ve streamlining our release process – automating everything we can and simplifying everything else. For example, we rely on automated testing to prove builds and, thanks to an internal tool, we can deploy to Production with the click of a button. See my post from 2013 about the benefits of automated deployments.
  • We break our work up into small, incrementally valuable user stories. This is so that they can be integrated into our weekly cadence – each story should be around a week to two week’s work for the team. This is obviously a bit of a black art, so we’ve had to think a lot more deeply about the scope of our user stories and their relative value. We have found that we have a much more ‘agile’ backlog and a good feel for what we can achieve in a week.
  • We keep the product code in a continually releasable state. This is a working agreement and has pushed us to use separate branches for each feature, user story or bug fix, so that the root of our source control repository only has work that is fit for immediate release. An additional benefit of this is that any parallel streams of work (e.g. a new feature and a big fix) are isolated from one another and so can be shipped independently.
  • We apply the Agile Release Train technique, which has brought it’s own benefits – #NoEstimates, Team-driven scope management and clear planning horizons. See my recent post on the Release Train for more details.

Just to be clear, almost all of these optimsations have caused us problems from time to time. For example, we sometimes find it difficult to keep within the bounds of our small stories and the pressure of always want to get something finished for the next Wednesday can feel relentless if we are not mindful of it. It’s also fair to say it’s not going to work in every environment, with every kind of software development project. However, we build a COTS product which is installed on hundreds of client machines across the world and it works well for us. I really beleive the benefits of a deliberate, weekly release cadence far outweigh the disadvantages.

I’d encourage other teams to experiment with Release Wednesdays – well, to try deliberate releases on a day of your choice at a fixed cadence (weekly, fortnightly, even monthly). We probably shouldn’t all choose Wednesday. If the enitre world released their software on the same day, it might be a bit wierd.