The last years, I noticed that I explain dimensional planning more and more.
I learned about dimension planning from Koen van Exem, one of the early Belgium agilists.
It’s one of these early germs of (Belgium?) agility, that unfortunetly has been mostly forgotten.
Last night JB (Rainsberger), Alistair (Cockburn) and myself had a small discussion about it, that made me realise that I still have a nice story that I had not shared on my blog yet.
Before I do that, let me explain the basics of Dimensional planning.
The idea of dimensional planning, is that we slice our stories in different implementation dimensions.
We do this because as JB says, a lot of clients want a Lexus by the end of the week. We might not be able to do this, yet we might be able to offer them a toyota by tomorrow, most clients love this offer till we can deliver the Lexus. (Aka very fast ROI)
I prefer the dimensional planning theory like Koen explained it to me.
Imagine you have a client that wants a highway between Amsterdam and Heusden.
You are good at making highways, so you start building right away. After a few months you are ready and you proudly let your customer use the highway. She arrives at Heusden and she does not have a happy smile on her face. You go over and ask about the gas stations and and if she liked the picknick area’s and the exits every 20 miles ect etc. Although she answers positive on all your questions she seemed to get annoyed more and more. And finally she burst out: this is not the city I wanted to get to.
You look around and notice the city sign: Heusden. Did she not want to go to Heusden? Yes she did.
Turns out there are two cities of Heusden.
After this your company and the client lawyers have long and large discussions about who’s fault it is and who will pay of the not useful highway.(If you have a good lawyer, your client will pay and then never come back…)
You could also use dimensional planning. When you do, you start by building a dirt road between Amsterdam and Heusden.
After less then a week that would have been finished and you would have discovered that you are going to to the wrong city. You say no problem, we both knew up front we would encounter misunderstandings. You look around, find the new Heusden and build another dirt road. You deliver that one after another week and wow, you discover together with your client that even that is the wrong one. Turns out there are 2 cities in Belgium and 1 in the Netherlands that are called Heusden. Who knew?
After another week, your client is happy that she has a dirt road between Amsterdam and her Heusden. (A lot faster then the original few months.)
Although she does not have all the features yet, she has already return of her investment as she can start sending cars between the two offices of her company. It’s not a great road, it goes rather slow, yet a lot faster then the previous road that had a detour of 100 km.
The day after you delivered the correct dirt road, you started working on a cobblestone road.
After another 3 weeks, you deliver that one.
You can also create a tarmac or asphalt version and a highway version.
Yet in a lot of cases the clients don’t want to highway version another more when they already have the ROI of the previous versions.
Because we all know that when we ask a customer if they want a highway they always say yes, and developers love working on all the features of a highway.
Yet going back to the car example as JB said so nicely yesterday, most people would prefer a Lexus over a toyota, except if they need to pay for the Lexus, suddenly a toyota (or even a lada -Thx Rik D’huyvetters *2-) is enough. Just like not every developer likes to pay constant attention to all details the way a Lexus demands.
Reader: Well Yves, isn’t it pricy to deliver 3 dirt roads, a cobblestone road, a tarmac and a highway?
Yes it is more pricy then just a highway, yet as we all know errors are made and delivering all that is cheaper then delivering 3 highways, as we almost always seem to do in product development.
Reader: Oh but in my methodology, we prepare so much that we never make mistakes…
If you are sure and you take that risk, be my guest. Even if you are correct (which I doubt will happen in 100% of the cases) I’m pretty sure that by the time you have started creating your highway, a lot of customers have already changed their minds. And our dirt road projects are delivering ROI already after just a few weeks, months before you even have started.
Reader: All nice theory Yves: how does that work in practise?
Ah glad you asked, I almost forgot, I started this blog with the promise I made to JB to blog about one of the nice real life examples.
A little disclaimer, I did change a few details of this story, to protect the client.
This is large company that already has a website, yet the website is totally in a demilitarised zone of the company network. They have created a small thing they are going to sell over the web.
The CFO was a big supporter of this product and wants to see the websales on a continuous basis.
To do that, they would need to breach to security zones and insert the sales data into their SAP.
At such a large company, that is a large project that will take 6 months of development and to prepare, we will start with meetings with at least 20 people in the room. (Security experst, SAP experts, webdevelopers and then lots of managers all the way to the person below the CFO)
At another meeting, the CFO shares concerns about lacking visibility of the sales progress for the pet product during the first crucial 6 months. I propose a temporary side projects, using dimensional planning. (where we consider the highway version the other project. )
The dirt road version:
Every day, we generate a pdf report on the webserver that we put on a floppy disc. (Remember this server was disconnected from most of the network.)
Everyday we print the PDF and bring a copy of the papers of the sales to the CFO office and have an intern typing in all the data into our SAP system.
The PDF report is created by one of our developers on the same day as the product goes life. By the end of the day, we already have the data for the CFO.
First problem noticed: the CFO wants something extra, something our website did not ask our customers buying the product. The developer that had proudly shown the report herself to the CFO, went back to her desk and less then 30 minutes later, the website asked the extra info, and the new report was generated. (Missing the data of the first day.) Right in time for the newspaper article that was published the next day, when a large number of customers buy the product.
The next day, while these numbers come in, our intern tries to add the data to SAP. We discover our second Heusden. Turns out that we were targeting the wrong SAP table.
This fix takes a few days. The CFO keeps getting his report, yet nothing in SAP the first week.
By Friday of the first week, our intern is able to upload data.
Yet it’s very boring work and is totally not scalable. (We have a few thousands sales the first week.) Time for our
Cobblestone version:
This time we are going to generate the report in a cvs format (Remember, this is before xml was popular.) Every day the first developer arriving at the office, wil physically go to the webserver, generate the report and copy it to the floppy disc.
The same developer will take the disc and upload the data to our SAP system.
This version is more scalable, no matter how much we sold our product the previous day, the action for our developer is the same. Even in this version we have a small glitch: one of the fields is marked as text instead of number. (Just a normal bug).
It’s a manual action every day, not automated and is only updated once a day (for the previous day.)
While this solution is in place, the meetings continue for the highway version. At the end of such a meeting, I ask the collaborator of the CFO, how they use the data and if they are happy with the numbers. Almost by accident I discover that the CFO is only looking at the data on Friday.
(So not on a daily basis ) and he even does not care that he does not see the full sales of the day/week.
Luckily I have a meeting with this same collaborator and the CFO the next day. We talk about the progress of the highway project and how it’s really blocking people from working on a high priority legal project. I gently propose that we might keep the cobblestone project in place for now, and put the highway project in hibernate. A lot of people at this company are unhappy, because they had hoped to work on this super duper cool project. The security officer on the other hand is very happy, because she can keep the webserver in the safe zone, without temporary breaches.
In the end, the company saves 6 month of development for a highway, that is putting their network at risk and that would not really be needed.
A few years later I meet the CFO who tells me that the highway project was probably a little overboard as the product they sold online, never got any sales that even came close to what they would have had to spend to deliver the highway project. And thanks to the dirt road project, they discovered very early that the missing e-mail addresses of their customers and that turns out to be the best investment every. This e-mail list has helped them the next years to up sell some of their services to these customers and that has saved the company from going bankrupt.
7 comments on “Dimensional planning”
Instead of building a dirt road twice (!) to the wrong place, how about first drawing a line on the map to check whether you understood the requirement well?
Preflection rather than reflection saves so much time.
true.
In the example of the website, we assumed we build the right road, that is we were accessing the right table in SAP, we were wrong. That kind of mistakes happen a lot if you ask me.
Yves
That’s why one of my many matras is: “Better assume that our assumptions are wrong”. That’s why we need feedback before having done more than necessary to get the right feedback.
I know that this kind of mistakes happen a lot.
That’s why I urge developers to design before implementing:
“First develop the problem, only then the solution”.
Especially in Agile environments I see so many cases where people write software before knowing what the real problem is and before knowing what the right solution is. Trial and error costs too much.
>Trial and error costs too much.
that depends. LeanStartup is all about reducing the costs of try and error.
I agree that usually not done enough..
Agree. That’s what Lean Statrtup is about. As is Pretotyping (//www.pretotyping.org/uploads/1/4/0/9/14099067/pretotype_it_2nd_pretotype_edition-2.pdf).
That’s why I got a reflex when reading about doing even a dirt road three times, which I think is a bad example, especially for those trial and error Agilists. The dirt road may be a prototype. A line on a map would have been a prototype.
In belgium, I know of a post office that was created for the wrong city.
That is, it was build in the right city, yet the architect when he dis research, assume that it was for another city,with a name 1 letter different yet 10 time it’s size..
Nobody noticed it, until it was officially opened, lots of people planned, lots of people look at the plans, nobody during construction said anything…
Dirt roads and lines on a map won’t solve all of this.
They are both a way to reduce these costs.
Yes I hope the line is made.
and then a dirt road which brings ROI almost immediately (which the line does not)
And only when we do have some ROI we go further.
If no body uses the dirt road we can stop the rest.
Agree.