Now requirements isn’t the best word for it is it?
By saying we require something we place a constraint on it, we limit our options, we are saying we really really want that thing.
And when we say we require the screen to be blue or the button to be big or for a spell checker…are we really stating a requirement or a preference? And what problem or benefit is this lot solving or providing anyway?
And when I say problem or benefit…do I 100% know for sure that the problem being solved is the right problem and will the benefit I think I am going to get be completely realised?
The product shall provide a revenue of £10,000,000…..
Just another requirement…no, preference…no, wishful thinking.
In http://alistair.cockburn.us/Requirements+are+SINs, Alistair describes the stuff that comes out a requirements phase as exactly that – stuff! It’s not requirements you have captured…
“…what goes into that initial collection of decisions, the Here’s What We’ll Build list, it is all of those and sometimes not any of those, and other stuff, all mixed in. They are simply what some key group of people say at some point, “Here’s what we should build.”
Let us no longer call them requirements. Let’s call them ideas of what we should build. I know, snappy isn’t it?
So if they are ideas of what we should build will we build them? A long long history of projects tells us they won’t all get built. Those that do get built won’t all get used. Those that do get used won’t all have been built as originally intended. Those that don’t change then are the original ideas we had that were worthy of being what we usually call requirements…and that is a small fraction of the overall ideas we had back in the hazy days of the requirements phase.
So the first point to keep in the back of your mind is this…
Requirements are not requirements they are our initial ideas of what to build.
Moving on let’s consider why we are coming up with these ideas of what to build.
There has to be a reason. There has to be goals we are trying to achieve, problems we are trying to resolve. Without this, then our ideas of what to build are more like ideas of something to do to pass the time.
What we really want to come up with are ideas to achieve x or solve the problem of y.
There is a great and worthy distinction here. We are not building something for the sake of it. This is pet project territory and should be avoided (unless you have nothing better to do and you want to learn something new).
We are building things for a specific purpose and you need to know what that purpose is. What are the reasons behind building this in the first place.
If the ideas are the what’s then the reasons are the why’s.
But the why’s are just requirements sorry I mean ideas anyway aren’t they? They are the strategic ideas the organisation has deemed fit to invest their money in.
So second point is this…
Goals and solving problems are ideas for things that will improve the organisation.
But how do we know that the ideas of what to build will realise the ideas that will improve the organisation? They are after all just ideas…
We need some means of ensuring our ideas of what to build directly contribute to our ideas that will improve the organisation and we need some means of validating this contribution.
This leads us to deduce that we somehow need to identify what this contribution will be in measurable terms and also, if we are unsure of this contribution, we will also need some means of rapidly gaining feedback to verify that this assumption is valid.
In Lean Startup[i], Eric Ries describes this as the build, measure, learn loop…
Instead of making complex plans that are based on a lot of assumptions, you can make constant adjustments with a steering wheel called the Build-Measure-Learn feedback loop.
The third and fourth point are therefore…
Ideas of what to build directly contribute to ideas that improve the organisation
We don’t know if they will – we just think they will. Therefore we need to…
Gather early feedback how our ideas of what to build contribute to ideas that improve the organisation before we invest wholly in the development of that idea.
So some bright spark somewhere has had a bright idea.
How does this bright sparks bright idea see the light of day?
And why is this bright sparks bright idea brighter than some other bright sparks bright idea?
And which bright spark gave another bright spark the permission to have a bright idea and start working on it? Who comes up with bright ideas?
The principles of the Agile Manifesto are clear on this aren’t they?
– The best architectures, requirements, and designs emerge from self-organizing teams.
– Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
This suggests that our teams are empowered to come up with ideas for the architecture, the product and the design – they are not told what the architecture is, what the product must do and what the design must be. These emerge through the efforts and imagination of our teams. And we trust them to do this.
So I ask again… Who comes up with bright ideas?
The answer? Point number five…
No-one has the monopoly on bright ideas.
We also need to ensure future ideas are not lost. Deeper analysis of ideas may produce unexpected results that spurn other ideas. These cannot be lost. Ideas for new products, feedback and observations from past ideas need to be captured. Where? Point number six…
Maintain an idea inventory.
With all these ideas bubbling around and a commitment to start building we progress the endeavour with optimism and excitement. There is, after all, nothing like a team of software developers, analysts, testers all pulling together in the same direction trying to build something that is game changing.
But what if its 10 teams. What if its 20 teams or a 1000 developers?
It’s hard enough for a team of 7 to adopt the disciplined approach that successful Agile teams require…but hundreds of them?
You can be optimistic but scaled Agile projects fail just as bad and as many times as traditional ones.
So how do we communicate these ideas to all these teams of people? We can’t expect that we can just visit our teams and talk to them about all these ideas. We should form a backlog of these ideas of what to build and how they contribute to ideas that improve the organisation so they can act as placeholders for our conversations but when we scale it is a good idea to capture a little more.
We need some means of understanding where an idea fits into an overall end-to-end process and we need to know the scope of that idea. That is, we need to know what done looks like for that idea.
In the past we used to write Requirements Specifications. Specifying requirements is worse than capturing requirements when we now know that they aren’t requirements at all. However, I can’t bring myself to call what we should produce an Ideas Specification. It’s more like a map of how ideas are strung together and a set of examples that show what it’s trying to achieve.
The seventh and eighth point are therefore…
Map the ideas of what to build to understand how they relate to one another
Bring your ideas to life with concrete examples
Having produced a map and scaled our project we now need to use this to take our plethora of ideas and somehow distribute them equally between numerous teams. To stand any chance of success the ideas need to be independent yet still contribute to a meaningful clearly stated and communicated set of ideas to improve the organisation that we think would make a decent release.
Our ninth point to keep in the back of our minds is therefore…
Independent ideas are distributed equally amongst teams.
BUT…(and it is a big but isn’t it?)
Are we ready to distribute this much work amongst our teams? How can things be independent without the infrastructure already in place to allow these teams to surge? But getting this infrastructure is costly and time consuming and we haven’t yet verified the Ideas of what to build directly contribute to ideas that improve the organisation. We don’t know if they will – we just think they will. Which one is the egg and which one is the chicken?
My advice is that it doesn’t matter how sweet you’re architecture is if what’s built upon it doesn’t have the business value it deserves. You have to start verifying your assumptions on idea contribution at the expense of architecture…go on, do it…NOW!
Another rationale for deferring architectural perfection is that there is little point delivering a product to market if someone else gets in there first. A great product is, we’ll, great but sometimes getting in there first is more important.
Now lots of people will talk about this and talk about early return on investment and talk about getting the low hanging fruits done quickly. This makes an awful lot of sense. Rather than spending our time perfecting the product lets do the easy high value stuff first and ship it so we can get the first foot in the market and start earning…
Hold on and stop and think for a minute.
Is this always the best strategy?
New innovative products that successfully fill some gap will be copied and enhanced and perhaps eventually overtaken by one of your competitors. New products have a shelf life whereby you will maximise being the new shiny thing that everyone wants.
If you released the easy high value stuff first then how long will it take your competitors to build a similar product when all they have to do is build easy high value stuff to catch up. Plus you’re architecture is pants so its likely to be buggy and difficult to build on. If one of your competitors is a big name then chances are they’ll have more resource, existing assets, better marketing and greater connections and will destroy you in the blink of an eye before saying thank you very much for such great ideas.
So my tenth point is this…
The ideas behind choosing the first thing to build are as important as the thing itself.
Whether this is validating assumptions, time to market, proving architecture, quality to market or preserving the longevity of your market you have to be sure as you can’t achieve them all.
[i] The Lean Startup, Eric Ries, Penguin Books, 2011