I first started writing this post at the beginning of 2015. It languished in my Drafts until today when I reread what had been written and thought it was worth publishing anyway, even if a year later than intended.

…

The Fall of 2014 was madness on the personal and professional fronts but this material is still relevant and I wanted to share with those who stumble upon it.

I had the honour and pleasure of speaking at UX Thursday Toronto — co-hosted by User Interface Engineering and Vitamin T — on November 20, 2014, alongside a number of friends, both new and old, in the design community. These included: Jared Spool, Ilona Posner, Desiree Sy, Matt Nish-Lapidus, Andrea Ong Pietkiewicz, Robert Barlow-Busch and Derek Featherstone. You can find a number of the talks on Slideshare by searching on the tag uxt-toronto or by searching on each person.

In my talk on Lessons from Labyrinth: Designing in the World of Enterprise, I shared a case study that highlighted a number of forces at play on a particular project within my work sphere and how the design team found ways to help the larger project team navigate them and do some serious team learning in the process. This blog shares one of the forces covered in that talk — having multiple project missions — and our use of backcasting to help a team effectively respond to that force.

Take a second to consider this picture. What do you think it’s about?

It’s a picture of a 12 person collaborative session — 2 in room, 10 on phone in different geographic locations. My design colleague is making virtual stickies on a virtual wall — Adobe Illustrator in this case — and sharing with the other participants in a web conference. The participants on the phone are being prompted to respond to questions I pose. I write a brief synthesized version of answers on stickies and pass to my colleague so she can type in quickly and share in real time.

Why are we doing this?
Because IBM is a big place, and it can be hard to get things done. If we want to collaborate in an interactive way with our fellow team members across cities and countries, we have to be rather inventive in how we do that — we have to create hacks to address the distributed team challenge. In this case it is a simulated wall and simulated stickies for a particular activity that was a full day in length.

Let’s zoom out a bit …
Every project in my world of software development has a history and a context, and at any given point in time there are myriad forces acting on it. These forces can fundamentally shift or destabilize a project. They can also be welcome opportunities to experiment with different ways of adapting to changing conditions, and through those adaptations learn and co-evolve as a team. We embraced the latter perspective and led the team through collaborative methods that deepened understanding among team members and clarified direction.

The first and most significant force at play was the challenge of establishing the initial scope and mission.

The project team had two missions: One mission, represented on the left side of the image above, was that it be an Integration Hub providing a centralized place to bring together data from heterogeneous sources into integrated views. An example of this in software development might be that two development teams working within an organization use different tools to manage and track their bugs, such as Atlassian’s JIRA and IBM’s Rational Team Concert. The integration hub would provide views into the content of both tracking records and allow for awareness and insight across both from a central place.

The second mission, represented schematically on the right side of the image above, was that the project team provide Independent Capabilities based on the same capabilities or services that would be part of the integration hub. In the independent capabilities mission, the capabilities would be combined in ways that couldn’t necessarily be anticipated because they would be used in other products to augment the functionality of those contexts. An example of this in software development might be that a team is already using source code and build capabilities but they want to add deploy so they can quickly put their work into production and test with their intended audience — all in one integrated workflow. The deploy capability would be added on to the team’s existing tools without having necessarily been designed for that particular context.

Having two missions, while complementary, was a tall order and the project team had a lot of enthusiasm and ideas. They needed to figure out what the overall vision was, how they might get there, and what the scope was to be in the near term so they would not try to do everything at once.

Having been inspired through conversations with Matt Nish-Lapidus and Matthew Milan of Normative in Toronto to try a foresight tool called Backcasting, I undertook creating a version of it for the project team to do remotely across four geographic locations. This is the activity we were doing in the image shown at the beginning.

To give you a brief primer, Backcasting follows this set of collaborative steps:

1. Pick your future point in time, e.g., say, 3 years out from today
2. Lay down the timeline working backward
3. Understand present state, including both things that work and don’t work
4. Define future states – what does success look like?
5. Give each state, or ‘range’, a name, e.g., the Triple Scoop Cup, the Soft Swirl, and the Ice Cream Sandwich
6. Pick one of the future ranges
7. Reverse engineer how to get there by defining: Actions, Indicators, Risks and Opportunities
8. Establish an action plan starting with what you are going to do tomorrow

The following image — albeit tiny and blurred because it contains proprietary information — shows the output of the remote collaborative session I showed at beginning and that of a second follow on session we did when the team was able to meet face to face at a conference.

We completed the visioning activity around the overall desired future range and backcasted one of the primary services. While it would have been great to backcast the complete picture, the tool and group activity was worth its weight in gold for helping team members understand one another and to get alignment on the scope for the most pressing areas of the project.

It was definitely worth the experiment of using an unfamiliar but promising tool and trying it in both remote and in-person contexts.

…

(If you want to learn more about backcasting, check out Matthew Milan and Sam Ladner’s presentation on Backcasting, or how I learned to stop predicting and help my clients at the IA Summit 2007 and Matthew’s Backcasting 101 presentation at the IA Summit 2008.)