The Same Old Way
“They came on in the same old way – and we defeated them in the same old way.”
~ Arthur Wellesley, First Duke of Wellington
As someone who develops or tests software, how well do written requirements – a.k.a. “specification documents” – meet your needs?
Have you, in fact, ever thought about the ways in which you come to understand what needs to be implemented?
Or do you just take for granted that there will be business analysts cranking out specifications in the same old way, and you’ll be poring over them in the same old way, ad nauseam?
Who Serves Who?
Do you see your business analysts as the experts on the expression of requirements, and defer to them in such matters? Or do you have a more of dialogue about your needs as implementors, and about how they (the business analysts) might best serve you and your needs?
The Agile Thorn
In Agile development, of course, three of the four core values in the Agile Manifesto are:
- “Working software over comprehensive documentation”
- “Individuals and Interactions” over processes and tools”
- “Responding to change over following a plan”
I have long chosen to interpret this as meaning that developers and the people with the detailed vision of the product – if not one and the same – get together as interacting individuals and explore, exchange and refine their common understanding of the emerging “requirements” by building working software – and not by cranking out and then working from comprehensively documented requirements specifications (in effect, a plan a.k.a blueprint).
Aside: My thanks to @michaelbolton for providing the related insight that the content of requirements specifications (documents) are much too often mistaken for and confused with the “real requirements” i.e. what the users, etc. of the software, product or service might actually want.
Who Leads Who?
As a business analyst, have you explored the needs of the implementors, with them? Inspected together how you and they come to understand what needs to be implemented, and adapted to best – or at least, better – meet those needs?
Who is better placed to initiate or lead this kind of dialogue? Does this fall under the general heading of “Business Analyst expertise” or are the implementors best placed to initiate and/or lead the conversation?
Lest we forget, or overlook the Scrum perspective on this subject, in Scrum there are only three roles: “The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master”. Also note: “Development Teams do not contain sub-teams dedicated to particular domains like testing or business analysis.”
So, the core question remains: In highly-effective development work, are there alternate, more effective means for deciding what gets implemented (and incidentally, when) – or is everyone just stumbling along “in the same old way”?