When business analysis really would help

Whilst not every team needs a business analyst, some would really benefit from having one.

Each of the following items adds weight to the usefulness of having a dedicated BA on the team.

• A moderate to large number of developers
• Developers who prefer to cut code
• Developers who prefer not to speak to the customer
• Junior or inexperienced developers
• Working across several timezones
• Complicated backend systems to integrate with
• Multiple channels of customer feedback and insight
• Busy, absent or otherwise non-engaged PO
• PO who doesn’t have the time (or want to) write user stories
• Pixel-perfect designs produced ahead of developer involvement
• Outsourcing the development of core business capabilities
• Long-cycle times for customer feedback
• The technical team has partial visibility of the end product
• Developer performance measured by volume of code
• Personal accountability for getting things wrong
• Having a 5-year product vision but not a 3-month delivery plan
• An organisation not ready for agile working
• An organisation that doesn’t want agile

A catalogue of anti-agile, anti-software development practices. But equally, perhaps an uncomfortable acknowledgement of what many software development teams look like on the ground.

Whilst a sincere desire to invest, train and improve in software development practices would remediate many of these over time, there is often an overriding need for delivery in the ‘here and now’ that is more urgent than anything else.

Also, many teams do not have the remit to make drastic improvements or find themselves in an environment that restricts meaningful change.

I’ve found that excellent business analysis (ie. retaining an experienced technical/digital/IT/agile BA for the team) can significantly address short-term delivery pressures despite the factors above.

Whilst acknowledging longer-term improvements will likely need interventions greater than the development team can make themselves.