What do I blog about?
Error: Twitter did not respond. Please wait a few minutes and refresh this page.
somethings are just inevitable …
This is a guest post by Cara Turner – Thanks Cara!
This exercise came from the “Gamestorming” book, and is useful for identifying the issues and concerns surrounding a project that generally stay in the back of people’s minds until they become real problems (the proverbial “Elephants in the Room”). The method followed is also known as “Remember the Future” (thanks Karen Greaves) – which you can find out more about here: Remember the Future and Remember The Future @ Munich Scrum Gathering.
I recently tried it with a team who were about to start a focused performance enhancement sprint on their product, where there was a lot of pressure on the team, and a lot of concern about whether this sprint would resolve the problems with the product.
We did this exercise in the Sprint Retrospective, and I introduced it as a slightly different retrospective activity, looking backward as if we were already in the future, imagining that we’ve come to the end of the project, and it had all gone horribly wrong – it’s become one of those projects no-one wants to be on or talk about except to say “ooh, at least it’s not the (x) project”.
Usually at the end of one of these projects, there is a ‘Lessons Learned’ exercise, which lists the things that went wrong – and usually, there are a bunch of people saying “I said that would happen – but nobody listened”. (And, as Lyssa Adkins points out, usually nothing is really learnt from a ‘Lessons Learned’ exercise).
So this is a chance to listen at the start of the story, and get those opinions and fears out early when they can add value to the planning, instead of going down the predictable-failure route.
To make sure that we kept the value of the exercise without changing the format into an impersonal spreadsheet that no-one ever looks at, I modified the Impediment Backlog concept to cater for things that could go wrong but haven’t yet, and stuck the issues & their correlated actions onto this.
Thought: since this was part of a retrospective, we first did a Check-in exercise reviewing the previous sprint – I recommend some kind of check-in to get the team’s focus in the room before launching into this, as it requires a lot of imagining…
Introduction to the team:
This is a slightly different retrospective activity, that looks forward not back, but as if we’re looking backward. We’re going to pretend we’ve come to the end of the next sprint, and it’s been a miserable failure – everything that could have gone wrong did.
At this point the team flinched a bit – I had to emphasise that the idea is to find out what went wrong, so not to focus on the feeling so much as the causes.
Then the team reviewed the upcoming stories, asking the questions: What could possibly go wrong ?
(at the start of a release, you’d probably be looking at the story map, rather than stories).
Ask the team to think of a “What If” question – something that could go wrong. Explain that they’re not going to resolve the issue now, just thinking up questions.
Since these questions are generally going around in people’s minds anyway, but only spoken between friends in informal setting, it really helps to give an example question here – kind of opens the flow for the team.
Taking it in turns around the room, each person asks a What If question.
for example: What if: the client can’t access the new UAT environment?
Hint: Don’t write down these suggestions: In the session I wrote them down as the team spoke, but this just dried up the flow of ideas for the next phase, as they started reading and thinking about the existing questions. When I wiped the board clean and asked them instead to write their suggestions onto the squared paper, they were off like a shot.
Building on the “What If” questions, each person has 7 minutes to write down three or more things that could go wrong in this sprint (as many as they can think of, no less than three).
Prompting questions: (I read through this twice, first at the start & then when ideas dried up a bit)
I encouraged the team to think as widely as possible, and to write down the silly and highly improbable things as well as their current genuine concerns.
Stick each note on the white board, and then group into categories / themes.
Add a large orange dot to the categories that the team has no control over. Move these to the side of the board, to look at separately.
Where we weren’t sure, we added a question mark on the dots, and also addressed these under actions.
Per category group, we asked the following questions:
For each item outside the team’s control:
It’s up to the Scrum Master or Product Owner to make sure these issues are raised in the appropriate forum.
Discuss each group & write at least one action for each on a sticky, and post it up with the groups.
Hint: we wrote the actions onto the board next to each group, but then found that we needed the action separately when we added them to the impediment backlog. I’m coming to love stickies more and more for their reusability!
Once we had a response in place for all items raised, we needed to identify which ones were of highest priority to the team. Here I asked the team to vote for items that were:
Each person had 4 red dots to vote; which could all be used on one category, or as they liked over the different categories.
At the time I didn’t have a home for these issues in the team room, but didn’t want to lose track of them either, so a couple of days and some research later I drew up a modified Impediment Backlog with the statuses:
– CURRENT Impediments – these are affecting us right now (and SM must action)
– POTENTIAL Impediments – ranked according to their likelihood of occurring as indicated by the team (you could also rank this according to priority)
and added the issue & it’s action to the product backlog.
What I found interesting was that some of the issues with multiple red dots (high concern to the team) had a low likelihood of occurring; and of them only two were considered significant enough to schedule their actions into future sprints; but the team is comfortable that if any of the others do occur, they know how they will respond.
Also since this was a retrospective, some of the issues didn’t make it to the board, as some retrospective feedback will always remain private – although I suspect this may also be the case in normal workshop format too.
We review the Impediment Backlog as part of the Daily Standup, removing items that have been resolved, moving ‘potential’ to ‘Current’ if it becomes a real impediment affecting sprint work, and adding new ones.
The Impediment Backlog is a new tool in the organisation, so I think it will take a while before it’s working in the way I’d like to see – a resting place for the team’s unspoken concerns, and an indicator that all stakeholders can access, giving them a better context to understand the issues impacting the success of the product / release / project.