Agile Futurespective
Agile Futurespective
Long-lived Scrum teams very often meet with the situation when they resolve all problems that they can. In this case, the team could be frustrated about the usefulness of Sprint Retrospectives because these don’t help and just waste time.
When you have this challenge, you could try Futurespective instead of the Retrospective.
In Retrospective, you see back in past and try to understand what we can do better. Bun in Futurespective you see forward in the future and think about what you want to achieve in the effectiveness and quality of your work. It is a different perspective and it could uncover your team’s hidden potential.
Today I’ll give you a common plan for most Futurespectives and several Futurespective formats which I like
The common steps to conduct an Agile Futurespective are:
- Meeting check-in
- Presenting the new format of Sprint Retrospective
- Gathering data
- Deciding what we want to improve
- Improvements goal setting
- Making an improvement plan
Let’s consider all steps in detail
1. Meeting check-in
Usually, meeting check-in is quite similar to a simple Retrospective. You just have to ensure that every team member is willing to participate actively in the meeting. You could use almost any Retrospective check-in, for example, from here.
2. Presenting the new format of Sprint Retrospective
This a very important step when you start any new Retrospective format with your team. You have to explain why you decide to use this format, what profit the team will get and what participants will do during the session. There is no rocket science, but many Scrum Masters forget to tell why he/she bring this new format and the team may have skepticism or even resistance against the new format.
3. Gathering data
Here are starting main differences in conducting Futurespective.
By and large, there are only two kinds of Futurespectives:
3.1. Any type of team assessments
3.2. Just free fantasy about the future
3.1. Futurespective by assessment
There any many variants of Agile team assessments. Here are just 5 examples that I like
You could collect data before Futurespective or directly during it. If you have enough time at the session it is better to gather data during it because you can explain some unclear questions and it will be guaranteed every team member participates in the survey. In case when you need to do some analyses after the survey of course you have to gather data before Futurespectivet.
3.2. Just free fantasy about the future
Actually, you can use any idea-generation technique, but for a fast start and structuring ideas, you may use one of the Futurespective formats. I use this type of Futurespective usually before Christmas:
- Team members write wishes about the work context. I ask them to imagine everything is possible. After that, they stick their wishes under the Christmas tree.
- And at the Retrospective after Christmas team think about how to get closer to wish fulfillment.
4. Deciding what we want to improve
When you get some data, the team has to decide what they what to improve for now. You could use any method of team decision-making: dot voting, consent, etc.
You could ask why not choose the worst metric from data gathering. Because it is not always the most terrible thing that could be resolved by the team. But you as a Scrum Master of course have to notice that and ask the team do they need help with this from management or someone else.
The team could choose 1–3 topics to improve. It is about focus because if you have a few things to improve, you will succeed faster.
5. Improvements goal setting
When have chosen what to improve you need to set goals about it. I like to make global goals for the year and mid-time goals for the quarter. Of course, you should do this with the team, precisely, you should help the team to do this by themselves. I love to use Improvement Theme Toyota Kata for goal setting. It also includes the next step of Futurespective (Making an improvement plan).
Here
Team Definition of awesome is the year’s goal,
Near targets are the quarter’s goals,
Next steps are the plans for the next Sprint.
Team selected three improvement areas: easy to release, quality, and health of codebase. And they set three year’s goals also — one goal per every area.
You can read more about Improvement Theme Toyota Kata in Jimmy Janlén’s article.
6. Making an improvement plan
Very many amateur teams forget this step and it is becoming the main reason that team starts to think that Retrospectives are useless, because “we only talk, but do nothing”.
For success you have to create a plan where every item has these four things:
- What to do — starts from the verb
- Who will do this — here may be only volunteer from those present at the meeting
- When it will be done — sometimes you may skip it if the action will be done before the end of the Sprint
- How to check it — if “What to do” is quite abstract you have to write some acceptance criteria. For example, “Text and examples will be prepared at the end of the next Sprint”
* Names of responsible persons are covered up here
After the Futurespective
The best practice is to add the Next steps to your next Sprint Backlog. It helps to not forget it during a rash of the Sprint.s
And, of course, you must review the planned Next steps at the start of the next Retrospective like the next steps from any other Retrospective. You have to ask the team:
- Was every next step done?
- Why it wasn’t done? (if “No”)
- Did it bring us closer to the Near target? (if “Yes”)
- What we should do next to achieve the Near targets?
Conclusion (of the article)
I hope it was helpful to you.
In a nutshell, Futurespective is not so different from basic Retrospective. You should just use some special practices and tools and, of course, stop thinking that Retrospective is only about solving the problems 😉
