filtercake

home  |  stuff I made  |  talks  |  try out all the things  |  meet  |  feed

Dimensional Planning of Software Features

http://www.amazon.de/101-Things-Learned-Architecture-School/dp/0262062666/

We recently had an internal workshop on user stories, which I am using as the basis for an info poster. While we were handed lots of possible ways to split user stories into smaller ones, I want something linear for the poster which will lead to helpful results from the beginning.

While our team was working on the new Jimdo shipping costs during the past months, one particular thing bothered me all the time:

How could we apply the concept of Hierarchical Drawing to our work on the feature?

And if you wonder what "hierarchical drawing" means, here is the related excerpt from 101 Things I Learned In Architecture School:

But we build software, right? Turns out there is an equivalent concept for development: "Dimensional Planning". Sadly, very little about it can be found online:

But Arne pointed me to a german article in Agile Review, a magazine it-agile makes for its clients. Following are some notes from "Dimensional Planning" by Stefan Roock, Agile Review 01/2013. [Personal comments by myself are in italic brackets.]


Advantages of small user stories

  • easier to develop shared vision
  • more precise planning
  • more smaller stories ease team organization
  • make smaller releases possible
  • smaller feedback cycles lead to faster learning (and thus a competitive advantage)

The road metaphor

  • dirt
  • cobblestone
  • asphalt
  • highway

[I really like the road metaphor. An important aspect of software is to enable the user to get a job done. Within the metaphor, the user wants to get from point A to point B.]

Example: invoicing.

The levels:

  • Dirt road: Paste SQL query template, paste result into word template. [Note no UI at all. Just a database and a manual workflow to get from A to B.]
  • Cobblestone: Start automation, eg make complete invoice from data. Just the legal basics, no options (eg no private persons, no discounts, etc). [Basic, unstyled interface to see if the right elements are used].
  • Asphalt: The state of today with all expected features (including persons, discounts, individual VAT per item, asf). [Looking good]
  • Highway: state of the art, exceed expectations, build USPs (eg custom layouts, import, export, APIs to external services, etc).

Iterations and releases

Doing release cycles this ways additionally offers:

  • getting feedback on value very quickly
  • "walking skeleton": put on meat, muscles, skin, etc later, when you're sure the skeleton is actually complete and can use arms, legs and head.

Not a silver bullet

Not everything is a nail just because you bought a new hammer. Accordingly, Dimensional Planning is not by design the best method for everything. It might help in these scenarios:

  • a complete but low-quality version helps to answer questions and assess risks
  • a complete but low-quality version can be used by a small niche group of users
  • there is no (or no better) strategy yet to split work incrementally

So far for the article.

I am a bit puzzled that this model is spread so rarely in software development. Sure, there is also "Lean Startup" and stuff. But I find it increasingly annoying to have to dig through whole books/frameworks/programs to find the bits and pieces which work. I'm not looking to buy into a belief system.

"Hierarchical Drawing" is one of the first things you learn in art school. It is the only way to achieve a consistent page – maybe unless you have many many years of experience. But even then it doesn't usually make sense to not work hierarchical. After doing the first rough lines to divide the basic composition, it is easy to start from scratch if necessary. But throwing away stuff or redoing areas of a painting becomes more costly with every detail added. And I be damned if that is not one of the main problems in all software development I have taken part so far.

Up next: adding this to the poster...