Over the years we've distilled our process into a set of three interlocking practices for management, exploration, and delivery. Or to put it another way what do we want to achieve, what do we need to learn, and how do we make it a reality?
We like to create a separate track for management which provides everything needed to direct and monitor a project without getting buried in needless details.
In practise this means we'll share lightweight docs encapsulating the problem to be solved, the solution or options we're proposing, where we stand in the process, and any next steps.
On larger projects we'll create mini-specs for each of the key features on the roadmap (think of these like a high level backlog) which allows management to make informed strategic decisions about which horses they want to back. This can be especially helpful when time or budget are limited.
Once we've pinpointed a problem to tackle, and received approval through the management track, it's full steam ahead on exploration of the problem space.
Be it paper sketches, wireframes, prototypes, or code, it's important for us to choose the right level of abstraction as we explore possible solutions to the problem at hand.
At this stage we repeatedly ask ourselves the following questions to guide our iterations:
- What's the next thing we need to learn?
- What's working and what's not working?
- Where are we against our schedule?
This stage moves in harmony with delivery, letting us continually learn about the domain, the problem, and the solutions we're creating.
This is the bit we love, when the tyre meets the road, and we get to put our work in front of the people it's going to benefit.
We tend to work in 2 to 6 week cycles depending on the task at hand and strive to ensure that each completed sprint meaningfully moves the project forward.
Progress gets fed back into the management track and user feedback informs the next round of exploration. Then we repeat each of the practices until everything is delivered.