“Where do Business Analysts live in the Agile ecosystem?”, or some variant of this question, is probably the one I am most often asked in my consultancy engagements. It pops up at different times in different places in different Agile adoption initiatives. But almost invariably it will be asked.
Why? Well for a start, the Agile model is supposedly business value-driven. Traditionally, this is the province of Business Analysts. Yet, as a recent book has noted, in the early days at least there seemed to be only two roles: the programmer and the customer (1). In Scrum there are only three roles: the Scrum Master, the Product Owner and the Development Team. Where, oh where then, does the Business Analyst fit in? This is an especially sharp question if BA is your job title, of course, but it is also one of general importance.
The Product Owner Myth
Perhaps we should start with the guess that many people make at the beginning: “The Product Owner is a Business Analyst”. If this means the Product Owner is someone who – at some level – performs business analysis as an activity, I have no objection. The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. That responsibility cannot be executed without a pretty deep understanding of the customers “business model”. But if they are referring to the Business Analyst as a job description then I begin to worry. It is often a clue that the Product Owner role has been misunderstood, and/or that the there is some idea that the Development Team should be getting requirements from someone other than the customer (i.e., by some intermediate professional).
I have discussed elsewhere what is wrong with the idea of the Product Owner being just a go-between running to and fro between customers and developers (2). Let’s take on this myth from another angle by focussing on system requirements.
Ask yourself the question; “Who needs the requirements?”. Not the Product Owner, and not the BA. It is the Development Team that needs the requirements. How else will they know what to build? What is the best way for them to discover them? The principles behind the Agile Manifesto tell us that the most effective form of communication is face-to-face conversation. That should lead us, as night follows day, to the conclusion that the Development Team should be talking directly to the customers. “Engage Customers” has been shown time and again to be an essential organisational pattern for high performing teams (3).
The objection is often thrown in at this point that requirements elicitation and requirements analysis are difficult-to-master skills, and that most programmers do not even have the experience of having met a customer or end user before moving to Agile. But here is another myth at work: the notion that a Development Team is composed entirely of geeks and nerds, i.e. of technical specialists. Scrum requires that the Development Team include people who between them have all the skills necessary to turn Product Backlog Items into product. The Development Team itself needs domain expertise; the Development Team itself needs Business Analysts.
The same research that discovered the “Engage Customers” pattern also threw up another called “Surrogate Customer”. It answers the question, what if the customers are unavailable for direct engagement about requirements? To be extremely clear, this pattern does not advocate a “go between”. It stipulates the creation of someone in the project as someone who will fufill the role, and who will be treated as the customer by the rest of the Development Team. “Most organizations seat the surrogate customer with the development team: in fact this role is often a member of the development team”(4). So, whether as someone who leads the Team to engage the customers directly, or to act as a proxy when customers cannot be engaged directly, the best place for BAs is in the Development Team.
Alternative Living Places
There are potentially two other ways, other than being members of the Development Team, that Business Analysts can engage with Scrum teams. One way is as a member of what might be called a Product Team, which is a group of professionals supporting a Product Owner. They are not themselves members of the Scrum team. Their job is to help the Product Owner, typically when either there is a great complexity in the product, or when the Product Owner is not fully dedicated to the Scrum Team and has other responsibilities in the organization. The Product Team members gather and analyse information, typically at the strategic level and concerned with business processes rather than in detailed systems requirements work (Hopefully we have already established that as the work of the Development Team). However, the Product Team is not a committee which can in any way substitute for the Product Owner. The responsibility and authority of the role must lie with one person for Scrum to work.
Finally, there may be Business Analysts, or other domain experts, whose knowledge is so rarified that it makes no sense to lock them into a single Scrum Team. Their contributions may be required by many Development Teams. In this situation they are best considered “Travellers” whose help can be requested at any time by Scrum Development teams on an “as-needed” basis.
Either – or both- of these two roles can complement that of the requirements specialist embedded in the Development team, but neither is a substitute. Fully cross-functional Development teams are essential for Scrum to be effective. So, far from there being no place for Business Analysts in the Agile ecosystem, there are at least three places in which they can contribute massively to the ongoing delivery of business value to the customer. Learning Tree’s course 3511 Agile Business Analysis is highly recommended for anyone wishing to pursue the subject more deeply.
(1) Janet Gregory and Lisa Crispin. 2014. More AgileTesting: Learning Journeys for the Whole Team. Addison Wesley
(2) Alan O’Callaghan “Eating at the Scrum Café”. http://www.emerald-hill.co.uk/emerald-hill-blog/entry/eating-in-the-scrum-cafe
(3) James O. Coplien and Neil B. Harrison. 2004. Organizational Patterns of Agile Development. Pearson Prentice Hall.
(4) Coplien and Harrison op. cit. p.117