The Same Old Way
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?
Scrum
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.”
Effective?
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”?
– Bob
Think Different
Bob,
I’ll start by saying that most of my work has been in large corporations, usually in large projects, and almost always within large systems landscapes. My comments are probably best understood in the context of this background.
Requirements & analysis:
The term “requirements” means different things to different people. I rarely get to see statements of business intent and a request to propose ways of achieving this intent. Instead, I get to systems requirements, i.e. detailed statements of what the system shall do. (When I get to see statements of business intent they are usually found in the introduction to the systems requirement…and are rarely, if ever, referred to again.)
I consider such requirements to be design decisions (http://wp.me/p3sVQX-6Y).
The typical requirements document I got to see is the product of an analytical process driven by efficiency concerns (separation of work), i.e. usually they are a more or less unorganised collection of seemingly unrelated (i.e. not explicitly related), fine-grained demands against a system. This is not surprising: if all you allow for is business *analysis*, where could *synthesis* possibly come from?
Note: I don’t intend to insult or disrespect anyone calling themselves or being called a business analyst. My point is only this: analysis alone doesn’t solve any problem.
Business requirements & software developers:
I met many software developers who were unwilling to engage in meaningful dialogue with product owners (used here as a shortcut for “the people with the detailed vision on the product”). Such dialogue was often considered to detract from the “real work” of coding to successfully deliver in the current iteration. A mindset of “Just tell me what to code” prevailed.
I’m happy to report that I also worked with great developers who were willing and able to engage in such dialogue.
Business requirements & systems of systems:
Engaging with product owners in dialogue on business intent and how to go about achieving it often touches several different systems in a larger, complex systems landscape. In such contexts, people deeply involved with one of these systems frequently had difficulties to contribute to overarching dialogues in an effective way. In particular, it seemed difficult to tolerate that concerns specific to one of these systems seemed less significant when viewed from the broader perspective.
Requirements & “the people with the detailed vision of the product”
I learned that in some large organisations, “the people with the detailed vision of the product” and the responsible product managers (i.e. “the people supposed to have the detailed vision of the product”) are not necessarily the same people–even if understanding “detailed vision” as a business-centric, outside-in view. To make things more interesting, there often were many different people who felt responsible for defining this vision.
This opens up a niche for people to provide value by consolidating these different, and often conflicting, visions and to offer this consolidated vision to the rest of the development team (and back to the other stakeholders). Rather than replacing and shielding the team from those other stakeholders, these people bring *context and purpose* (http://wp.me/p3sVQX-6K) to the dialogues between development team and product owners.
So, in conclusion, big requirements produced upfront with little regard to how the different pieces will form a coherent solution to a relevant problem weren’t helpful in my past. The approach that worked time and again was this: explicitly state the business intent (http://wp.me/p3sVQX-2T) and co-create the way to go about achieving it together.
The approach is simple. Pulling it off is not. And just because you pulled it off on the last project doesn’t mean you get the chance to try it again on the next.
Thanks for joining the conversation.
I concur with just about everything you write here. And special thanks for mentioning “business intent”. I have never seen business intent clearly and coherent described, excepting in some case studies by Tom Gilb (being a topic at the heart of Competitive Engineering).
NB: I write a lot on the topic of “organising intent” – a fellowship-friendly version of “commander’s intent” c.f. Auftragstaktik – in “Product Aikido”.
– Bob
Bob, thank you the pointer…this sounds interesting.
– Oliver
Pingback: The problem team & the solution team | On Service Design
As a business analyst who appreciates agile software development methodology, my requirements probably come off as vague to most developers. My goal, however, is to document just enough so that a conversation between us can take place.
I read recently that software engineers are like physicians. They have an obligation to their clients to diagnose known problems and prescribe effective therapies. Especially for tougher problems, prescribing takes some thought and hopefully involves consults with other “physicians”.
Pingback: Five Blogs – 31 May 2013 | 5blogs
As a developer who works on air traffic control and defense surveillance radar real-time software, requirements “artifacts” from radar domain experts are indispensable for getting the job done. They are the “go to reference” from which all analyst/developer communication is centered upon. To extract tiny signals from noise and environmental clutter and enemy jamming requires sophisticated, math-intensive signal processing algorithms that I aren’t trained in. The radar engineers don’t just throw huge specs over the wall to us. We iteratively work together to resolve ambiguities in the specs and holes in the algorithms. It’s not the same as writing the functionality for a web site shopping cart or an online survey form.
It’s all about context. What works in one context can utterly fail in another context. In my case, without “blueprints” to reference and guide the development, we’d be blown out of the water by our competitors because our radars wouldn’t work – period. They wouldn’t detect or track any aircraft if the algorithms and math manipulations weren’t captured “in the same old way”.
Thanks for joining the conversation.
Have you or your crew experimented with other ways? And, btw, would you call your present way of working anything like “agile”?
– Bob
You’re welcome Bob.
You mean like not using specs? I have no idea what could replace them and still work. What would you suggest?
Yes, I think we are agile. We communicate a lot, the focus is on the product and not the process, we have a controlled but not onerous change process, and we trust and help each other. Is that not agile?
A very interesting perspective.
When I read your comment I thought this form of collaboration must surely be due to the fact that your software system is ‘just’ a (sub-) system within a larger (non-software) system, i.e. your requirements are part of somebody else’s solution design. (I’m not implying a lack of complexity, value, significance of that software or of the work you do.)
But I then realised that in the fairly distant past I have worked in similar setups–but in entirely different fields: salary & wage management, commissions management, financial clearing & settlement. In these contexts, ‘hard-core’ domain knowledge was essential. We had people with domain expertise on the teams, and we had access to more people with even deeper domain knowledge. (I remember helping financial risk management experts get into domain modelling, and them helping me to understand the basics of financial risk management in return. Great times!)
Interestingly, the formal statements of requirements seemed much more lightweight and the approach much more collaborative than in contexts where less ‘hard-core’ domain knowledge seemed required (or available?).
As an example, just about everybody has an opinion on the design of websites. And sometimes the strength of that opinion doesn’t seem directly related to the strength of its foundation.
– Oliver
Every system is a sub-system of a supra-system 🙂
Indeed, but not all of these supra-systems are designed.
As soon as a person mentally aggregates a collection of things/objects/ideas and sketches a boundary around them for whatever reason, that person has designed a system of interest for him/herself.
I was referring to ex-ante deliberate design as a system within a system. Apologies for being unclear.
Bob,
Thanks for your posting, very thought-provoking as usual. I joined a discussion on this general topic with you on Twitter, but it’s too limiting (as usual!).
[Aside: Many discussions on this topic seem to assume in-house IT supporting internal business users. I am writing from my current perspective of contract s/w development for external customers, not necessarily co-located or even in the same region]
You discuss “the people with the detailed vision of the product” – there may be multiple people, each with a partial vision. They may not agree with one another, or be consistent over time. They may leave halfway through the project. They have other responsibilities. They may work on different sites (or perhaps even countries). They may need to go off and consult further people (who are not necessarily immediately available) when a searching question is asked. This can take a lot of time and organisation and means that the vision of “interacting individuals” may actually be somewhat sporadic, even if you are lucky enough to be co-located.
That doesn’t mean that traditional ‘comprehensive specs’ are the answer, but it may mean that knowledge gained in the lucky moments when all the right people are available needs to be captured somehow, because it will not be on-tap at the moment when it is needed. And artefacts (maybe documents, wikis, whiteboard diagrams, lists) can be useful aids for developing, presenting and capturing shared understanding. The software itself is not always so useful for this, especially if there is a lot of logic that is not visible to end-users. I’m concerned that we don’t throw the baby out with the bathwater.
– David