Keeping Retrospectives Fresh

An average Scum team will do 26 retrospectives a year. Using your favourite retrospective method 26 times in a row can become boring and unproductive and eventually the marginal utility will decrease. It’s a good idea to trial different retrospective techniques to keep the team interested and fresh ideas coming.

These are three great resources for different activities that you can use at retrospectives.

http://plans-for-retrospectives.com/

http://tastycupcakes.org/category/agile/

http://retrospectivewiki.org/index.php?title=Main_Page

Note that some techniques will be better than others and like all things Agile you can stop doing the ones that don’t work and do more of the ones that do work.

Parallels between coaching elite sports teams and high performing technical teams

All Blacks coaching and leadership in elite teams

This is an excellent article on successful coaching techniques for elite teams. There are a lot of parallels between elite sports teams and highly performing technical teams. Some quotes:

As Henry stated: “Better People Make Better All Blacks, came from that meeting after that Tri-nations tour in 2004… It’s evolved, and it’s pretty good now. But … you’re always gonna get better.”

What you do shouts so loudly that I can’t hear what you’re saying.’

“The best thing about the All Blacks at the moment is that players can contribute so much. Beforehand I think it was dictated to us what our days consisted of. [Being able] to contribute… makes your work a lot easier than if you are being treated like a schoolkid being dictated to”. Byron Kelleher (All Black)

Both coaches (Hendy and Smith) emphasized the importance of transferring responsibility to the players, empowering them, expecting more ownership, and expecting accountability from them for the team’s success, both on and off the field.

Peer-ownership, peer-responsibility, them running the culture, and the environment of the team was hugely important to the success of the side. Because at the end of the day they knew they were totally responsible when they got on that field… They’d been given the responsibility. …We thought that was the best way of developing a rugby side… The more confidence you can give them in leading the team, in making decisions on the field, the better they’re gonna play. Also it makes them feel good, it’s good for their self-esteem.

So a simple way to live that day-by-day is to not spoon-feed players [as a coach]. And that might be [something simple like] not handing out a daily plan every day.” Wayne Smith, All Black Coach

About every seven weeks we would try and freshen the way we were doing things. So that might mean we would review the game differently. Or we’d change the training week… At one point the coaches all changed [roles]… At the end of 2009, I became defence and counterattack coach… Graham became line-out coach. And Steve became the attack coach… Then, in 2010 we changed again… We felt that we’d stopped improving. …It was seen as pretty radical… [one journalist] said it was like shuffling the deckchairs on the Titanic. But we had a feeling it would be good for us. Wayne Smith, All Black Coach

We also focused on increasing the enjoyment.

Turning showcases into SHOWCASES

cast

Once you have been doing Scrum for a while and the Team are comfortable with the Showcase process it’s probably time to dial up the Showcase to maximise the benefits that the Team and business get from it.

Why do we do Showcases?

It lets the business know how the Product/Team/Project/etc are progressing.

If necessary the business can use what they learn at Showcase to change the future direction.

It encourages the team to focus on getting the Stories they Committed to DONE as they know the Showcase will be a public event.

It reinforces the Scrum Values of Openness, Commitment, Courage and sometimes Sense of Humour.

Showcase allows for a celebration and recognition of the hard work of the Team.

Dialling up Showcases

So if we’re going to do Showcases for these reasons then we should do them well as we possibly can.

Get the basics right

For any Showcase to be successful you have to get the basics right. The Team should be ready to go before the booked time. If there are any AV equipment to set up they should book the venue early enough to allow for setup activities. Likewise, if they are working from a laptop, make sure that any urls are preloaded and any logins required are already completed (unless that is what you are showing). Basically they should be ready to start on time and the presentation should be as slick as possible.

The Team should know what will be covered in the Showcase before starting. This should be Showcasing every Story that got DONE in the current iteration.

Stories that are not done, or are almost done, or 99% done, should not be covered at Showcase. If the Team wanted to show these Stories at Showcase they should have gotten them DONE before the end of the Iteration. Showcase isn’t for pretty thing that we’ve been working on. It’s for showing what the Team got DONE. The only exception for this is when there is value in the business knowing about important aspects of incomplete work. If the Team decide to show work that isn’t DONE then they should be clear with the audience that the work is not DONE and why they are showing it.

Get a BIGGER venue

In one contract I moved all of my Scrum Showcases into the kitchen as it’s the largest space in our office and it has a 60 inch television. Move your Showcase into the biggest venue you have. If you don’t have a large TV then try to get a projector. In another contract I moved the Showcase to an onsite auditorium that could seat 200 people. We had eight Scrum teams from a SAFe Agile Release Train showcasing in order and out maximum audience we ever got was probably over a hundred people.

Invite EVERYONE

Make your showcases as public as possible. Invite every stakeholder related to the Stories that they Team are working on. Let the Team know who is invited. Speak to senior stakeholders and make sure they turn up occasionally. Not knowing if the CIO (or other important people) is going to randomly turn up will motivate the team to make sure they do a slick Showcase every time.

Top Tip: Don’t do this until the team have done a few Iterations together and know how to run a good Shocase. No need to humiliate a new team that is just learning the ropes.

Scrummaster tip – Make your teams stronger by doing less work for them!

Sometimes as Scrummasters we spoon-feed our teams a bit too much by doing loads of small support tasks for them. To make our teams really strong and self-organising we need to take a step back and do as few things for them as possible.

So a simple way to live that day-by-day is to not spoon-feed players [as a coach]. And that might be [something simple like] not handing out a daily plan every day.” Wayne Smith, All Black Coach

This is a list of trivial things that you might be doing that you can easily offload to the team.

  • Bringing postits and sharpies to the Planning meeting
  • Turning on the digital board before the morning standup
  • Printing and drawing the line for the Iteration Burndown chart
  • Printing Story cards form JIRA (or other Agile software)
  • Calls the countdown for Planning Poker – the Product Owner should do this
  • Orders new stationary eg postits and sharpies
  • Cleaning the board at the end of the Iteration
  • Moves the Board into the meeting room for planning
  • Filling out the Capacity Plan for the team
  • Closing the Iteration off in JIRA
  • Starting the new Iteration in JIRA

What else can you think of?

Every iteration try to think of one small thing you are still doing for the Team and let them know that they will be taking responsibility for that from now on. Slowly but surely they will take full control and responsibility for their own Agile journey

Handling risks in Agile

One of my recent BAU Scrum teams ran a fortnightly risk review meeting. The risks were prioritised according to probability and impact and tracked in a risk register spreadsheet in Excel.

If there were Stories that the Team could work on to mitigate risks, these were added to JIRA. The Stories in JIRA and the risks in the risk register were linked.

The importance of the risks became part of the business value that the Product Owner considered when he prioritised Stories for each sprint.

When the stories were DONE in a given iteration, both JIRA and the risk register was updated.

Planning new Stories part way through an Iteration

Sometimes an iteration will get off to a brilliant start and it will become obvious that the Team will finish the planned Stories well before the iteration is finished. When this happens it is important to make sure that any new Stories that are planned in are planned properly.

When planning in new Stories consider the following:

Do

  • Make sure that the Team agree that ALL of the original planned Stories will get DONE.
  • Book an interim-planning meeting with ALL of the Team and the Product Owner to plan in the new Story(s).
  • Make sure that any new Stories are fully written and go through the same planning rigour as any Story planned in at the beginning of an Iteration.
  • Even if a Story is written and estimated it is important to review the Story as you would at any planning session to make sure the details, conditions of satisfaction and estimate are still accurate.
  • The Team must COMMIT to getting the Stories new DONE just like in any other planning session.
  • The new Story(s) become part of the Teams commitment for the Iteration and are included in any post Iteration metrics. If a new Story doesn’t get DONE don’t be tempted to wipe it from the records as it “wasn’t part of the original plan anyway”.
  • Review why the original plan wasn’t accurate at the Team Retrospective.

Don’t

  • Don’t pull work that the team cannot get DONE according to their Definition of DONE
  • Don’t just pull the next highest priority Stories off the backlog
  • Don’t plan in the new work at Standup
  • Don’t let the Product Owner make the decision for the Team
  • Don’t use previously written Stories without the Team fully reviewing them and confirming estimates

Why having extra capacity part way through an Iteration isn’t always great.

It might seem like a good thing to have a load of extra capacity part way through an Iteration but underplanning an iteration is still a failure to estimate and plan accurately. Also planning in new Stories part way through an iteration is less efficient than planning the same Stories the beginning so there is an impact on Velocity.

Retrospective

At the Retrospective ask why they original plan was underestimated. Understanding why we weren’t accurate will help is plan the correct amount of stories in future iterations.