The reason why most enterprise organisations do start with DevOps implementations is because they want to have the benefits of increased quality, increased business agility and acceleration of teams. Most organisations discover that at some point there is a need for certain capabilities being centralised in separate specialist teams. We call this the shared responsibility model. (You could think of CI/CD, cloud, compliancy and security capabilities) The consuming the capabilities of specialist team by a DevOps team however, does not always have the desired effect of acceleration. On the contrary, this shared responsibility model is often where the DevOps teams become impeded.
Teams become dependent on processes, interactions and products that they do not control. These dependencies are inevitable, but rather than slowing DevOps teams down they should accelerate DevOps teams. In this series of blogs approaches will be described how specialist teams can be DevOps teams oil instead of glue, starting with a short introduction in this blog.
As a coach/consultant I have worked at many financial institutions and enterprise organisations. In most of these occasions we focussed on helping teams to accelerate by introducing continuous delivery and DevOps practices. Improving and amplifying the acceleration can be done on the following developer experience (DevEx) topics:
Interaction
When a specialist team offers services/capabilities to other teams, interactions are the most important means for consuming the product of this team. Interactions fuel the process that eventually forms the product that is consumed.
Interactions with a specialist team are probably the first impediment DevOps teams will encounter. Communication is often unpredictable, asynchronous, manual and inconsistent. Most of the time this leads to frustration and even is misused as scapegoat by the DevOps team. (In part 2 this problem is elaborated and possible solutions are shared.) When the specialist teams accepts the request the next developer experience challenges will become visible in the process.
Process
The process of a specialist team providing capabilities and services to other DevOps teams should be consistent, reliable, transparent and should reward the team that did the request as soon as possible. The DevOps team will get a better insight in their organisational impediments and better predictability when a product (result of the process) is delivered.
Product
A product (capability/service) that a specialist team delivers should be become a commodity within the organisation. It should be as easy to use and reliable as electricity coming from an outlet and a DevOps team should be able to have ownership of this product without any challenges.
Conclusion
Thinking about developer experience (DevEx) in an enterprise organisation is a means to not only accelerate single DevOps teams but also to amplify this acceleration over other DevOps teams. It will simplify how DevOps teams incorporate capabilities/services from other teams into their own product and process without becoming impeded. In the next blogs I will give an in-depth description on how to improve developer experience on interactions, process and product.
In the next blog I will cover how to improve interactions and how teams can create scale-able and consumable interactions that amplify the acceleration of DevOps.
