We want parallell (agile) & predefined (waterfall) requirements at the same time.

19 01 2015

I believe we are many in the same situation. At the same time as we are developing the software we define the requirements in different formats – verbally, written or as drawings & models. Also we define our requirements in parallell with other projects who are dependent on our project or vice versa, and who already have started development.

This is basically something good. Previously many did the specifications up front – sometimes for months or years (!), then handed over to development who tried to understand and implement what was written. This led to many errors so the ”requirements phase” has basically disappeared completely.

I have many good experiences from working with requirements in parallell with development. It’s pretty messy and frustrating for everyone, but in the end, the result seems to get a bit better off.

The problem arise when the organization do want to work like this, and at the same time expects the product owners, business analysts, solution architechts or whoever works with requirements to have ALL the answers exactly specified completely for every conversation.

”If you can’t give us a complete specification this week on feature x then we cannot commit to give you any delivery for the next 8 months, and possibly not at all”

-”But, in order for us to give you a good spec we need to see your first version of the software so we know where the gaps are, and can fill in the blanks”

I have seen this many times. You don’t want a 6 months requirements specification phase, because you know this will generate too many errors. Still you don’t want to accept that by removing this you DON’T have a complete specification to offer, you DON’T have the answers to new or modified business rules and you actually HAVE to have a development process that deals with this.  (There are many available..)

It seems so hard for many organizations to accept the fact that there is no specification and to adjust the processes to fit with the new reality of requirements discovery during development.

Those organizations who learns how to facilitate the new way of working by building in these facts into agreements with suppliers or dependent organizatons will succeed.

And those who have realized you need people who spend more or less 100% of their time with requirements investigation, disvovery, design in the teams & projects will also have a better chance to succeed. In mature teams, with time, the ”agile” requirement process will settle but it needs attention, competence and focus.

We’re in the middle of a change and too many are trying to work both in the old and the new way with requirements. This creates only more mess. Let’s accept the new form of working with requirements in parallell with development, and adjust our organizations, agreements and contracts to this.




4 responses

21 01 2015
Joakim Holm

Nice one! I agree with you. I guess you are witnessing a traditionally thinking organisation trying to adapt to an agile world.

One suggestion might be for you to discontinue use of the words ”requirements” and ”specifications”, since they both suggest an oracle-like, complete knowledge of what to create. Why not use the vocabulary of the UX community, e.g. user need, user goal, hypothesis, experiment, learning, etc? I believe these words better convey the inherent uncertainty and risk.

25 01 2015
Ulrika Park

Yes I agree, ”requirements” and ”specs” give bad associations. As soon as you use these terms everyone thinks ”all requirements up front” or ”complete specifications” in stead of just ”specs”.

I often use ”hypothesis”, ”options” and ”user needs”, even ”desirements”, but I do miss a good collection term for all of it. I do have ”requirements” which aren’t a hypothesis anymore, and not really a user need (I can give a bunch of examples). I like the real meaning of ”requirements” but not the use of it. I guess I have no choice but to stop using ”requirements” in the end.. and I will miss the meaning of it.

23 01 2015

Bra inlägg och mycket viktigt ämne som jag tycker berörs förvånansvärt sällan! Tack!

25 01 2015
Ulrika Park

Krav i allmänhet och det arbete som relaterar till det berörs alltför sällan.. Det finns 1 miljard informationskällor om hur man programmerar eller projektleder, men ett fåtal om hur man jobbar med ”user needs”, ”krav” eller vad man vill kalla det..


Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in:

WordPress.com Logo

Du kommenterar med ditt WordPress.com-konto. Logga ut /  Ändra )


Du kommenterar med ditt Google-konto. Logga ut /  Ändra )


Du kommenterar med ditt Twitter-konto. Logga ut /  Ändra )


Du kommenterar med ditt Facebook-konto. Logga ut /  Ändra )

Ansluter till %s

%d bloggare gillar detta: