Three Pitfalls to Consider Before Decentralizing Your Development

DZone 's Guide to

Three Pitfalls to Consider Before Decentralizing Your Development

Learn about some of the risk and considerations for hosting decentralized development, and why value stream managmenet might be the answer.

· Cloud Zone ·
Free Resource

Everyone gets excited when they get something new. Whether it be a new phone, a new car or even a new software application, the first instinct is often to completely immerse yourself in it and figure out how to make it a part of your life. 

This is also how I’ve seen many companies manage new methodologies and processes — specifically, Agile and DevOps at scale. After deciding to embrace the ways of working, organizations tend to make sweeping changes like splitting up teams, creating new autonomous, product-oriented teams, getting rid of project and release managers, and moving everyone else to cross-functional teams.

Oftentimes, these changes can lead to chaos because the decision essentially attempts to eliminate the safety net and leaves teams to navigate risk on their own. Now, the people tasked with managing the development pipelines are left to cross their fingers and hope the new process is successful. Additionally, the new changes leave the architectures in a state of flux since team members are uncertain how to navigate the new architectures, and the security provided by the release managing groups is gone. 

While there are benefits to decentralizing your development, there are also pitfalls to look out for, especially around your risk, dependencies and governance.


Despite creating autonomous teams and empowering them, it can still be a struggle to pinpoint exactly who owns the risk of delivery. In a perfect world, it would be the product owner. However, this is often not made clear to the new cross-functional team, which creates more risk for the company as a whole because when something goes wrong, it can have negative consequences for everyone, not just the team. To avoid that kind of situation, it’s imperative that the team understands the risk of delivery and who owns it. Once ownership has been established, you can effectively start managing the risk.


When teams are decentralized but the application is not, the standard operating procedure for managing dependencies is changed, which can result in a breakdown of communication. Changing even one thing for product-centric teams can have ripple effects for other teams because the existing products still have code and functional dependencies. While teams have been decentralized, the applications have likely not been changed. This means if someone makes a change to an application, it can affect other things such as how to test a scenario or how to make sure value is being delivered. 

You must make sure everything is working together, even in situations where the team is releasing dark at a specific time. This is especially important because customers don’t care about the back-end details; they care about functionality, the user experience and a cohesive solution. Online shopping is a great example of this. No matter what page they visit, they expect the shopping cart to be in the same location, or you risk losing that business. 


Decentralizing your teams can also create issues around your governance and regulatory compliance processes. It’s common for teams to lose sight of a broader view and fall out of touch with their organization’s governance and compliance guidelines as those teams become more autonomous, smaller and more focused. However, your customers still depend on these teams to deliver the product they need while the business needs them to continue to mitigate risk by adhering to required governance.

Individual teams have the ability to check on their own status, but they lack the visibility, time, and resources to see how the larger team is fairing. This means the responsibility falls squarely onto the shoulders of the portfolio manager to pinpoint which teams present the biggest risks and need the most improvement. With the safety net eliminated, there needs to be a system in place to keep teams from drifting, and it needs to be better than a portfolio manager all of a sudden realizing a team isn’t meeting requirements and creating risk. For example, a healthcare company we work with can face fines of up to a million dollars a day for non-compliance issues. This proves the importance of having visibility into the larger team and why it's important to know why remaining compliant is absolutely critical to all business functionalities.

The Answer is Value Stream Management 

Luckily, these problems can be solved with value stream management (VSM). One of the principal benefits of VSM is that it provides visibility and makes it easier for individual teams to be on the same page. It does this by allowing collaboration and streamlining efficiencies, so all teams can access the end-to-end metrics as well as having an overall view into the health of software development and delivery. VSM also manages governance by employing workflow and orchestration techniques, which ensure continuous compliance every step of the way.

VSM gives organizations the ability to map initiatives across teams to understand the dependencies and know what will be delivered. Individual teams can also deliver metrics at every phase of the software delivery pipeline by using VSM analytics and business intelligence.

Without VSM guiding teams from being project-oriented into their ideal product-oriented state, organizations are heading down the path towards a potential disaster. And these pitfalls will be immediate signs of the trouble that lies ahead.

decentralization, governance, risk, value stream management

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}