Cross-Team Requirements — Challenges and Opportunities

When developing applications there will be requirements that are needed on more than one application. Examples of such common requirements are non-functional, cookie consent and design patterns. How can we work with these types of requirements in a smart way across several applications and teams, without adding bureaucracy and increased lead time?

It is a common challenge, that we work in silos, developing “our own” application within one organization. Each application has its stakeholders, product owner, scrum master, user experience, business analyst, architect, developers… In the beginning, it’s fine if you only have a few applications running, however, what happens when you have 10 applications running? Consider each product team spending 8 hours analyzing a requirement, that means the organization is potentially wasting 72 hours on each requirement. And not only is it a waste during the initial development, consider the amount of waste during the full life-cycle from that one requirement.

So why do we implement solutions in silos? The answer is that it’s often quicker. We want to deliver with speed to the market, and it’s often easier and faster to do the solution within the team rather than having to rely on other teams, their priorities and time available. Autonomy in all its glory, but sometimes it makes more sense to work across product teams to ensure we work smart and deliver sustainable solutions. And does it really have to take longer just because we work across several product teams?

How can we work smart with cross-team requirements?

How can we in practice work to implement these requirements in a smart way to all relevant applications? There is, of course, the Spotify model, but if it’s too big a change or not the route you want to go down, this could be something to try out.

1. Someone has an idea or are working on a requirement when they realize that this is a requirement that would bring value to other applications within the organization as well.
2. All product owners meet to discuss the requirement, perform a quick analysis to determine if it brings value, if it’s achievable and if it’s a priority right now within the organization. They collaboratively make a decision on how to best move forward, they set a course of action. The course of action might be that it should be developed by two teams that will work together on further analyzing and developing the solution.
3. The two product teams collaborate and do a more thorough analysis to determine the smartest and most sustainable solution for the organization as a whole. Once implemented on one application (possibly as a shared component), the other product teams use the created solution for a “quick” implementation on their applications.
4. The product owners update all product owners on status and inform about the chosen solution that are being implemented so that they can prepare their teams for what’s coming. Once all applications has implemented the requirement the requirement is set to done. The team does a quick retrospective to learn and adapt.

Benefits from working this way

• Transparency and cross-team collaboration
• Smart and cost-effective
• Speed in delivering critical changes on all applications
• Align tech solutions and user experience

What are the prerequisites for a smooth transition to this way of working?

Stakeholder alignment
When delivering software, we deliver something the customer needs, that is technically feasible and sustainable and that works for the business. So why is there still so much politics involved? Most commonly due to team or product bonuses which leads to misalignment, endless discussions and incorrect priorities. Bonuses should only be based on total company success. This makes the decisions easier and everyone working towards one common, unified goal.

We are in this together
Company culture must be about the best for the company in totality. You get rewarded when you work for the best sustainable solution for the whole organization. There are, of course, times where speed is more important than quality, for example when performing proof-of-concept, to allow for early feedback, but then once you know you are building the right thing we need to take a step back and look at the best solution for the company.

Team mission
Teams want to know they are working on creating value, they want to be proud of what they are developing, they want to work smart and rest assured that they are contributing to the overall organization in the best way possible. Contribution to the bigger picture has to be part of the culture and be part of each teams mission statement, cross-team collaboration should be noticed and rewarded.

Let data and learning lead the decisions
The challenge with working across teams is that more people are involved which leads to more opinions and ultimately to longer lead times. But with an agile mindset, basing the decisions on data and learning, it shouldn’t have to end up with endless discussions. The requirement that brings highest value is the one we work on first and the team that will tackle the initial solution is the team that is most fit to do so at that moment in time.

It’s important to clarify, that not everything is a common requirement. Your organization needs to decide what is and what is not; it should only be treated as a common requirement if it brings value by analyzing and delivering them in a cross-team collaborative way.

I would love to hear your story

If you have faced or are facing a similar challenge, I would love to hear your story.