What practices would allow an Agile team to work effectively when every developer is allowed to gather requirements from the business customers?

Question

I may possibly inherit a new team which had toyed with Scrum but not found it the correct approach (largely due to the parallel not sequential nature of business projects).

They are working to a fairly effective Kanban system but the development team are unhappy. In previous roles they worked closely with customers and now they are just developers (their words) who report to a Product Owner of Project Manager who articulates the customer requirements.

Unfortunately this has led to a number of project delays as technical information or warnings from the developers are ignored until the Project Manager must return with their tail between their legs to the business customer and explain the timelines were unrealistic.

I have been asked to explore the feasibility of a development team where each developer could theoretically be assigned to a number of projects and be heavily embedded in the requirements gathering and backlog generation alongside the Project Manager or Product Owner. The management want to know if such an approach is still "Agile" which seems to be a fixation.

The senior Product Owner would still decide the priority of the projects coming into the environment but the developers would be responsible for the priority of tasks within each project in conjunction with a PM/Deputy PO.

What practices would lead to the potential success of such a system?

TL:DR

• Cross Functional 10 Man Development Team
• Full Stack Developers
• 3 Tier Environment
• Multiple ongoing high priority projects
• Current system is Kanban
• Toyed with Scrum
• Developers have no contact with business customers apart from occasional Sprint Review
• Customers hail from all business functions
• Project Managers are non-technical often ignoring development wisdom
• Management wish to explore Agile solution whereby;
• Developers can approach customers directly in conjunction with Product Owner
• Each User Story card is owned by a single developer

Considerations

I know the temptation for some may be to fixate on the "Scrum did not work part" or the "developer is unhappy part" of the question but I gave that information for context. I feel confident in turning around the morale of the team and improving each individual's self worth. I am keen to explore whether a former Scrum team can survive when each developer is allowed to gather / re-prioritise requirements alongside a Product Owner.

Edit to Add

I know this question is somewhat theoretical and a bit more heavy than the normal fare at SE.PM but I felt if anyone could crowd source the cost-benefit of such an approach it would be here. :-)

Answer 1

TL;DR

I think the question of "requirements gathering" is based on a misunderstanding of the agile principles involved, and especially of how user stories are created and how the details of a story should be fleshed out into an implementation. Simply re-framing everyone's expectations properly may help a great deal.

While it may not be feasible to have 10 developers acting as business analysts simultaneously, there is no reason that developers can't be involved in the story-writing process, in backlog refinement discussions, or in collaborating directly with customers. In fact, the Agile Manifesto explicitly declares customer collaboration to be a core value, but leaves it up to the framework and the team to identify the best ways to implement such collaboration.

I offer some analysis in the next section, and some practical recommendations for collaborating effectively in the final section below.

Stories as Conversation Placeholders

A user story is not a specification or a set of requirements (see "Advantages of User Stories for Requirements" § User Stories Aren't Requirements Statements). Rather, a user story is a structured placeholder for a conversation about how to best implement a given feature.

Even within Scrum, which has a fairly rigid definition of roles within the Scrum Team, there is nothing in the description of the Product Owner role which prevents the Development Team from clarifying the intent of a user story or collaborating with the customer directly. The Product Owner should be involved in gathering requirements and developing user stories so that he can prioritize the Product Backlog properly, but this is supposed to be a way of structuring project priorities rather than a communications barrier.

The Scrum Guide says:

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.

The focus here is on prioritization of stories and, by extension, allocation of project resources for each iteration. The common use of the Product Owner as a communications proxy for an absent customer is certainly not mandated by the framework.

In fact, in Extreme Programming the customer should always be available to the team. Further, they are expected to actively collaborate with the development team, as illustrated by this direct quote:

Because details are left off the user stories the developers will need to talk with customers to get enough detail to complete a programming task. Projects of any significant size will require a full time commitment from the customer.

Requirements must be gathered, but it is up to each project to determine how that should happen. The important thing is that the user stories aren't treated as fixed requirements or detailed specifications, but rather as well-framed context for further elaboration and collaboration with the customer.

Practical Recommendations

• A desire to gather one's own requirements is often a project smell that indicates a desire to avoid being held accountable for management targets or imperfect communications. This may indicate a fundamental trust or process issue that should be addressed by the whole organization.
• Developers should help write user stories when this improves the story-writing process, but this must be determined on a team-by-team basis. A lot depends on the agile maturity level of the team.
• The Product Owner must remain the single arbiter of priority for the Product Backlog or story queue.
• Stakeholders must work through the Product Owner to manage the priorities and resource allocations for a project.
• Customers should collaborate directly with developers whenever feasible; proxy communications are simply a fallback for situations where tight feedback loops aren't feasible.
• Sprint Reviews are the last possible moment to gather feedback within an iteration, but they aren't the last responsible moment. Tighter feedback loops are usually better.
• Customer collaboration throughout the iteration is preferable, provided that it doesn't invisibly change the goal or scope of the current iteration. Changes to scope must be addressed through the framework, not via side-channels.

Answer 2

Customer collaboration throughout the iteration is preferable, provided that it doesn't invisibly change the goal or scope of the current iteration. Changes to scope must be addressed through the framework, not via side-channels.

This point can be made even a bit more general and independent of framework. The concern is the possibility that side-channel communications could circumvent existing agreements or introduce conflicting requirements, ie, requirements that meet the needs of one stakeholder without regard for the effect on other stakeholders or on the user experience of the system as a whole.

This risk can be mitigated by keeping the appropriate persons (product owner, project manager) in the loop: not necessarily present at every meeting but aware of the general topics discussed.

For example: on one of my projects, I'm the dev lead, and I have a counterpart who is the customer lead. Customers are encouraged to communicate directly with me and with my devs -- which they prefer, because it's more efficient -- as long as they keep their lead in the loop. Occasionally they forget, and I bring her in. (We do a lot by email, so it's easy enough to cc the appropriate folks.) She knows the big picture on the customer side, and I know it on the dev side. There's an explicit agreement in place that nothing gets committed to without signoff from both of us. On the rare occasion that we can't come to agreement, we go to upper management & let them decide. It's informal & effective.

Answer 3

Interesting situation. My greatest concern from reading the scenario is that you have 1 person (a developer) wearing multiple hats (BA, PO, tester?) with potentially very little accountability.

Foremost thing for this type of environment would be to ensure everything is very transparent and help developers avoid the pitfall of drifting from being a team to a working group with silo'd ownership of stories.

I'd probably look at doing some form of Scrum-ban. Story sized backlogs but working off a kanban board with WIP limits and close attention to cycle times on each bucket of story point. I'd also probably go pretty granular on the kanban board to clearly layout what's happening in process areas where each specialty does their work.

product owner visioning and prioritizing, business analyst detailing, developer pre-committed code, developer post-committed code, manual QA, and whatever staging or integration activities that are supported as well.

I'd look at using the 3 Scrum ceremonies, but consider flexing the iteration duration by up to a week so that the team could adjust to rapidly shifting priorities. Depending on the maturity of the team, retrospectives/reviews could be more informal.

Finally I'd bucket work into high medium and low priorities instead of ranking, and put limits on how many high priority stores can be in an iteration to force constant discussion on what is most important to accomplish during the iteration.