SAFe, are developers required to gather their own requirements?

Question

Recently at our company, the management decided to implement SAFe. Things have changed quite a bit since then for better or worse.

One of the major changes we have noticed as a developer is the burden of doing requirements gathering. While we are not against asking questions, clarifying items in the acceptance criteria, but are expected to gather all requirements for a feature.

When a feature is broken into several user stories and each user story is picked up by developers, the requirements at that point is very fuzzy and creates a lot of confusion among developers. One developer comes up with one solution, another with a different solution and so on. For about half the sprint, we get dogged on trying to figure out how the process really works.

We have Scrum Masters (previously known as Business Analysts). With the new title change, scrum masters say they do not assist with requirements gathering anymore. Previously, Business Analysts used to identify how the process worked, create flowcharts where necessary and developers used to assist them on technical side to make sure things would work out fine.

What are we doing wrong here?

Answer 1

TL;DR

Your company has not implemented SAFe; they have implemented Buzzword Management™. In this case, the interplay between roles has been applied incorrectly. Core responsibility for requirements management is a product ownership function, but the development team has a collaborative role to play, too.

The Scrum Master's role is to be the process referee for the framework, and to make sure that everyone else on the Agile Team is able to effectively implement their roles. This isn't currently being done, either.

Product Ownership Roles in SAFe

While SAFe development teams are primarily involved in decomposing Features into User Stories or other types of actionable backlog items, the core responsibility for requirements gathering is split between the Product Management and Solution Management functions.

Product Management has content authority for the Program Backlog. They are responsible for identifying Customer needs, prioritizing Features, guiding the work through the Program Kanban and developing the program Vision and Roadmap.

Solution Management has content authority for the Solution Backlog. They work with customers to understand their needs, prioritize Capabilities, create the Solution vision and roadmap, define requirements, and guide work through the Solution Kanban.

There's also a SAFe Requirements Model, that says that "Agile Teams primarily employ user stories, story acceptance tests, and NFRs [Non-Functional Requirements]" which puts most of the responsibility for product ownership and requirements management into the hands of Product Management and Solutions Management.

Furthermore, consider the varying levels of product management roles within SAFe:

SAFe offers a chain of content authority that spans three levels:

1. Team – Product Owners make fast, local content decisions on behalf of the Agile Team.
2. Program – Product Management is accountable for content decisions for the Agile Release Trains (ARTs)
3. Large Solution – Solution Management has content authority for Solution Trains

That means each Agile Team's Product Owner is responsible for managing that team's portion of the overall Product Backlog. This includes gathering requirements from stakeholders/customers, and prioritizing backlog items.

And Yet SAFe is a Team Sport

With all of the above said, that doesn't mean the Agile Team developers aren't involved in understanding or gathering requirements. User stories and Product Backlog Items are not specifications. They are placeholders for collaboration with other elements of the Agile Release Train.

The Product Owner may be the primary point of contact, but the team as a whole should be actively engaged with the stakeholders who are called out as value consumers in a user story. If the Product Owner is not facilitating this, or is placing the responsibility solely on the team, that is a role failure. Likewise, if the team is sitting back and waiting for full-fledged specifications from the Product Owner, the Agile Team isn't fulfilling its proper role either.

Agile frameworks, especially Scrum (on which a number of SAFe practices are based), require active collaboration between roles. If the roles are in conflict, or individuals are seeking to "toss work over the wall" to someone else, then the framework has not been fully adopted or properly applied.

Answer 2

I'm going to assume that you don't have any Product Owners (POs).

Going from Business Analyst (BA) to Scrum Master (SM) is a bit of a weird change. The job of BA is much more similar to the job of PO than it is to the job of SM.

There is some debate out there as to whether or not it's a good idea to have a dedicated SM or a developer/SM. However, to me, it makes much more sense to pick some developers, teach them Scrum, and make them SMs than to pick some developers and try to make them POs.

If the former-BAs want to remain as SMs, then you'll need to hire some POs (or train some devs to switch to being POs then hire new devs). If the business just doesn't want developers being SMs, then they need to hire some dedicated POs (or change the SMs to be POs and hire dedicated SMs).

Answer 3

What are we doing wrong here?

A lot.

Typically, in SAFe, your development teams are running some combination of Scrum, XP, and Kanban. There's no real requirements as to the specific methodology, though. However, the idea of iterations and increments feed into the overall SAFe approach.

Requirements tend to flow down - Strategic Themes come from the strategy of the Enterprise; Solution Management is working at the Large Program level on Capabilities and Enablers; Product Management is working on Increment Objectives, Features, and Enablers; Product Owners are working on Stories and Enablers. Of course, these people aren't working on requirements in isolation, but with some technical support. Solution Architects support Solution Management, System Architects support Product Management, and the Dev Team supports Product Owners.

Not everything needs to explicitly flow down from the top. Some things may be technical work that becomes apparent at one level, but is too in the weeds for the level above it. But this decomposed and enabling work can be detected as the work to be done is fleshed out at every level.

To me, it sounds like the Product Managers and Product Owners are not developing strong Program Increments, Enablers, Features, and Stories. There should be refinement activities at each level that are addressing these vague and unclear requirements and to ensure that there's enough information for everyone to be on the same page.

---

The fact that Business Analysts became Scrum Masters is also slightly concerning. In my experience, BAs (which may have a number of other names in different organizations) typically support a product management organization, and not a development organization. On a team, the Scrum Master role is, in some ways, directly opposed to the Product Owner - the Product Owner seeks to optimize the value delivered by the Development Team while the Scrum Master helps to team to optimize their own performance. Sometimes, optimizing the team means slowing down the delivery of a product.

Answer 4

The functional requirement needs to be provided by the Product Owner or Product Manager. The developers are only responsible for designing the functionality technically in collaboration with the PO/PM on the functional and usability perspective.