Agility in Requirements Gathering

Comments: 3
Rate this:
Total votes: 1

Requirements gathering should be done mindfully. Then there is this world we are living in, which requires agility, right? Well, can mindfulness and agile be imagined together?

Once you can imagine this your requirements will be solid and done right, and you will obtain agility. Your sign-offs will be also achieved smoothly. It won't stop there. Development, unit testing, functional testing and UAT will be smooth as well, including your org readiness efforts, along with your usage uptake and learning experience. Does this sound like it is out of this world, or in Utopia as most of us know this is not a very easy thing to achieve?

So, really...how do we do this? This is revolving around good documentation, with data and process visualization. It starts with seeing the big picture and depicting it in the most logical way. Let me expand on this little more. Spend sufficient time to understand the problem first. Listen to the voice of the customer (this is the group we are gathering the requirements from). This will build trust between you and your customer. Do not turn anyone off by making them feel uncomfortable. Sometimes consultants (internal or external) do this as they present their involvement in a more hostile way, not politely at all. Agility requires a certain level of speed and by being mindful, at the requirement gathering phase, you will actually help down stream processes. You will also win the customer. By truly hearing their concerns, you will help them be creative in resolving their problems together. Use visual depictions. Diagrams, that are simple to follow and interpret, and sometimes even hand drawn sketches will help you tell their story in a unique way which will resonate with everyone, and be understood.

We all had worked with PMO assigned PMs, and for them it is just another IT project. It is not PMOs or PM’s responsibility to have agile requirements, they did not write the requirements. Do they even have to understand the requirements? Or have sufficient time to digest it, track changes, follow it up closely? Ultimately, aren’t they also responsible to deliver a project with an excellent customer experience? Between the time a requirement is written, understood by all, signed off on it, and given to PMO to do it, the document goes through so many iterations, it is hard to follow it. PMs just treat it as another item in their project plan, they don't know much what's in it! However, aren't they the stewards of that document. Like a classical orchestra conductor, they should live and breathe it. I know what you think. I keep coming to the PM, but this is about requirements gathering, and documentation of it in an agile way. The document is not even used by PMs much. Developers use it, architects better know it, process owners should sign off on it. PMs really care about their project plans, and their metrics. They don't have time to track anything in its entirety in an agile world. They just go with it, and conduct the whole thing without even knowing the music at all. As they run these sprints, it's all about how many of these they deliver on time, under budget, right? Most PMs assume the quality of the requirements is already in place since it passed all of those steps. A PM most of the times don't even think they need to know intimately about the product/service or whatever their project is delivering. They complete their project and move on to the next one.

If we gather and document mindfully then everybody will know the music. They will feel it, live it, get so close to it and consequently deliver quality projects. Overall customer experience will also be good and they will all be happy users. Learning will be faster and knowledge will be sustained. Simple visualization is the key for agile efforts. Know your customers well, know their process by listening to them. Spend up front time gathering their requirements after you hear their voice well, and know what they want. Use data and process visualization and simple, yet strong illustration in your documentation. For sustained and clever solutions that is the best approach you can adopt. All you have to do is to document what you hear mindfully, using visual depictions, illustrations, and sketches. Agility will start with this. You will see how it will help expedite all steps downstream and your requirements will be simply better and naturally agile when done mindfully.

Comments

Ahmet Akal
,
posted 7 weeks 2 days ago
I agree, simplicity is key to agility. That's why sprint approach is so helpful. Divide and conquer but use simple depictions.
Dagmar Biegon
,
posted 18 weeks 2 days ago
You address the need for sketches, drawings, diagrams. There are lots of visualization courses around, which I usually found to be helpful for BAs. You can also act als multiplier and present the course content to your team, so everybody can benefit.
There are different visualization methods around - to be honest I forgot the particularities of each single one, but I took the best of each method and use a mixture of them all. Anyway, to work agile means (to me) not to be too method-dependent.
Steven Gordon
,
posted 18 weeks 4 days ago
Your approach still seems waterfallish to me. If you are gathering all the requirements before handing them off, it does not matter how mindfully you do it, it inhibits agility. To facilitate agility, what you want to do is collect just enough of the requirements for development to get started. Then slices of working software can be delivered to validate that the system that will be developed actually solves the intended problem. It does no good to meet the initial requirements, if the system does not solve the intended problem. Once that feedback loop is established, there will be better understanding of what is actually needed, which will then facilitate collecting better requirements for the next iteration. Furthermore, by not getting too far ahead of development, there is always more feedback to improve requirements gathering as well as every other aspect of the development effort. Also, when all the requirements being gathered are turned into working software quickly, there is no need for extensive documentation. Just explain each requirement to the developers as they are about to start on their work for the requirement.

Join the Discussion

Your email address will remain private.

Shopping cart

View your shopping cart.

Related training courses

BPMInstitute.org provides training courses online and in person for individuals and groups. View courses related to the material you are reading on this page. 

OpEx 101Agile Business Analysis 101Decision Management and Business Rules 101BPM 101Methodologies and Approaches for BPMView the Learning Path for more courses »

Business Process Management Jobs

Editorial Directors

Gregg Rock
Gregg Rock
Editor & Founder
BPMInstitute.org

Andrew Spanyi
Editorial Director
BPMInstitute.org

Jeff Scott
Editorial Director
BAInstitute.org