I recently spoke with a friend of mine, who is now a software development team manager in a Fortune 500 listed company. He shared with me that his managed teams work using agile methodologies and consist only of software developers. No Business Analysts, Solution Architects, or dedicated Quality Assurance team. His argument – a quote from the Agile Manifesto:
The best architectures, requirements, and designs emerge from self-organizing teams
These roles are embedded and assigned internally, rather than being a separate, dedicated function.
This made me think, I still believe having these roles as a dedicated function adds material value even when agile software development methodologies are used. My arguments:
The traditional role of the Business Analyst (BA) is to capture and document requirements, to have an in-depth understanding of the business, to possess the ability to analyze and order the different viewpoints of stakeholders. That also means he is facilitating the negotiation between the stakeholders and the development team about what to build. In Scrum, the Product Owner (PO) is much more focused on an individual product, whereas a BA might be working across a whole family of products. While the BA will help formulate the product vision, it’s the PO that takes ownership for this vision and is accountable to the business for getting the product delivered. The PO makes the ultimate decisions about what to build and what not to build to ensure the creation of maximum value.
The two roles have obvious overlaps but they’re quite distinct in terms of responsibilities. Often BAs feel that their skills are undervalued by Agile development teams. They’re expected to come up with requirements instantly and, when they can’t, are often criticized for being pointless. After all, couldn’t the Scrum team just ask the business directly?
Frequently the answer to that one is no. To whom would the developers direct their inquiry? How well would they facilitate the resultant conversations? How would they be able to combine the different answers of various stakeholders into a set of requirements that creates value for the business? These are the unique skills of the BA.
For these reasons, I think the BA has an important role to play in the Scrum team. In a sense, the BA keeps the PO honest – ensuring that the needs of the business and the customer are served by the PO’s decision making. Their input into planning and backlog grooming exercises is vital in this respect. To get the most out of the BA and PO relationship their roles and responsibilities should be kept distinct and well-defined. Scrum helps here as it has a clearly defined role for the PO as the owner of the product backlog.
BAs also serves as the bridge between the stories, the requirements and the task list. They also help in settings roadmaps and once the roadmaps are set, BA will help keep the team – including managers, developers, users, and other analysts – focused on the end-game through retrospectives. Thus a BA definitely fits into a Scrum team.
The traditional role of a Solution Architect (SA) is to be the strategic designer and planner of solutions in a tech environment. That their role has historically been viewed as disruptive or slowing down the progress of engineering teams because they’re driving toward a bigger vision. One way to deal with this in an agile environment is to move away from delivering architecture and design in the early phase of the project. That requires to constantly make evolving decisions as you go forward and to re-evaluate decisions as requirements change so there’s a lot more work. Agile has created a situation where you’re empowering self-managed teams to make decisions rapidly for productivity, and if solution architects aren’t embedded in those teams, it can be disruptive and create a lot of unexpected work later.
The Quality Assurance (QA) role is the role responsible for guaranteeing a level of quality for the end client, and to help the software development team to identify problems early in the process. When QA is part of the development process from the initial design phase, they help to drive higher-quality code throughout the process. Ideally, for each developer working on the project with a mental focus on functionality, you have an opposing QA developer with a mental focus on breaking the code and thus making it better.
It is like a disconnected pair-programming where one developer has an emphasis on controlling quality. It is also important that the developers don’t develop the attitude which says, oh well if I leave a bug, it will be caught later and I will get a chance to fix it.
What do you think? Are the roles of the BA, SA, and QA obsoleted? Have they been absorbed into the developers’ job description?