Using Agile Scrum for a Change Programme

Over the past months I’ve been using scrum for a major change programme. It’s works well. Here’s how we have been using it.

The Sprint Team and Roles

We have a product owner, who represents the business outcomes and calls the priorities on our work. We have a scrum master who facilitates the process. We have a change team of 4 people who attend all the sessions. We have a couple of specialists who drop in as needed.

The Sprint Cycle

We have a 2 week cycle, starting Monday. I’m considering moving this to a different weekday, so it is less impacted by long weekends and bank holidays.

Kanban Wall

We have a classic Kanban wall. Split into 5 columns:

  • Story
  • To Do
  • Doing
  • Done, and
  • Blockers

Story Cards and Task Cards

We write our Stories onto white index cards. Each story card states:

  • An outcome,
  • A “So that” statement,
  • A due date (optional – usually end of sprint)
  • An owner
  • You can also add the “User” or recipient of the output.

Sprint Planning

We do sprint planning at the end of each cycle. It’s a 2 hour meeting for everyone. The product owner brings the overall backlog, and selects the top priority Stories for the upcoming sprint. We write these up on index cards and blu tack them onto the Story column. Sometimes these stories can stay up for a couple of Sprints.

The team assesses each story card and writes Post-It task notes which they put alongside the Story in the To Do column. By putting up a task the team are committing to deliver the outcomes within the 2 week cycle.

It’s the team who decide how much they can do, not the product owner. Sometimes this means Stories may not be achievable in the cycle, and must be de-prioritised.

Velocity

The velocity is a measure of how many tasks the team can deliver over time. After one sprint cycle we can already see how many tasks or Post-It’s the team can get through. This helps sprint planning next time so you don’t over-commit to tasks.

It’s true that not every task is the same size, but we find it averages out. We track our velocity, so we can start to see the average.

15 minute Stand Ups

We do stand ups twice a week. This is enough for us. The main attendees are the scrum master and the change team. The product owner does not have to attend the stand ups.

The standup is a briefing where each person takes it in turn to say:

  • What they completed yesterday: focus on outcomes, not activity
  • Their next actions for the day: this is about a commitment to do something
  • Any blockers they have, and how to remove them

Without real rigour it’s easy for the stand ups to drift out to 30 minutes. If they do this it’s usually because people are getting stuck into conversations around specific topics, or because they are trying to fix problems as they come up.

If you have topics that need to be discussed further the best approach is to save them for immediately after the stand up. You can try using a “parking lot” for these detail points to follow up: just write them on a sheet on the wall.

Here are a few other tips for your stand up:

  • Try not to go into detail
  • Encourage people to update their tasks before the scrum
  • Make sure you have no distractions, no phones
  • Run your stand up in open plan so others can listen in
  • Don’t forget you are here to help each other
  • Each team member should address his or her statements to the other team members, which enhances a collaborative atmosphere.

End of Sprint Review

At the end of the sprint, we show off what we have achieved. This happens on 2 levels, the Sprint Review and the wider Show and Tell.

We hold a 90 minute Sprint Review with our Product Owner to run through the outputs and improvements we have delivered. We often have demonstrations.

It’s also a good time to add any ideas and updates to the product backlog. Other key people from the project team can turn up and give feedback.

Show and Tell

We also hold a company wide Show and Tell once a month. We have several sprint teams turn up from across the project. Anyone from the business is invited. This is a more “user friendly” session, focused on communication and keeping people updated. We do this in a larger room, with each team having a stand that people can circulate between.

Retrospectives

At the end of the sprint cycle we use the Glad, Mad, Sad approach for retrospectives. We spend 15 minutes on this. It works well to do these as part of sprint planning. Everyone gets to talk.

  • Glad: what we are proud of.
  • Sad: what we want to improve on.
  • Mad: what we want to stop doing.

We also make sure we discuss and agree to top actions. We try to keep the whole thing very simple: just 10 or so post-its total.

Top Tip: we’ve found that the retrospective can fit nicely on to the start of the Sprint Planning session. It saves on meeting time, and the retrospective output has relevance to how you plan for the upcoming sprint.

In Summary

Using an Agile approach has really helped our change programme activities. It keeps things visible, helps identify blockers more quickly and improves communication. It’s a great approach to take and certainly worth adopting.

 

 

 

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *