Everyone knows that working in cross-functional, autonomous teams is the most effective way to ensure agile product delivery, but in bigger organizations (and when trying to build complex IT systems) this can be hard. Dependencies between teams still cause integration pains and priority conflicts which lead to high planning and coordination efforts and a waste in development.
We often see companies use modern software engineering techniques like CI/CD in combination with frameworks like SAFe to try and tackle dependency and integration chaos. However, this rarely addresses the root cause of these problems.
All too often:
Requirements continue to be broken down with a technical focus — e.g. by components rather than focusing on value creation.
Team structures and boundaries are defined by existing reporting and power structures rather than based on an architecture that’s actually needed.
Product owners lack the capabilities (particularly in product thinking) and necessary empowerment to make decisions about how teams can best contribute to outcomes.
The overall goal for the system isn’t broken down into smaller increments that deliver value early. If shorter planning cycles are run — as in program increment (PI) planning in SAFe — the goals aren’t expressed in terms of business outcome and are not cascaded down into the teams. Although progress may be tracked by doing reviews at the end of the PI Planning cycle, there is little focus on trying to gain a better insight into the performance of the overall working system.
In short, if companies are to properly address the root causes of slow and ineffective delivery — across multiple teams — and increase the flow of value to their customers, they need to introduce modern software engineering techniques and make changes in their organizational structure and operating model. While such an approach is more effective, it is arguably less efficient. If you care more about cost, you don’t want to do this.
Let’s take a look at the key things that need to be done.
Develop a shared understanding of the entire system, then break it down into distinct domains each with a clear focus on a specific value.
Conway’s Law states that organizations tend to produce systems that mirror their communication structures. Your system and your organization should be designed in such a way that both are not pushing against each other. If you are aiming for an organization that’s capable of fast and agile delivery, you need to design an architecture that’s made up of loosely coupled and highly cohesive services organized around domains.
How you decompose your system will determine the team structures required. By forming value-stream aligned teams around distinct domains, you minimize the need for component teams, enhancing flow optimization (see the book Team Topologies). This approach reduces the communication overheads caused by lots of dependencies, and lets teams focus on incremental value delivery with faster flow.
Establish multi-disciplinary teams that have end-to-end responsibility for the outcome that they contribute to the overall system.
Once you have clarity on the distinct boundaries of your domains, you can establish cross-functional teams capable of delivering specific outcomes with as few dependencies as possible. Make sure these teams are small and customer-focused rather than activity or skill-based teams where product, software and operations people are all in separate organizations. That slows you down and makes you less responsive due to information complexity and high-bandwidth communication up the organization. The benefit of value-stream aligned teams is not just multidisciplinarity; they are also more autonomous. They can operate independently, iterate quickly and take ownership of their work. This will ultimately lead to faster and more effective delivery.
Empower strong product owners that own outcomes and are incentivized to contribute to the overall expected outcome.
Product owners should lead the vision, strategy and roadmap for the products and should also be outcome-focussed. They leverage market, competitor and user research to guide prioritization, and are adept at defining and measuring lagging and leading indicators of success. Ultimately, they should align with the business's overall goals and assess the team's initiatives' viability.
These expectations may be unfamiliar, especially for new product owners in technical domains. This is why it’s important to choose individuals with the right mindset who are eager to learn product thinking. It’s also worth emphasizing product-oriented thinking over technical expertise, even in technical product contexts.
Track expected outcomes in value increments through lightweight governance.
When developing a complex system it’s impossible to uncover every challenge even with the most in-depth upfront analysis. One way of dealing with this is by implementing governance that emphasizes incorporating customer feedback, active leadership engagement and responding to changes and learnings.
Another challenge can arise when teams begin to embrace working autonomously. They start implementing local optimizations which can lead to inefficiencies. The key is that the governance approach should make sure that the overall work is broken down into value increments per domain and then broken down further into value increments per team in regular time intervals. This creates a shared sense of purpose across teams and guides them towards the same goal. Progress can then be tracked using the working system (where all components will be continuously integrated) as the primary measure of progress.
Those responsible for steering the overall program need to facilitate feedback and prioritization discussions, and should encourage the leadership to adapt to internal insights or changes in the external environment.
Conclusion
Introducing significant changes to your organizational structures and operating model takes time and cannot be achieved in one big bang. At the same time, however, organizations are today experiencing increased pressure.
While the approach outlined above is more effective in reducing dependencies and thus decreasing time-to-market, it is less efficient in terms of required resources. The increased cost pressure in the current economic climate explains the popularity of approaches like SAFe — a promise that through an elaborate framework the challenges that come with delivering a complex system can be managed efficiently while making significant changes to the way the organization operates.
We advocate for taking a holistic approach. First, you need to understand the current state of your organization and then identify what changes need to happen across all horizons — structural, operational and technical. Once you’ve done that, you can then take an incremental approach to implementing the necessary changes and be more deliberate in selecting particular elements of frameworks that will help you manage your specific challenges.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
