Scrum has taken the agile landscape space. According to VersionOne 13th State of Agile Report [1]: 54% of agile projects uses Scrum (against 1% using XP and 5% using Kanban).
The Scrum framework prescribes three roles: ScrumMaster (SM), Product Owner (PO) and team member.
SM is the facilitator, the person familiar with the Scrum framework that should help the Scrum team to reach their Sprint goals by fostering a great teamwork and by removing the blockers that might show up. The SM main goal is to deliver the thing right. The focus is on teamwork efficiency.
The PO’s main responsibilities are: (1) to manage the Product Backlog, (2) to maintain the communication with the business stakeholders and (3) to answer the team’s questions about the work related to the product features under creation. The PO main goal is to ensure the team delivers the right thing. The focus is on product results and efficacy.
Anyone else on the team is a Scrum team member: a person, either a specialised or a cross-functional type of professional, helping the team towards the Sprint goals. Typically, Scrum team members are dedicated to one and only Scrum team. The focus is teamwork for doing the right thing and doing it right.
Back on the days, at least on the 90s, there was the traditional Analysis phase [2]. With it, there was a role named Business Analyst (BA).
But, from 2000 onwards, there were the early agile companies: Influenced by Agile, these companies demanded the “business” (or product) people to work in a more agile fashion. They should know how to work with Agile requirements, and they should be available for the team.
The reality, in the beginning of the century the typical businesspeople did not know how to work with agile requirements. Typically, the businesspeople were not available to the “technical” team (to sit with the developers, on the same table if possible, all day!)
So, what happened? Some of these BA learned how to work with the agile teams.
Back in 2006 when I started coaching about agile, I thought it made lots of sense. I used to think “a modern BA works the agile way, while a traditional BA works in a more waterfall style”.
Before 2006, it was very difficult to find BAs that had hands-on agile experience. But as agile and Scrum got famous, many companies and consultancies were also getting experienced with how to handle the business requirements on an agile way.
The division between Mode 1 (waterfall) or Mode 2 (agile) became more apparent. Gartner even published a famous paper on the bimodal IT on 2011 [3].
But here is the mismatch, the role name confusion.
The PO role shows up as a Mode 2, agile way of working, while the BA role was viewed as a role on Mode 1. That is the confusion. These days, many companies are using agile (Mode 2), but still using a Mode 1 denomination: BA.
That’s the confusion. That’s the mixed message. The world has changed. The majority of agile companies the Scrum framework vocabulary: Daily, Retrospective, Sprint, PO, etc.
Therefore, my post title and advice: on Agile teams, use the name PO instead of BA; this reduces the confusion and ambiguity on these roles definition.
Looking forward to you feedback and great comments to this (very) sensitive topic.
References:
[1] VersionOne 13th State of Agile Report (2019);
[2] Project Management: Best Practices for IT Professionals, 1st edition (2000); https://www.oreilly.com/library/view/project-management-best/0130219142/ch07.html
[3] Achieving Enterprise Agility through Bimodal Transformation, Gartner.com (2011); https://www.gartner.com/imagesrv/media-products/pdf/ALTIMETRIK/Altimetrik-1-354WZ5A.pdf
