Future-spectives

 

The concept of retrospectives is well established in the agile community as the way to incrementally improve your processes and the way the team members collaborate during their work. The idea is that by regularly looking back at the past period you may find improvement that will increase the productivity and delivered value.

This concept can also be used in other contexts, for example during a project kick-off at the start of a new project and team. To get the team on track and up to speed quickly it is important that the forming process starts out nicely and that the team learns how to collaborate and get focus on their work. Iterative processes with short iteration lengths helps out here in that the team needs to get focused in order to have a successful delivery after the first iteration. But you can also help out by establishing a common goal and vision for the team immediately at the start of the project. This common goal could help the team establish better collaboration and communication patterns as well as good process and engineering practices from start that will kick-start the project. And to establish that goal you could run a retrospective from the future, a future-spective.

In a future-spective you imagine that you are in the future, for example at the end of the project, and that you are performing a project retrospective to find out what contributed to the successful delivery of the project. I have used this concept a few times with very good results. Future-spectives help us establish practices and collaboration patterns early on that move the team from a group of individuals to a real team faster than otherwise.

The agenda of a future-spective is like an ordinary retrospective with the options that you start out by moving the team into the future. I have had the following steps during my future-spectives:

1. Check-in
2. Explanation of the exercise, its purpose and goal
3. Moving to the future
4. Brainstorming
5. Moving back to present time
6. Check-out

Check-in

It is important that all participants get focused and inspired by the upcoming future-spective. If the members feel like they are in the future the exercise may release a high level of creativity. But this is not easy if they all have a lot of other things on their minds. Therefore, it helps out to run a check-in to make sure all participants have said something and cleared the air before continuing.

Explanation of the exercise, its purpose and goal

Explain to the participants the purpose and goal of the exercise, describe the agenda and the different steps in it so that they all understand and know what’s expected from them. Depending on how much time you have you may be able to work out activities based on the findings of the future-spective. It is best if the team can leave the meeting with a few activities that they will implement immediately. But if you are short on time you need to do that in a follow-up meeting instead.

Moving to the future

Once you have got a shared understanding of the purpose and goal, start the journey to the future. Do that by describing where you are and what the team has achieved at that point of time.

For example, I had a case where I started up a team with the purpose of refactoring a set of problematic tests. The system under test was quite large and our test runs took up to two weeks in total to finalize. We had our fair share of both good and bad tests, and some of them were catastrophic; they took really long time to run, were mostly manual, were dependent on subject matter experts as well as really expensive to maintain. The team was formed to address this with the clear goal to radical decrease the execution time and to improve the quality. The team also had a secondary goal of bridging the cultural gap between the test and coders disciplines as well as knowledge transfer between them.

I described the future where we had just delivered our last test implementation and we were about to run a project retrospective in order to find out what it was that made us so successful. The organization and our co-workers gave us a standing ovation during our last sprint review where we summarized our achievements. We had decreased the execution time 90% and also eliminated our dependence on experts by automating all tests that were previously manual. We had also exceeded our secondary goal of bridging the cultural gap between testers and coders and all members were now able to easily take on either role. The organization demanded to know our secret in order to be able to implement it site wide.

It helps to present this positive picture of the future a bit theatrical. The participants should feel proud of their achievement and get into the mood they would have been in had they met their goal.

Once you have moved to the future you perform an ordinary brainstorming session to help you determine how to meet your goal. In my case above the team brainstormed around the question “what was it that made us so successful?”.

On that occasion among the success factors we uncovered were the following:

 

• We have a responsive, forgiving and positive culture in the team
• Close collaboration
• Short focused sprint with a small and effective team
• Practices like feature kick-off, READY and DONE criteria and effective planning
• Test driven development
• No interference from the outside
• Collaboration across the disciplinary boundaries
• Common and shared goal
• We had fun

As can be seen the team worked out success factors that were both soft and hard, processes and collaboration oriented. From this list you can work with the team to exemplify and detail what they mean with a responsive and forgiving culture, for example. You can do that by letting the team establish a common working agreement stating how they should treat each other.

Moving back to present time

When the brainstorming session is over it’s time to move the team back to the present time. You can have the team reflect a bit about the success factors in order to establish a common understanding of them. You can also work with the team to generate a positive common goal described by the success factors, a goal of what they will try to achieve both technically and collaboratively.

Depending on how much time you have you could continue to work on the brainstormed material, for example prioritize among the listed success factors. The team can select the top three to brainstorm what the team needs to do to implement the success factor in the upcoming project. If you’re out of time you explain that the team will continue to work on the success factors in a follow-up meeting.

End the session with a check-out. For example have a short retrospective of the meeting in order to get some improvements for the next time you run it.

I have found this exercise to be a really good way of kick-starting a team just about to form in a new project. You help the team find success factors that they can implement immediately. You also make sure that all members have the opportunity to express their belief and desire at the start. In that way the team will benefit from everybody’s previous experience and you as a scrum master or team lead have the opportunity to learn what the common ground is and potential gaps between the team members. But even more than a list of success factors, this exercise helps you build the team. The exercise lets the team members together generate a shared goal of how they should collaborate together. It is quite powerful to have that ground early on in the project, and you can use it in exercises thereafter in order to continue forming the team.