A s h l e y T e r n e s

We’ve been running (semi) regular futurespectives as a way of taking hard earned experience and turning it into positive action for the future.

I think that one of the hall-marks of a “Good” place to work is a sense that you are making a difference, and that people are genuinely working to make things better. This kind of attitude is very hard to maintain, especially in a corporate environment, and especially in the financial services industry. As much as I respect the need for governance, stability and predictability these corporate goals often seem to run counter to innovation, creativity and empowerment in the workplace. I believe that Agile techniques are most readily adopted by people who value these things more highly than conformity and standardisation of process. But what has this got to do with futurespectives (I’ve seen it spelled “future-spective” as well)?

Most people who have participated in an Agile project are familiar with retrospectives. These are usually run at the end of each iteration and, although they take various formats, are generally focused on a theme like “What went well, what didn’t go so well, and what puzzles or blocked us”. This constant looking back is a crucial tool for driving constant improvement.

The first futurespective I participated in was run just like a retrospective but as if the group was 6 months into the future. We imagined what went well etc. Honestly, I found this to be a little esoteric and I noticed that the folk in the group who were new to Agile actually had a hard time staying “in character”. Since then I’ve used a less subtle approach that focuses on fixing problems (or pain points) and entrenching more of the “good” practices. The main material difference between this and a retro is that we’ve used it to focus on long-tail problems – the kinds of things that need more steady work or buy in from other parts of the organisation. Examples are reducing build cycle times, and increasing the amount of automation testing in the organisation. Now, I’ll take it one step further and propose the following questions as the foundation of a futurespective:

• What will we do more of in the future?
• What will we do less of in the future?
• What are the things we’re not sure about and will monitor going forward?

Okay, now it’s my turn to be a little esoteric. I’d suggest that on the face of it, the only real difference between this and a current retrospective is the tense in the questions – driving towards the future. Thinking about it a little more however, I’d suggest that this is an important shift. We do a lot of looking back, measuring, and using “yesterday’s weather” in software development but I think that there is value in institutionalizing a more forward thinking viewpoint. This has a psychological effect that shouldn’t be underestimated and I think we’re seeing benefits. Skeptics and evangelists alike become involved in solutions instead of being part of the problem. This is a significant step towards making your project or department one of those places people like to work.

In your futurespective, ask those same questions, and still decide as a group which topics are the most important, but focus more on what you will do about it or change than what went wrong. This means you run less risk of playing blame games and spend more time getting on with things. I call this optimistic analysis and it is proving effective.