Agile Zone is brought to you in partnership with:

Allan Kelly has held just about every job in the software world, from sys admin to development manager. Today he provides training and coaching to teams in the use of Agile and Lean techniques. He is the author of "Changing Software Development: Learning to become Agile" (2008) and "Business Patterns for Software Developers" (2012) and a frequent conference speaker. Allan is a DZone MVB and is not an employee of DZone and has posted 85 posts at DZone. You can read more from them at their website. View Full User Profile

Requirements: Whose Job are They Anyway?

  • submit to reddit
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 doesn’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.”

Published at DZone with permission of Allan Kelly, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Mark Unknown replied on Wed, 2013/04/17 - 10:22pm

I plan to respond on Allan's blog, but the problem is that he is thinking in job titles and not roles, amongst other issues. I have been thinking and discussing this topic a lot lately, but from an "architects" perspective (long term perspective).

Lund Wolfe replied on Mon, 2013/04/22 - 12:18am

It's all about communication, according to XP.  If the business/customer isn't willing to dedicate someone to the development team or the developers aren't willing to understand the business needs and its vocabulary, hope for a very simple project with a simple end product.  We've all seen projects fail because they bombed at step 1, requirements.

If it's important and both parties care, they will fully cooperate.  The next option is to add a middle man to do indirect communication, which may work or may barely work.  Some projects are hard to fail because the requirements are few and almost anything delivered is good enough.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.