If you’re a software developer working for a big enterprise, chances are high that whenever you need to provision a database, or a build pipeline, or an SSL certificate, or pretty much any piece of infrastructure, you have to submit a ticket to another specialized team so they can do it for you. Then you wait. And wait. In the meantime, the story you were supposed to be working on is blocked until the required piece of infrastructure is provisioned for you. In such a scenario, the infrastructure teams are a bottleneck to the delivery teams’ software delivery life cycle (SDLC).

If you’re a software developer working for a big enterprise, chances are high that whenever you are done implementing a (big) chunk of functionality and are ready to deploy it to production, you have to wait for a separate team of QAs (testers) to check your code for bugs. Then you wait. And wait. After a few days (or weeks), you get a report with all the bugs that need fixing. Then you fix them. Then you wait again for another round of tests to be completed. This cycle repeats over and over until the number and/or types of bugs meet a desired threshold. In such a scenario, the QA teams are a bottleneck to the delivery teams’ SDLC.

If you’re a software developer working for a big enterprise, chances are high that whenever you want to deploy your application(s) to production, you have to fill a bunch of forms and/or spreadsheets with details about your application, have meetings with governance and operations teams to explain what your application does and/or which changes it introduces. Finally, you submit a ticket to the operations team so they can deploy your application for you. This cycle repeats over and over until operations and governance teams are satisfied with the information you’ve provided. In such a scenario, the operations and governance teams are a bottleneck to the delivery teams’ SDLC.

Then there’s performance tests, security assessments, architecture, user requirements, all performed by separate groups in the organization, each one very specialized on their specific tasks, each one becoming a bottleneck to the organization’s SDLC.

All those siloed functions add up to the delivery teams’ lead time and can in fact comprise most of it. A two-week worth of software development can take weeks if not months to see the light of day. Delivery teams will learn to optimize for that and try to pack as much functionality as possible into a single release. Then, instead of shipping small chunks of functionality and getting quick feedback from users, the organization ends up resorting to big, infrequent, and risky deployments, delaying the feedback cycle and killing innovation.

One solution to this problem is to break all silos and have those specialized folks as members of the delivery teams. One issue with this approach is that it’s hard to scale. Those specialized roles are hard to find and therefore, expensive. If your organization has multiple delivery teams (which is often the case in big enterprises) it will be really difficult to staff those specialized roles for all teams.

Another (and better) approach is to optimize the way those specialized teams work. Work smarter, not harder they say. We don’t want to get rid of those silos, we just want better silos. In order to achieve that organization must focus on shift left, automation and platform thinking.

Take the example of the dependency on the operations teams for provisioning new infrastructure. In order to reduce or even eliminate this dependency, a couple of things need to happen. First, the focus of the operation teams need to shift away from fulfilling tickets to providing a platform where delivery teams can self-serve. That’s how an organization can fully utilize the knowledge and capacity of its operation folks. Automation plays a central role on building such platforms. An organization should try and adopt tools and practices that support this kind of automation. If Infrastructure as Code (IaC) came to your mind you’re on the right track. I won’t get into the details of IaC in this article but suffice to say it comes with its own challenges. However, organizations that successfully adopt it will reap its benefits like increased productivity, security, and stability, among others. I recommend you to check Kief Morris’s book if you want to learn more on this topic.

In the examples of the dependencies on the QA team for testing and the operations team for deploying an application to production, automation and shift-left are your best friends. In both cases you’ll face the issue of having a single team responsible for serving multiple delivery teams likely creating a scarcity issue which will translate to waiting queues. Here’s how we can address those two scenarios.

When it comes to delivering software, quality is not something you can leave for last. It needs to be embedded into your SDLC from the beginning (shift-left). In order to achieve that, developers need to feel comfortable writing all kinds of tests (unit, integration, functional, performance, and so on). It’s also crucial to embed the QAs into the delivery teams. No more long develop -> test -> fix loops. To be considered done, each story/functionality must be fully tested. It’s also important those tests are fully automated so they can be executed by developers on their local machines as well as part of a CI/CD pipeline.

When it’s time to go to production, throwing an application over the wall to the operations team introduces a lot of friction and risks. The operation teams will have to learn how the application works, how to monitor and troubleshoot it. Even if the required knowledge transfer is done successfully (which is rarely the case) a huge amount of time and energy is required which could have been better spent somewhere else. Organizations must shift from a project mindset to a product one. Product teams are (among other things) long-lived teams responsible for the software they build. In such a world, operations teams are responsible for providing the means for the delivery teams to safely deploy, monitor and troubleshoot their applications. Again, platforms and automation are key to successfully implement this mindset change.

Similarly, governance, security and architecture should also work closely with delivery teams. The most effective way to achieve that is to focus on establishing guidelines and metrics as opposed to prescribing what delivery teams should do. Their mantra should be “Tell delivery teams what you need as opposed to how to do it”. Governance and security requirements can be verified through automated reports executed by the CI/CD pipeline. The same is true for architecture if you adopt fitness functions as a way to measure architectural alignment for your applications.

There’s one area I haven’t mentioned yet that also benefits from working closely with the delivery teams. In some organizations they’re called product or simply business. Those are the people that (supposedly) know what customers want. They define and prioritize which features to deliver next. A gap in communication between business and delivery teams is cause for many failed projects (and products). If the delivery team doesn’t understand what they’re a building and why, it can lead to bad technical decisions. Similarly, if the product team doesn’t understand the technical constraints or needs (e.g.: tech debt) of the delivery team, it can lead to bad product decisions. It’s crucial to have a product person embedded in the delivery team to make sure such communication gaps don’t happen and the delivery team understands the purpose and goals of the software they’re building.

In all those scenarios the pattern is the same: Relieve very specialized and scarce people from ordinary work that can be automated and shift the responsibility for this work to delivery teams. Embed crucial roles into the delivery team to eliminate communication gap and enhance it with new capabilities (e.g.: testing). By doing this, you reduce or even eliminate the dependency of the delivery teams on those silos which in turn eliminates bottlenecks and reduces lead time. Your organization delivers better software faster and your very specialized people can focus on what really matters for them and the organization (better governance, better security, better architecture, better product, better infrastructure and better quality).

So, what do you think? Do you agree or disagree with the importance of breaking silos in order to improve the SDLS in big enterprises? Let me know your thoughts in the comments. Until next time.