There’s a scene in the Wire where some sturdy Baltimore cops are trying to move a desk, only to realise that the guys on one side thought it was supposed to move into the the room while the others tried moving it out of the room. It’s funny because we’ve all been there; doing our best to achieve the wrong purpose.
The problem is all too common in software development, where the intangible nature of the artefact you build, makes it harder than ever to make sure everyone in the team are singing from the same song sheet.
The default solution used to be to write a specification–a spec–detailing every nut and bolt in the imagined solution, have developers sign off on it, and then let them loose.
This is similar to how physical structures was once built. A master builder was trusted to keep all the details in his minds eye, and instruct the craftsmen of different disciplines on the fly. The European cathedrals of the middle ages marks the grandiose pinnacle of this paradigm.
Houses aren’t built that way any longer, just as it’s rare to come across a software project that is organised around blindly implementing a spec. Things just got too complex for that mode to work; no one person can be expected to grasp the whole and the sum of all the details at once.
And also, with software, it’s simply not feasible to know exactly where you want to end up when you set out.
While there might be exceptions to this rule, most notably in slow moving and highly regulated environments where security and robustness must always be the priority, most software projects exists in a volatile dynamic world where the need of users are in constant flux.
That means you can’t afford to lock your missiles and start implementing a spec which, no matter how good it is as the ink is drying, can never predict where the market will be once all the development work is done.
The importance of being able to respond quickly to changing requirements was the main impetus behind extreme programming. XP is a comprehensive methodology for how to remain agile while building large scale corporate IT systems where the customer don’t exactly know what they want until they see it.
Where before, best practice had been to design future proof systems optimised for extendability, XP evangelise to think in terms of the simplest possible solution that will work now, even at the cost of remaining flexible enough to be able to serve the users of tomorrow.
XP gave rise to agile, and both methodologies favour user stories over specifications.
Framing how people are expected to interact with your product in order to achieve some change in their world in terms of stories, makes a lot of sense of course. I check the wether to decide my mode of transportation; I take an online course to level up my expertise without having to quit my day job. These are example of stories.
Stories shine when it comes to smoking out ambiguities in what people really want your software to accomplish. They’re also great for clustering your to do-items into a backlog that can be prioritised and sliced into short development sprints with concrete output that brings value to the users.
What stories won’t give you, at least not out of the box, is a framework for having high quality conversations about why you build what you build in the first place.
Which for most of the teams I know is *crucial*.
Because they’re not consultants, they don’t have a customer to give them a set of requirements, however vague.
Instead they have a hunch that a certain piece of technology can somehow be put to good use in the world, but they’re not sure what end to start in, let alone who “the user” might be.
Teams like this can follow the tenants of XP and agile to the letter, and still end up building the wrong product. Teams like this need tools on a whole different level. Entire problem spaces need to be explored, before discrete problems are picked out to be solved.
That’s where I see story mapping coming into the picture, as an exploratory design tool rather than a discipline for agile development.
Story mapping isn’t hard to grasp. It has a horizontal dimension that walks through each step a certain user takes in interacting with a system (=product=service). Let’s think of this as the yellow axis, since most commonly each of the steps will be represented by a post-it note.
Even for the simplest of systems, there will be multiple yellow rows. They typically represent different types of users, each with their own agenda on how to achieve change in their world. Even just with one type of user though, there will be many different ways to interact with the system. (Using a map application to plan a road trip through Europe is going to look radically different from using it to find the nearest veterinarian.)
The second dimension, let’s make it blue, is a vertical one. This is where the implementation options of the yellow note are plotted out. If “creating an account” is on the yellow axis, possible blue notes on the vertical axis could include “create profile by connecting Google account” or “ “team creates account for user by accessing the database directly”.
The blue columns allow for decisions on where to be quick and dirty, while the yellow lines facilitates a higher level conversation on what to build and for whom.
Because ultimately, those are the questions you need to get right. And it’s not like they’ll ever be clarified once and for all. The laws of evolution apply for built systems as harshly as they do for biological ones; stop moving and you’re dead in the water.