Requirements whose job are they anyway?

Later this week I’m giving a talk at Skills Matter entitled: “Business Analyst, Product Manager, Product Owner, Spy!” The talk title is a reference to the John Le Carre book “Tinker Tailor Solider Spy!”, its probably too clever by half and I should just have entitled it “Requirements: Whose job are they anyway?”

The talk idea was born out of what I see as confusion and land-grabbing in the requirements space, or as I prefer to think of it “the need side” i.e. the side of development which tries to understand what is needed.

I think there are a number of problems on this side of the business...

First all too often this side is neglected, companies believe that Developers will somehow comprehend what is needed from a simple statement. In the worst cases this is a condition I refer to as: “Requirements by Project Title”. Just because Developers understand the technology does’t mean they understand what is needed.

Unfortunately Agile tends to make this problem worse because a) developers think they get to decide what is needed, b) business see Agile as a cure all.

The second problem is the exact opposite of the first: Developer exclusion from requirements. In this case a Requirements Engineering type is the one who is tasked with understanding need, probably producing excessive documentation, and probably giving it to developers who are then expected to create something. In the extreme this means developers never get to meet, talk to or understand the people and businesses that will be using the product.

However, it was another problem that was on my mind more when I thought up the talk: the confusion of roles between Business Analysts and Product Managers, made worse by the appearance of the Scrum Product Owner title.

In the UK it seems to me that too many companies think requirements are done by Business Analysts. This is often the case when development groups are developing software for the company’s own use or by a specific client. But when the product is being Developers for multiple external customers, when it will be sold as a product then requirements are the job of a Product Manager. I’ve written about this role before, several times so I won’t repeat myself right now - see Inbound & Outbound marketing or Product Management in the UK.

Part of the problem is that in the UK - I can’t really talk for other countries but I think most of Europe is the same - software companies appoint Business Analysts to do what us essentially a Product Manager role. I base this statement partly on the fact that when I deliver my Agile for Business Analysts course (at Skills Matter later this week and another version then later this month at Developer Focus) I find people on the course who I would regard as Product Managers but they - and their employees often have never heard of the Product Manager role.

Finally, I’ve also become concerned in recent months the Behaviour Driven Development is being used by Developers in an attempt to occupy the requirements space - a land grab!

On the one hand this needn’t be a problem, if BDD allows Developers to better understand the problem they are trying to solve then I would expect development to go smoother.

On the other hand there are three reasons why I’m concerned about this trend:

The “need side” is a fussy, messy, ambiguous area and I sometimes wonder if the rational engineering mindset is right tool here.

• I wonder if Developers really have the skills to understand the need side. Undoubtedly some do but I’m far from convinced they all do. Indeed those who do might be better off moving entirely from development into the BA or Product Manager role.
• Time: perhaps is the main concern

I have long believed that to really understand the need side, and to get to the bottom of what is needed requires time. If Developers are trying to tackle the need side while still coding then I question whether they have the time to do both. If they do not then I believe that opinion and assumptions will substitute from fact finding and requirements validation.

(I should say that on a small work effort, with a suitable Developer(s), having one person do the needs assessment and coding can be ideal.)

I’ve only really stated the problem here not the solution. I’m still working all this out in my own head, Wednesday’s talk should move the discussion forward and I’ve already started to sketch another blog entry on this subject - coming up soon “Requirements & Specifications.”