Closing the communication gap: an Agile approach to defining software requirements
The communication gap between business professionals and software development teams is one of the main reasons software development projects fail. Here we explore how using Agile to change your communication process around requirements can help you close that gap.
Why software projects fail
Software changes fast and often. Its development involves and impacts a lot of people, so the risk of misinterpreting or mistranslating requirements is high. That risk is even greater when:
- You’re communicating complex information
- You’re communicating a lot of information at once
- You’re communicating separately to lots of different people
- New information emerges, or things change over time
The result of a communication gap in software development is a misalignment between what is expected and what is delivered. In other words, your digital product will fail to hit the mark, falling short of your business goals.
So what can software development teams do to close the gap?
Using Agile to close the gap
An Agile approach to software development helps mitigate the risk of a communication gap by prioritising rapid feedback, willingness to change, and collaboration around a shared objective.
Close and regular communication between business professionals and development teams is at the core of the Agile manifesto, which was created to help teams release working software to market faster.
But many organisations are still transitioning to Agile, or have only adopted it on a fairly superficial level. For product owners, business managers, or business analysts in teams who are moving to Agile, the following five pointers will play a crucial role in closing the communication gap.
1. Start small with your analysis
When planning a change, or defining requirements for a change, avoid defining the whole backlog or scope of work to a high degree of precision up front. You’re exposed to a greater risk of missing something, getting it wrong or things changing. Also, consider how overwhelming it can be for the recipient when you’re trying to communicate that amount of information.
Breaking your changes down to small pieces of value will reduce the complexity and the amount of analysis you have to do in advance. Drip-feed the work into the development cycle to deliver working software or get visibility of it earlier.
2. Communicate and define requirements collaboratively
When you’re conducting analysis around a change, and trying to define it in isolation, the risk of communication and translation issues increases.
When your development teams haven’t been involved in the Discovery journey with you, they don’t get the same sense of ownership, vision, and context. It’s a proven leadership technique to involve and empower your team members rather than tell them what to do. This builds-in a sense of pride and purpose in what the the team creates.
Based on engagements with our clients and what I’ve seen across the industry, getting business professionals, analysts, developers, testers, and other project stakeholders together to analyse and define what needs to be done and why is a must for delivering software well. It’s important to embed business analysts and product owners and even end users into teams to ensure alignment with the people who build the software.
Be mindful of translation and alignment issues. When sharing tacit and explicit knowledge between people from different backgrounds, they often don’t know the business context or jargon. Consider using behaviour-driven development (BDD) and specification-by-example techniques to aid the conversations you have as a group.
3. Overcome complexity with early learning
If you’re working on a complex change with lots of business rules and functionality, try prototyping it or iteratively developing it to prove the assumed value.
This will help the team and the business stakeholders visualise and understand the resultant changes, and check everything is as expected, early on. If you have a requirement that’s hard to define, or a feature that you assume will be valuable but are not sure, this approach works really well.
Work with the team to look for those small pieces of the change that can be built quickly to validate that you’re going in the right direction. If you invest in a change that doesn’t turn out to be very valuable, the learning by delivering early is in itself valuable.
4. Be more than the requirements scribe
A good requirements specification document or model that you create with business stakeholders and throw over the fence to the development team is not your goal. Your goal is to deliver some valuable working software.
As a business manager, business analyst, or product owner, it’s more important to spend your time finding valuable opportunities and communicating them to your team than it is trying to detail and specify exactly how you want it to function.
The nature of their role requires business analysts to be effective facilitators and interviewers. Their strength is eliciting information and using techniques to decompose and question a change, tracing it back to some business value.
This strength carries a lot more value than writing specifications perfectly in isolation. The ideal way to define functional or behavioral specifications is to let them emerge from a team discussion where the perspectives of team members like developers, QA, and end users contribute to a consensus agreement of what needs to be done. The outcomes should be made explicit and documented as reminders but the discussion itself is a fantastic way to avoid a communication gap.
5. Keep an eye on change
An Agile approach to software development involves analysing and learning what changes work as early as possible, so that you can respond to change. As a product owner or business analyst, you can play a key part in measuring the impact of a change and utilising analytics tools and user feedback to help you do that.
Be on the lookout for alternative options or changes. Analysing the market and what similar competitors are doing. This all feeds into your process of finding value and learning what works and what doesn’t in a world where things change fast.
