Recently, I attended an Adaptive Path conference called Managing Experience.It was brilliant, and here’s a writeup if you want to know more about that.
I was lucky to spend a bunch of time with Todd Wilkins in a workshop about IBM’s Design Thinking Framework.
There’s lots to like, but in particular, two out of three principles resonated strongly.
- Hills (instead of epics/features/stories)
- Playbacks (instead of showcases)
They’re similar to epics/features and showcases, but different, in important ways.
Here are two provocative generalisation:
- Teams often get blinded by features to build instead of problems to solve.
- Stakeholders get bored at showcases because giving a demo of a completed feature is largely not very exciting.
Hills and Playbacks try to solve those two problems, with an added side-benefit of helping to focus and empower teams to solve problems (instead of build features).
Sounds pretty good, right?
So what’s a Hill? and, what’s a Playback?
First, read the short version of the IBM Design Thinking Framework.
Here’s that link again.
A Hill is simply a way of framing the intended outcome of the work being carried out, from the point-of-view of the user and/or business stakeholder.
Experience designers would recognise these as design challenges, where the phrase “how might we…” is often used to start exploring ways of solving the challenge.
A Playback is a demonstration of the outcome, generally told as narrative, from the point-of-view of the person who’s problem is being solved (which is typically the ‘customer’ and ‘the business’ simultaneously)
How doe’s this empower teams, exactly?
Well, alone, Hills and Playbacks won’t do that – after all, it’s only slightly different language and metaphor to what we’re used to from agile development practices.
But with the right team culture, and some other guidelines (e.g. what number of hills for a given project?), framing the work this way allows freedom to act, because teams are empowered to create an outcome, not just build the next feature in the list. It’s inherently more collaborative too, because challenges are less likely to be ‘pre-solved’ by another team (analysts, designers… whomever) .
In essence, Hills describe The Commander’s Intent*
For the purposes of this discussion, that basically means, setting a shared direction/vision, then leaving capable, well trained professionals to execute the solution.
*I like the Harvard Business Review description from the article above:
“The key to successful Commander’s/CEO Intent is trained, confident, and engaged military personnel/employees. Employees must understand the plan and when they have to deviate to ensure the Commander’s Intent is accomplished. Military personnel have to employ a “Spectrum of Improvisation” when they execute Commander’s Intent.”
A final note
Yes. I know the differences here are pretty nuanced.
I can hear your inner monologue too: ‘We already do that’… (If so, then great!)
Reflecting upon my entire professional experience, it’s not something I’ve seen often, if ever.
I think there’s lots of potential, and I’m looking forward to road-testing it on a project soon.