There is a really really great opportunity to mentor and help one in thought of something. Either direct advice or as a sounding board to provide wider understanding, another view or new insights. I also find the self-recognition effect very amusing and the challenge to transform what I apply myself into written or re-distribute like into this article. Okey, enough gaiety and back to the topic! This time the mentoring was about this (classic) topic;
Business are bad to describe to IT what they want. How to make them understand what we need?
As you can see, I was immediately pushed into a classic round: Business vs IT
Anyone with a sense for humor do understand the point of the model. However, there is usually a gap between IT and business. Intentionally and by the book, one can think this is a junior question and following is just a skill curve. But fact is there, described in different job descriptions, in pillars of an IT architect, as well as a program manager or an project lead. Even whole programs is defined and driven to reduce this symptom. There are a lot of value in agile IT waiting for this gap to reduce. Every discussion like this, is little step closer to provide this value, to users, employees and organisations.
The best part of it all, it quite simple to address and mitigate. Just by mindset and patience.
This time I was given a chance to emphasize Engagement as the way forward. Opposite to contractualization or spending time to claim, restrict and explain definitions. Of course a documented baseline can (and should) co-exist, such as “how business should define a requirement”. But as soon as that tool is used just to “throw over the desk”, there will be a “how IT should meet our requirements” and then we can start round 2 and everyone fail.
Instead, we consider engagement. The key is to build dynamic and soft touching points, reflecting the situation and scope. Either the method for the requirement delivery from requester (business) to receiving IT (developer), the content to be discussed, documented as a test case or similar. Based on the change management culture in the department(s).
The shared forum should be technology agnostic and driven by the need to complete both sides perspective of the requirement.
I like to ensure generic approach wherever possible, to enable re-use of methods and thinking. Not being bounded to a product or vendor, not require the other side interact with specific tools except for general office tools. The “engagement” itself may be a email chain, a phone conference, meeting over desk, shared screen viewing a Kanban board, or all of them. The point is to have the together-approach when decide and agree on how recognition meet requirements.
The deliverable from the engagement into development would be very product specific. But the requirements or ideas need to be iterated through a templated assessment, a set of questions like the next model below. It’s easier to mention “what to define here, in the acceptance criteria?” out from a defined template.
If a item does not apply, just mention it does not apply and pass to next (but do mention it, don’t just remove the question). If an item can’t come to conclusion, just document that and return to it next time (classic backlog).
This much, was approximately what we was able to conclude during our 30 minutes session.
Finally transformed into the point of increased value
Beside this, it’s open to take next step with connecting continuous integration and continuous deployment to the requirements and automated reports for test acceptance approval by business. Let’s that be a later story. Or your story.. =).