How are Agile roles actually implemented in the real world…?

It’s no secret that Organisations differ in their implementation of the various Agile ‘roles’ (where multiple ‘roles’ are often undertaken by the same person or where multiple individuals share a given ‘role’). This variation depends particularly on the type of Organisation – but ‘each to their own’ is almost a Universal Constant.

I get the impression from the various conversations in various BA discussion forums that real-world implementations of Agile structures within Organisations are as variable as the Organisations themselves. There may be no such thing as ‘pure’ Agile, in the same way that ‘pure’ Waterfall is probably only really a theoretical construct. In reality, almost every Organisation will adopt – and adapt – multiple processes & techniques from multiple methodologies as appropriate to their individual needs. In other words, “if it works, it’s right”.

Given this attitude, it seems logical that each Organisation defines the activities that each ‘role’ should undertake. However, this can lead to confusion and a lack of clarity about who should be doing what. For example, for those who suggest that the Product Owner defines the features that are to actually be developed (in other words, a gatekeeper / prioritisation role), then what role does the Product Manager play in these scenarios, if any? If a Business Analyst takes the role of ‘Customer Advocate’, then surely that BA is the arbiter of what constitutes ‘value’..? If that is the case, and if value is the key prioritisation attribute in Agile, should the BA be a gatekeeper to the Sprint? Or should there only be a Product Owner who also acts as BA? Similarly, where does the Business Analyst actually ‘sit’ in an Agile scenario? Do you see only one BA (in the Dev Team) or one BA (in the Product team) or do you see two BAs – or more – who collaborate?

Is it different, in your experience, if the Organisation is a software development business compared to other sector? In recent years, Agile methodologies have taken root in software development Organisations in particular. Although Agile ‘philosophies’ are not limited to software Vendors, it does seem as if there are often more ‘mature’ and ‘separated’ Agile-type structures where the Organisation develops software.

By way of example, the following hypothetical scenario is devised from various engagements I have been involved in over the last 5-6 years…

NewCo (made-up name, of course!) has developed software for Corporate payment processing, document archiving and electronic file transfer systems for many years. They are particularly expert in developing functionality for all things privacy-related and there is a huge knowledge of the various rules / regulations that must be complied with. Software is developed using the Scrum method.

There are separate ‘Product’ teams for each of the product areas. Each Product team has one or more BAs and a Product Manager. Although they would be aware of the technical capabilities and features of the range of Products, these are not necessarily technical (i.e Coder or Developer) people, being focused instead on Product features from a Market, Customer or Business perspective. The Product Teams (Product Managers & Business Analysts) define what high-level features the Products should ideally have and what rules & regulations the Products must comply with. This team prioritises the features according to the needs of the Market / Sector / Customer but they accept that other factors might affect actual delivery timeframe.

There is also a Product Owner. Their job is to manage the process of getting Epics and User Stories onto the Product Backlog, once they have been started by the Product Team, and then ensuring they are adequately defined before then ‘feeding’ them into the Elaboration Sessions, Estimation Sessions and eventually onto the Sprint Backlog. The Product Owner is also aware of the multiple Development teams available and the various speciality skills available in the Organisation and this helps to identify the best team (and shared resources needed) to allocate development of individual features to. They also monitor the delivery of these features, once the Sprint starts, similar to a project manager.

There are a number of different Agile Development teams, some in remote offices and some in the same office as the Product teams. Each team has Developers, QAs, Architects etc.

A Scrum Master oversees multiple teams and collaborates closely with the Product Owner when planning an upcoming Sprint. The Scrum Master manages the daily Stand Up, the (re)allocation of tasks within the Sprint Development Team and is responsible for addressing any issues that arise, often requiring access to expertise outside the Dev Team. As such, the Scrum Master performs a similar role (in addressing issues) as a Business Analyst or Product Manager but only in issues that arise from User Stories currently being implemented (e.g. In-Sprint, not on the Product Backlog).

There are also shared specialist resources with expertise in areas such as DBA, Security and System Architecture, who are co-opted and queried as and when necessary, by either the Product teams (for Analysis & Elaboration) or the Dev teams (for Estimation and Implementation advice).

The BAs in the Product Team and the BAs in the Agile Development Team collaborate to ensure Product features are adequately defined & clarified, as required, in order for the Dev team to be able to estimate – with relative clarity – what the Product team actually requires. They act as a ‘bridge’ or ‘interpreter’ between Requirements and Deliverables. Often, the Product BAs sit in on the Dev teams’ Estimation Sessions. This is an important role for a BA to play as it means clarifications or alternative suggestions raised during Estimation by the Dev team (who have no prior knowledge of the individual User Stories to be Estimated) are dealt with quickly and effectively rather than being sent back for input and maybe missing the Estimation cycle for an upcoming Sprint.

After each Sprint, the Scrum Master, the Product Owner and perhaps the BA / Product Team convene to review the Velocity of the previous Sprint, the Capacity originally planned for, the pre-Sprint Estimated size of the User Stories developed (using any appropriate metric), any post-Sprint re-Estimate of User Stories ‘actual’ size (to avoid incorrect Estimates of similar stories later) and anything that could be changed (before or during future Sprints) to make future work more effective and efficient.

Of course, this is only one possible arrangement. My personal experience over recent years suggests that a setup like this would work very well, especially once the two collaborative BAs (one in the Dev team and one Product-or Customer-focussed) had come to understand the ‘modus operandi’ of each other. For this reason, the two BAs should be often & repeatedly ‘paired’ over time to develop a shared understanding, thereby minimizing miscommunication and misunderstanding. A particular team should regularly develop the User Stories defined by a particular Product BA – meaning that it became easier over time, due to familiarity, to explain / understand what is required, making Estimation more efficient & effective and ensuring that the Product Team has a more direct and immediate understanding of what is to be implemented.

Of course, this is a hypothetical scenario and it may be completely unworkable in some cases, either due to resource constraints or (perhaps the opposite problem, in a way) scaling Agile for larger Organisations. However, noting that multiple ‘roles’ outlined above could actually be carried out by either one person (for smaller, resource limited Organisations) or could be shared horizontally among similarly-skilled individuals (for larger Organisations), the actual structure itself is not difficult to adopt – and adapt – to the needs of most Organisations.

——–

If you have any comment on the above, or take issue with anything suggested above (which I would encourage!), feel free to comment!