Separation of design and requirements may have destroyed more software projects than waterfall...
The people that convinced us to never mix design with requirements may have wrecked more software projects and destroyed more value in the software industry than anyone else!
Just think what happens when you separate requirements from design:
During those requirement writing sessions we tried our best to stay away from the design discussions because we knew that if we did go into design (which we wanted and felt we should do) the requirements would never be ready. So we decided to do the wrong thing because we knew there was no way we would ever get the requirements written and the Requirements Gate passed if we did not do it.
Now that I look back I find it amazing that we ever got the requirements right! Think about it, if you don't validate the assumptions you make but to a superficial level you are saying to yourself "I know that there's no way I can prove that I'm writing the right requirements for my system to succeed". How's that for a smart way to do software development? But that's how we got taught in University (still are today to a great extent), and that's what our process trainers brainwash us to believe in.
This separation of Requirements and Design is, in my view, the single biggest reason for software projects to fail, and it is still happening today!
Define the most important requirements first, then worry about the rest
This is why it is so important to delay writing the low-priority (as in "the ones you are not sure you need") requirements until the last responsible moment (aka "delay commitment"). You should take an appropriate set of requirements that fit in one iteration (using the highest-risk, highest-value heuristic) and develop those. Get a slice of the system working, don't get caught in the useless (and never ending) discussions that do not relate to the requirements being implemented (note that these requirements can be non-functionals also, e.g. performance or security).
Once you have a set of requirements implemented you have validated (or disproved) the most important assumptions about your system because those are the ones that relate to the highest-risk items of your requirements list.
Since you have avoided to think about all the requirements you have not either lost any time discussing requirements that make no sense to implement and therefore should have little (or no) importance when making the major decisions for the system, like architecture, technology, etc.
Another important thing to consider is that when you think about design, you are in effect creating feedback to the requirements cycle. If you separate requirements from design you are also removing all possibility of having early (and needed) feedback to your requirements writing!
If there are some times when I think I did stupid things in the past this is one. Boy, we were dumb back then! (and may are still today...)
at
21:48
Just think what happens when you separate requirements from design:
- You don't validate assumptions to more than a very superficial level (the "I don't care about the technology, just give me the business needs"-level)
- You never evaluate the system's constraints and how those may make the system possible or not (hardware, technology, etc.)
- You never think of how testable the system will be (as in "is it possible to ever prove that this requirement is implemented?")
- You don't write down the tests that will prove that the system works (until it is too late and you have to hire a gazillion testers to test the whole system using a script that was developed by people that never really participated in developing/defining the requirements)
- You never visualize how the system will be used by real users
- You probably - I'm being generous here - did not involve the testers/coders/designers in the requirements definition
- You spend way too much time disconnected from the reality of your business. Remember that our business is software development (as in coding/testing and getting feedback from real users) not requirements management (even though some tool-vendors will make you believe otherwise).
During those requirement writing sessions we tried our best to stay away from the design discussions because we knew that if we did go into design (which we wanted and felt we should do) the requirements would never be ready. So we decided to do the wrong thing because we knew there was no way we would ever get the requirements written and the Requirements Gate passed if we did not do it.
Now that I look back I find it amazing that we ever got the requirements right! Think about it, if you don't validate the assumptions you make but to a superficial level you are saying to yourself "I know that there's no way I can prove that I'm writing the right requirements for my system to succeed". How's that for a smart way to do software development? But that's how we got taught in University (still are today to a great extent), and that's what our process trainers brainwash us to believe in.
This separation of Requirements and Design is, in my view, the single biggest reason for software projects to fail, and it is still happening today!
Define the most important requirements first, then worry about the rest
This is why it is so important to delay writing the low-priority (as in "the ones you are not sure you need") requirements until the last responsible moment (aka "delay commitment"). You should take an appropriate set of requirements that fit in one iteration (using the highest-risk, highest-value heuristic) and develop those. Get a slice of the system working, don't get caught in the useless (and never ending) discussions that do not relate to the requirements being implemented (note that these requirements can be non-functionals also, e.g. performance or security).Once you have a set of requirements implemented you have validated (or disproved) the most important assumptions about your system because those are the ones that relate to the highest-risk items of your requirements list.
Since you have avoided to think about all the requirements you have not either lost any time discussing requirements that make no sense to implement and therefore should have little (or no) importance when making the major decisions for the system, like architecture, technology, etc.
Another important thing to consider is that when you think about design, you are in effect creating feedback to the requirements cycle. If you separate requirements from design you are also removing all possibility of having early (and needed) feedback to your requirements writing!
If there are some times when I think I did stupid things in the past this is one. Boy, we were dumb back then! (and may are still today...)
Blogged with the Flock Browser
Labels: agile, backlog items, backlogs, design, iteration, requirements, requirements management, risk, risk strategy
RSS link
2 Comments:
I agree and IMHO the worst enemy of IID and agile is the fact that many customers require a fixed price bid.
Usually this also means that the scope is pretty much fixed, because otherwise it's difficult to say what does the customer get for that fixed price.
So in practice many customers first order the notorious "analysis project" so that they have enough material for "implementation project" RFP and they can get bids that are within reasonable margin. In public sector Finland the law requires that you must ask for bids for any system that costs 15 kEUR or more. This has severe consequences that effectively ruin many of our chances to be truly agile.
My point is, that in most cases separation of design and requirements just happens because there are factors like money, law, contracts and lack of trust in the equation.
The problems of this model are numerous and violate most of the Lean and agile principles. The challenge is that there aren't too many options left to make it easier - even if both parties wanted to.
This leads to the well known "barrel of wishes" vs. "minimal scope" dilemma and bid low + use expensive change requests-game. Everyone knows this is a lose-lose scenario.
Pure time & materials deals require a lot of trust and partnership (and absence of public procurement law restrictions). "Cancel after any phase"-type incremental funding models are great if you can convince your customer and there aren't any critical constraints.
According to Lean wisdom attempts to limit or control the scope often increase it. This applies to the project cost as well.
Oh boy do I envy those IT shops that do internal product development. :)
By
Anonymous, at March 25, 2008 2:18 PM
I believe you are right when you say that there needs to be a lot of trust to overcome the traditional way of setting public-sector contracts.
Agile companies should be contributing to that by showing by example and bucking the trend in the public sector.
There are some good examples of that, at least outside Finland. It's time we start seeing some innovative contracting models being used within the "fixed price" jail.
Have you or your company looked into this?
By
Unknown, at April 14, 2008 7:18 PM
Post a Comment
<< Home