It aint what you might believe at first – a super-trendy writing about how to start blogging. It’s far more boring than that. This piece could also be headlined with something like “How to overcome the lingual glitch between IT and the rest” (though I realize I don’t have any clear answers, after reviewing this mess).
This reasoning might seem a bit over-due, old school or even obsolete in the era of furious Product-Management-with-an-agile-foundation, but it will never stop being relevant. Why? Because old truths are boring but often more persistent than we actually want them to be.
I will elaborate on one of the most overlooked phenomena that has existed even since human started to build things that in some way does human work for her – namely managing of requirements. I find it kinda strange that this discipline so often is regarded as a certain discipline, hosted outside a production workflow och outside a development project and populated by specialists that is regarded as a really special sort of nerds. The competence field QA is also often perceived as a bit self-generating and my experience is that it often is slipping around above or around the project or maintenance teams it is supposed to be integrated in*, similar to “the process team” that makes process management a work on its own merits, often regarded as self-generating as well.
From time to time I have been involved in discussions with business representants and in the context of trying to understands the needs and what problem they want IT to solve. Many times we have been sitting with an existing solution that fits the needs ok but not fully, and trying to improve functionality already decided and designed by a third part, the vendor of a system, may it be a cots, may it be quite a specialized product (in earlier days often named service, but product is a more popular term nowadays, yet another thing to explore in a future post…).
A repeating thing that has showed in these contexts is that the business side often have difficulties in formulating requirements so they are easy to digest for the IT people trying to technically solve the issues. Once we took it so far that we arranged educations for the business stakeholders, eg. mostly process leaders (might today be replaced by Product Owners), where we let our very dedicated and skilled requirements analyst teach requirements management to the participants. This turned out quite well for some time (not that long that we’d wished though), and lead to a little bit deeper understanding on the business side for the need of a common language when having the specifying dialogues.
BUT – the error I think we made then was to assume the starting point too late than what we should have** – because we didn’t explore the need for the requirement to occur in the first place. Business needs is the focal point one should start looking into instead of starting a change or request journey with trying to state a requirement that might be quite intangible if the needs aren’t clarified. I have seen agile profiles in different feeds emphasizing the need discussion, but I have never seen it being more than a fragment in the never ending flood of talk-about-how-to-work platitudes. This should be a success factor in both easing the need for translation but also a possible lever for the business side to actually take more active part in the early phase of a change tickets journey in the code-crunching machinery. It has also the potential of easing the often (always) cumbersome with prioritizing a backlog, since it should be much more obvious how needs are weighed towards each other than bad formulated user stories or features with unclear business value. It also has the potential to give a clearer definition of done, if you originate from the need instead of a lingo-feature description.
BUT – isn’t this already what all agile how to’s and agile descriptions always have told us in DoD and DoR’s explanations??
OF COURSE – I’m not trying to come up with some new fresh ideas here, I’m just (as always) trying to point out what already exists.
BUT – try, just try to give a business representative the explanation of DoD found here of even DoR found here, and you will get this “do I dare to question this mumbo-jumbo without being classified as an idiot” face in return. We really do need to be able to talk about needs (and in second-hand requirements) with the business side with being so centric about the IT-side lingo which is held so dearly by too many.
Tying the ropes:
Regarding the headline of this post: I somehow feel that I need to get back to this in order to tie this story together. One of the most common and I guess classic mistakes organizations do when it comes to management of requirements is the silly “You just can start from a blank paper” prompt, given by IT to business. It is often ditched quite quickly, since everybody knows that they need some kind of facilitation or guiding, because the present state is needed as input value, as well as different conditions and constraints that limits what actually is possible to describe if the user story is supposed to be meaningful and valuable.
For reference:
The explanation of what a user story is supposed to be is actually more or less good, but often overlooked and not fully embraced (or understood, or correct interpreted) by all in the processes, making it necessary to reflect over when uncertainties are spotted.
To be continued:
*) The QA experts should have more of a more tangible, facilitating role in the organizations they serve than they have, since their traces most often is a trove of hard-to-answer questions in the WoW-section of the endless Confluence library – for every team to invent and solve independently.
**) This urges me to write about the real life cycle of a change or new-feature ticket in a teams workflow. Will do this as soon as possible.
Leave a Reply