Failing fast to learn a lot

In the first part I wrote about common pitfalls when creating requirements documents. In part 2 I tryed to give an example and describe the outcome should one fall into one or more of the pitfalls.

This final part is based on a speech, I had to give a few months ago. The goal of the speech was to get the listernes to value the points, I’ve written about in my series on Mr. Work, especially the points from The Story of Mr. Work and the Love for UATs

Basically I wanted the audience to experience some of the challenges, that developers and Architects face every day.

Instead of just giving a speech, I decided to take a chance (this was when I was preparring the speec h not some last minute decisions, which would not have work).
I asked one of the listerners (they were 6) to come to my white board and describe Bathroom of his dreams (you know you had dreams about bathrooms, so of cause he’d had them too). He was to describe it in the form of a bullet list.

He wrote stuff like: 2 sinks, a lot of light and spacious. Actually most of the bullets were rather detailed, so I think every one a picture in their mind of a bathroom, that fullfilled that list just nicely.

I had given him a minute and when the time was up, I asked the next guy to draw a blue print of that bathroom. I hadn’t told anybody at the moment but as you might have guessed, that list was going to be my spec analogy later on and the blueprint the architectural documents analogy.

3rd one at the white board was the only woman present and her task was choosing all the elements based on the two previous “documents”. She had to decide what specific sink should be used (brand/model), which tiles, basically all the hardware, or you could call them all the modules for her job was the module design analogy. The last person at the board had to do all the plumbing and wireing.

With those 4 “documents” on the white boards I asked each of the first three, starting with the woman, if the result of the previous stage was as she expected and if not what was different. In the end I asked the first guy, if it was the bathroom he’d dreamt of. Of cause the answer was no.

In plan of my head that was the first goal to have him say no. So we were still on track.
Keeping to my prepaared plan, I started from the buttom again, asking about what we could do prevented there erros they had pointed out at each transition.
All my questions had been preparred before hand and was all questions I ask my self, when I do peer review or write unit tests, so I was pretty certain, that the answers I got, would fit nicely into and entire hierachi of arguments for using the w-model. (which was my over all goal)

When we were done, all the listeners had a clear Idea of why so many errors are actually based in lack of requirements.
We all agreed, that what they had first thought to be requirement specifications for a bathroom at best was requirements but no way near specifications and that the lack of specifications was the source of the problem or in the terms of the first part by making those dreaded decisions they would actually increase the PPV not decrease it as they had first thought.

I’ve tryed getting that point across so many times and fail horribly in most tries. Taking something every one can relate to, a bathroom and making them make the errors, forcing them to take decisions based on lack of information, the point was suddenly much clearere.

They realized that no matter how hard you try to do your work as an achitect if you only have informations like: “spacious”,”lots of light” and “2 sinks” you are bound to fail. You can be the best Bathroom architect but you will never design the bathroom the guy who wrote the bullet list envisioned.

What I learned, was to use analogies everyone can related to and instead of telling people the conclusions of some arbitrary scientific study, to guide them with preparred questions to make those same conclusions them self.

So in the future when I’m have to tell people about write requirement documents. I’m not going to talk about building Applications or abstract things such as the v-model. I’m going to tell them about building bathrooms

In part 1, I wrote about some of the reasons I think requirement specifications often have a less than optimal quality. In this post I’ll try to proliferate.

Let’s look at a possible scenario:
The user wants to be able to create/edit and format texts online, no Flash or Silverlight is allowed only DHTML. The editor is going to be part of the company’s CMS.

It should be possible to:

• Create new text documents
• Edit old text documents
• Choose the font type,size and color
• See the contents in all browsers
• Include pictures and sounds
• Insert links
• Use all Unicode characters

At first this might look simple but ok. However just digging a little we’ll find several problems. Most of them are based in an All-the-cool-stuff-should-reflect-back-on-us-and-al-the-bad-things-on-somebody-else way of thinking. So let’s dig and look at a few of those problems

“See the contents in all browsers”
The coolness of this requirement is of cause that the text will seems as intended in all browsers giving all end users the same experience.
The cost of the requirement would seem to be an incredible amount of testing but hi, thats somebody else’s problem.
A better requirement would be a fixed set of browsers. That would probably end up with a more user friendly editor increasing the coolness but that’s not so obvious to the person specifying the system so the fear of lowering the value will win.

Fonts
How about choosing font type? This requirement leaves a lot of decisions to the developers
Should the font changes apply to the entire text or just a part of the text? Should the editor validate against design guide lines? believing that the developers will make the exact decision the users would want each and every time is a bit too naive.
Again the specification is leaving more unanswered questions than it’s answering.

Actually every single requirement in the list above has the same basic problem. I like to think of it as the “Demand a lot and make no decisions” problem.

The above requirements could be implemented as a online version of notepad, where the user would have to write the HTML by hand.
Even though it would meet the requirements it would be absolutely useless to the customer.
Then the developers and the customer could argue who were to blame.
One could argue that every requirement is met but for the customer to accept that argument would mean they had to acknowledge a loss of Personal Value, which they will be very unlikely to do.
Getting out of a situation like that with every body smiling is a skill on it’s own. My point is that the project ended up there and stays there for the same reason: PPV.

The trick is to act early to make the users realize that there’s a higher PPV in taking those domain specific decisions only leaving the IT decisions to the IT professionals. That’s where building bathrooms comes in which will be the subject of part 3.

In another post I referred to a survey, showing that the majority of errors are made in the specification phase.

I often wonder why it’s such a hazel, for the customer to specify what they actually want.

I was attending a change management meeting not so long ago. One of the pointers was, that we are all making the majority of our decisions based on “perceived personal value (PPV)”.

In the case of change management PPV is the value, that one thinks the change will have for one self.
That is, if my boss suggests to me, that we should change the way we test our deliverables. I will unconsciously evaluate the value of those changes to me.
If I think I’ll end up spenting more time without elevating the quality. I will not be as motivate to implement those changes, as if I think I’ll spent less time accomplishing the same results after implementing the changes.

Sounds pretty obviuos right? But just as important and not so obvious is: If I cannot see the value nor see a loss of value. I will still be more affraid of the loss of value than looking for the potential gain.

Basically PPV is all the coolness factor. If a change makes us look more cool, we welcome that change. If it doesn’t make us look cool, we’ll more often than not be afraid that the change will make us look uncool and hence we’re not overly excited about it.

Let’s try and apply the same logic to specifications.
The persons responsible for the specifications will want all the success of the application to reflect back on them self and the possible failures to be somebody else’s problem.

Bear in mind that no matter how bad the specifications might seem. The people writing them are doing their best to be as cool as possible. The problem is, that the way they unconsciously evaluate what’s “best”, might be and often is slightly off the target.

My favorite user argument for doing things the way they did, was that they wanted the specifications to be flexible. They did not realize that that was self contradicting.

Loooking through the PPV glasses they were so affraid of making decisions that might turn out to be lower their PPV that they wanted to be able to change their mind at any time.
At some point they did change their mind. Unfortunately to implement the wanted changes we would have had to rewrite the entire domain model.
Faced with a 50% cost increase they decided to stick with what they already had.

I’m sure, if they had been forced to make those decisions before hand. The fear of taking uncool decisions would have made them think more about use scenarios. Making them realize that subtle changes to the requirements was needed. I also know, if we had had those extra requirements from the start we could have implemented them with no extra cost.

I wish that we as developers could make customers realize that not taking decisions that might lower the personal value later on, is making a decision that will lower the personal value gained. I do however have an idea on this, that I’ll blog about later, which is where building bath rooms comes into play.