This is from a while ago, written as an attempt to provide an overview of how these three roles have changed and how a large and complex organisation might transition from a more traditional setup to a more modern “fighting fit” one.
Posit: the Business Analyst role is fading
The role of Business Analysts in the last 10 or so years has changed perhaps more than any other role in the technology world. In many cases, it is fading away, with those same skills being picked up in either expanded roles, or new roles.
Traditionally, the thinking was that we needed “accurate requirements”. And so we needed Business Analysts to “translate” business requirements and put it all into a detailed specification which was then handed to Developers to build. The basic model that this supported is sometimes referred to as BDUF (Big Design Up Front) or the more pejorative “Waterfall”. The suggestion being that you spent a lot of time and effort figuring out exactly what the business wanted, writing that down in detail and then handing that document on to the people who then executed those specifications and built what you wanted. The thinking being that this was the best way to make sure you weren’t building the wrong thing.
Unfortunately, the result of this approach was often software that was unusable and worthless, partially because of the ambiguity of the English language. Many billions have been wasted in this fashion. The real problem was the the feedback loop between what we thought we wanted, and whether that was possible to build, or if users actually needed that was far too slow.
The shift to “agile”
What changed was a switch to a more “agile” iterative approach. By shortening that feedback loop, and working in a way that not only allowed iteration, but actively encouraged it, the role of the BA needed to change.
Often, the shift starts with “user stories” as a primary mechanism of capturing smaller requirements that can be delivered in a few days. The written stories are not supposed to be independently read and executed, but rather to act as a placeholder for a conversation, with back and forth clarifying questions and answers. The new model required collaboration between the person who understands how it needs to work, and the person who is actually building it, rather than a formal handover of a document that would (in theory) replace this conversation. We learned the hard way that “specifications” without iteration didn’t work.
The other key change is the introduction of frequent “demonstrations” as a way to not just follow the instructions of what to build, but to provide checks and feedback from end users. “This is what we’ve built as a result of our conversations. Does this work for you and users?”
The most common response I’ve seen to these changes has been to convert the Business Analyst into “Product Owner” in a vanilla Scrum setup. Sometimes this came with a typical 2-day sheep dip style scrum training. Often it was completely unsupported – as if changing the job title and description would work. Unsurprisingly, this hasn’t always been successful.
How many POs per team?
What doesn’t work, is having more than one Product Owner for a team. In a lot of large corporates, you tend to have such complex business rules and logic that needs to be understood that a single Product Owner for a team of 4-5 developers quickly gets overloaded. This generally results in quality issues, where key processes are rendered in software in an incomplete way, to the point where it is risky. In this case there is a tendency to continue with Business Analysts in the team working with the Product Owner/Lead to clarify what to develop. This is not an uncommon model.
Depending on the complexity of the business rules and problem domain, and if your developers don’t have deep enough or long enough experience, you’re generally looking for someone with subject matter expertise to help guide development. That often falls to an experienced BA. Hiring a new BA to do this doesn’t make sense. Might as well just hire a Developer and have them do it. Limiting WIP in the team, pairing up those with subject matter expertise with those who don’t is also a good solution.
In short: only 1x Product Owner per team. Either support with more BAs or have the Developers do more of their own analysis, depending on the team, experience, codebase and problem space.
QA has also changed
At the same time, how we do Quality Assurance as has also changed a lot – especially over the last 5-10 years. The shift to Continuous Integration and Continuous Delivery requires a level of automated testing that means a lot of the more manual testing that a QA has typically done has reduced a lot. QA in teams these days tend to be more focused on Integration and End-to-End testing through the UI, where it is both harder to automate and can introduce a lot of work maintaining a working test suite for a product or application that is changing from week to week.
The advantage of having fewer manual tests and automating more of the quality assurance is that the Developers can do much faster iterations, reducing risk and getting higher quality changes into the hands of users and customers much faster.
The introduction of regular Demos (at least every 2 weeks) also means that Product Owners and BA/SMEs are more involved in QA than before.
In this way, QA is increasingly more of a “practice” that Developers and teams themselves are collectively responsible for. This is the holy grail though. Most large corporates are a long way away from fully automated test suites with sufficient coverage of unit tests to catch risks sufficiently.
To help figure out where you are, look at Unit Test coverage of different areas, or the shape of your Test Pyramid. If you’re not already focusing on shifting to Continuous Delivery you’ll want to dial that up. Most of your people in Technology will already understand this, the question is whether there is any focus or slack in the system for them to make the necessary improvements.
Organisations that have higher Digital maturity get this and have made (and continue to make) the necessary investment into chipping away at Technical Debt and automating QA as much as possible. The faster feedback loops that result are well worth it. Most organisations I’ve seen still have a long way to go on this journey though.
T-shaped hiring & training (Combine BA & QA where possible)
A good model for handling this is to train (and hire) people across a broader skill set that covers both the BA part of the process (mostly upstream of Development) and QA part of the process (both upstream and downstream of Development). This is one example of what we call “T-shaped” people.
The idea being that instead of hiring specialists in either BA or QA, that you instead hire people that cover both areas. In effect, these “Quality Analysts” work closely with 2-3 Developers helping them to understand and break down stories, write executable Acceptance Criteria (BDD) and then help with manual testing of happy path, failure modes, exceptions etc. (and gradually automate these) as well as the usual exploratory testing.
The previously mentioned approach, where you train (and hire) Devs to do this actually results in an even broader T-shape – a Developer who can also do the necessary Analysis as well. Even better is if they can do all three: Analysis, Development and Testing. You can develop this, if you provide a learning environment, where folks can pick up and learn each of these skills as part of in-house skills development, via communities of practice and team policies and process.