Accelerating the process (DevEx part 3/4)

In the previous blog the steps a specialist team can take to improve their interactions with DevOps teams consuming their products were described. All these interactions leads to actual work that the specialist team should be performing, however the way the specialist team processes the work not always lead to acceleration of the DevOps teams.

There are three types of work a specialist team can be performing and the balance between these types of work is an indication whether an organisation is able to amplify the acceleration of DevOps teams. The three types of work that can be identified are:

• Unplanned work
• Planned work
• Production

Unplanned work is the work you do not want to have as a team, these questions, incidents and ad-hoc requests. The team was not prepared to handle the interactions and these will have an negative impact on the planned work. It also can lead to a lower production, but not necessarily. It could be that the level of interactions does not allow for integration into a production process or that the specialist team is not ’service-complete’.

Planned work is work that the specialist team does this could be improving the production process, handling request, answering questions and solving incidents. This is work is not interrupting the day-to-day work is actually planned in for example a sprint-planning. However is planned work being used for handling requests from DevOps team instead for improving interactions, production process or product than the specialist team is not focused on scaling the acceleration.

Production is the work that the specialist team handles unattended, an interaction from a DevOps team automatically triggers the productions process and the delivery of the requested product. The goal of production work is remove or minimise the human factor in the delivery of the product. The more the specialist team allows to handle requests as production work the more time they have to improve or extend their services. As additional benefit the product that is offered as a production work can now scale within the organisation.

Specialist team work balance

For the specialist team if they want to provide a great developer experience that is both beneficial for the specialist team and the DevOps teams and allows the organisation to amplify the acceleration of DevOps than these aspects are important:

• Reliable
• Automated / Integrated
• Secure / Audit-able / Traceable
• Measured / Monitored

Reliable, means that if DevOps team interact with the production process that there is clear documentation when a product is delivered successful or when something goes wrong. But also the production process and interactions should be as user-friendly that the change of doing something wrong is brought back to the minimal.

Automated / Integrated, means that a interactions triggers the production process. The focus on production process should be to remove or minimise the human factor from the production as much as possible, this could mean that the production process also can trigger other production processes in other specialist teams.

Secure / Audit-able / Traceable, it should be clear when somebody triggered the production process and how it was triggered with which configuration. Also the production process should be secured with authentication and authorisation.

Measured / Monitored, gives specialist teams on insight their production and where there might be problems in the production process. It can give a clear indication where the production process can accelerate.

In the previous DevEx blog on interactions, an example of changing a firewall rule was given. When approaching this problem from a developer experience process perspective these steps need to be taken:

• Improving the interaction
• Integration / Automation
• Product delivery

Improving the interaction is the first step that should be taken, if the specialist team is reliant face-to-face communication requests will probably will end up as unplanned or planned work and not allowing to be part of production because integration and automation is not possible. The simplest step for creating an integrated interactions is creating a simple web-form that triggers a workflow.

Integration / Automation is removing or minimising the human steps from the production process. A great way to do this is defining a process workflow (use and process design language you like) and automate and the integrate the process step-by-step. The result at the end of the production process is the requested product.

Example production process for creating a firewall rule

In this example there is a human interaction to approve the firewall rule, but the human factor is minimised and if a means to remove the human factor from the production process is possible this would be a great improvement that allows the specialist team to scale.

Product delivery, the product that is the result of the production process. This product should always have a certain consistency, like returning the same format every time and the use of the product should be as easy as possible.

Improving the developer experience looking at process factor does not only allow organisation to scale by offering products through integrated and automated interactions. It also helps specialist teams to actively reduce the level of unplanned work and improve and extend their service through planned work.