DevEx for managers
The reason organisations are adopting DevOps practices is because these organisation want to gain more business agility. This increase in business agility should demonstrate itself in advantages of a faster time-to-market, increased quality, ownership by teams, higher product quality, faster feedback from the market and the ability to experiment. However when the number of DevOps teams start to grow within in a organisation all these advantages start lacking behind, because of the nature of this growth. Side effects are illustrated in the animation underneath.
DevOps is considered the catalyst to gain these previous mentioned advantages within a organisation, but when the growth of the number DevOps team this catalyst becomes less effective. DevEx(developer experience) is then the next catalyst to use. DevEx (developer experience) is the means which allows to scale DevOps adoption within a organisation, by focusing on the ease of use of tools and services by the DevOps teams.
To investigate whether DevEx the is right instrument for improving the acceleration of a DevOps teams, you should focus on these two metrics.
- Number of impediments caused by consumed tools and services
- Mean time to resolve (MTTR) of impediments caused by consumed tools and services
If either one of these metrics is abnormally elevated, then there could one of these problems with this tool or service. The problem(s) could be in the interaction, process or the product.
Interactions are the touch-point with the tool/service, if interactions are not intuitive or cannot be automated it is not suiting the automation flow of DevOps team. An example of great interaction is AWS CloudFormation, it allows define the an end-state as code and use the AWS Cli for communication with the platform and also validating if the interaction is going to work in advance.
Process is when the DevOps team relies on the tool/service for execution. For some processes this can take a while and this has the tendency to become a black-box. A DevOps team should always be able to see what the process status is in an automated fashion.
Product is all about: does the tool/service deliver as intended. This is a process of continuously question if right tools/services still are being used or whether the supplier is willing to change the product.
The supporting teams that offer DevOps team services/tools should focus on improving these three facets mentioned above. Typically if there is a problem with one or more of these facets, the supporting team has a lot unplanned (supporting) work. By improving these facets, unplanned works shifts into planned work and eventually becomes unattended production work.
A good practice for supporting teams to adopt is service design. Service design helps to create a customer focused experience (DevOps teams that are consuming services from supporting teams should be considered consumers) using techniques like discovery workshops, ethnography, service blue-printing and many more.
By adopting DevEx practices, supporting tools/services become accelerators for the DevOps teams instead of impediments. By doing so the organisation can focus again on increasing its business agility, by speeding up software delivery and increasing quality. It also allows teams to exercise more ownership on the services they deliver, because they become less impeded by to supporting organisation.
For more in-depth information:
