Mending the rift between business stakeholders and development teams

Introduction

How often can your organization boast about getting a steady and predictable flow of productivity?

In today’s business world, the synergy between stakeholders, product management and development teams are paramount. A pleasant collaboration ensures smooth processes and timely deliveries with high-quality output. However, in practice this desired synergy is often elusive, in worst cases leading to a siloed work environment.

Let’s talk about one situation where the apparent productivity masked an underlying discord, and how Xebia tried to locate and improve the situation.

Customer’s problem

At one of our major clients at Xebia customers complained, that the project velocity was inconsistent, while the development team seemed perpetually busy. For instance, in one week the development team might complete five major features, while in another, they might struggle to finish just two despite similar workloads. The business was often dissatisfied with the development team and their slow progress – and the feeling was mutual from the development team, who commented how the business seemed to lack active involvement, often missing key meetings, and not providing necessary resources.

Upon joining the project, and talking to parties involved, Xebia started gathering hard cold data – by looking at activity metrics in client’s issue tracker (JIRA) and commit histories in their version control system (GIT). The initial goal was to find conflicting or supportive evidence to what was heard from the project’s participants.

It was revealed that significant chunks of work were wasted and thrown away. Often, work that was primed for production had to be entirely redone:

• This was primarily because, during the Sprint reviews, stakeholders found the work unsuitable for production. As a result, a significant amount of the initial work was abandoned and had to be recreated, whether the issues stemmed from UI, UX, or inaccuracies in data presentation.
• More troubling, however, was the inefficiency that permeated the entire process. Not only did the development team expend valuable time on features that failed to gain approval, but the product team also faced setbacks. They invested substantial effort in preparing, refining, and detailing user stories, only to find that half of them never progressed to the implementation phase.

Upon closer inspection and digging deeper in the sessions together with the members of the development team, these reiterations were attributed to the following root-causes:

• Ambiguous Requirements: Often, the specifications given to the development team were unclear. Without clear guidelines, the product owner and developers had to make assumptions which sometimes diverged from the stakeholders’ expectations. And the stakeholders were often “too busy” or far away to clarify them.
• Lack of Regular Communication: The channels of communication between the stakeholders and the developers were infrequent and irregular and were mostly carried via comments in JIRA or email correspondence via a Product Owner. This meant that misconceptions or misunderstandings were not clarified in a timely manner, leading to more work than necessary.
• Feedback Delays: When the development team did finish a (part of a) feature or module, there were significant delays in receiving feedback. This often resulted in the team moving forward on a mistaken premise and only receiving their feedback at the Sprint review at the end of the sprint.
• Changing Priorities: The business side sometimes altered their priorities mid-development, leading to previously important tasks becoming redundant, and therefore causing the development team to shift focus and discard the work they had done.
• Absence of a Mediating Role: In many successful projects, a business analyst or a product owner acts as a bridge between the technical team and the business stakeholders. More importantly, they act as a gatekeeper and a person who can decide over accepting or refusing a request, request clarifications or conformance to standards. In this scenario this person was not effective enough, performing more like a secretary or planner, rather than owning a product.

Improvement approach

Although the process was clearly there (at least on paper), the team still suffered from poor performance and predictability of their planning. To address and overcome the challenges, Xebia implemented the following measures together with the client:

1. Strengthened the Mediator Role: the product owner and business analysts took a training to refresh their understanding of their responsibilities and their mandate. Next to that, we recruited management’s support in making sure that the PO has the power to make decisions and demand availability from the stakeholders when they were needed.
2. Refined Requirement Documentation: we conducted several workshops on “Specification by Example” – a collaborative approach to defining requirements and business-oriented functional tests, together with the development team and the stakeholders. Participants managed to learn about each other’s expectations and agreed on formats and rules for their requirement requests. As a result, the ambiguity in task refinement dropped significantly, leading to more accurate development estimation and easier planning.
3. Enforced Requirement gathering format and associated process: following the workshop, we implemented (and enforced) a standardized requirement gathering process together with a common template. We actively guided the initial refinement sessions to make sure that everyone from business stakeholders to PO understood, followed and adhered to the same process and format. This not only streamlined the process of gathering requirements but also made sure that everyone, from developers to stakeholders, understood and interpreted the requirements in the same way. As a result, there was a significant reduction in back-and-forth communication and rework due to misunderstandings.
4. Established Regular Communication Channels: we initiated a temporary (running 6 weeks) weekly stand-up meetings between the development team and stakeholders (facilitated by the PO) to demo work in progress and collect feedback. Following this temporary work-around, stakeholders and PO started to communicate more frequently and regularly to align on the progress.

Conclusion

The disconnect between business stakeholders and development teams can have profound impacts on a project’s success, leading to wasted efforts, delays, and overall dissatisfaction. This friction is often rooted in ambiguous requirements, inconsistent communication, shifting priorities, and might be worsened by delayed feedback and the absence of an empowered mediating role or lack of strong direction from the leadership.

The most difficult part here is recognizing where the root cases originate from. In this situation, Xebia successfully helped the client to address the root causes of their troubles and fix them. However, the data and all the necessary information was already there – and some examples of the insights you can get from it, you can get from this wonderful article by Lennart Tange.

Through careful observation of the operational chain and identification of roadblocks, many companies can self-improve, provided there’s both the will and the need. So being proactive can prevent many of these issues from arising. Emphasizing clear communication, fast feedback and ensuring easily accessible observability of your end-to-end process are some of the best preventive solutions that you can take.

This blog is part of our series "Holistic Horizons". Check out the previous entry – "API Security is more than testing” by Yianna Paris. Or read further to the next article – "Insights from your JIRA data to help improve your team" by Lennart Tange.