Adopting DevOps is an accumulation of a number of small steps towards a common direction. In this short article, I like to cover one of those small steps in making DevOps work for you – getting your teams to use the same platform.
DevOps started with software teams switching successfully to Agile methodologies. Development cycles started to shorten and the need to deploy more frequent and in shorter cycles increased.
While development found its way to be more reliable and closer to the customer, operations struggled to follow. The new methodologies created a bottleneck. Changes that had to be applied every three months now needed to be applied at least every two weeks – if not more.
These short cycles leave little room for time wasted on planning, misunderstandings and clumsy administration processes. Development and Operations must work hand-in-hand to build a faster, more reliable release pipeline.
This is easier said than done. In most organisations, there is a big wall between development and operations. This wall was build and cultivated over the past years through the use of different tools and different objectives.
Team members are sometimes even selected on stereotypes that reinforce this division. You might have a team of ‘reliable’ operation engineers and ‘creative’ developers, yet they are unable to speak in the same terms as the other.
Tear down this wall!
It is clear DevOps is a cultural shift more than anything else. How can operations be prepared if they can’t see behind the wall and anticipate changes? How can development improve the software if no feedback from operations is coming through? How can development and operations improve as one team?
Building a culture of collaboration is the foundation of DevOps. Maintaining and establishing practices like Agile, Continues Integration and Continues Delivery are the cornerstones in this initiative.
While a tool alone is rarely the solution to a problem, the right tools can certainly be the needed catalyst for the adoption process.
In my exaggerated view on Development and Operations, let’s assume they decided to use the same tool base. Instead of an Agile planning tool and a ticketing system, they have one common platform. This is not as erroneous as it might sound. A ‘Service Request’ is like a ‘Story’ within an Issue that needs to be completed. A ‘Bug’ is like an ‘Incident’ within an Issue that needs to be fixed.
A bug or an incident?
Let’s take the following example: An incident is reported by a customer. The operations engineer analyses the incident and comes to the conclusion that it might be a bug in their own software. To confirm he mentions the responsible developers on the ticket. The developers then receive a notification and can swarm the incident as all required information is available in the issue.
What’s great in this process is there’s no need to switch tools nor to have a long email chain. The platform’s collaboration features track the conversation between the teams. This is helpful if you need an additional specialist to join on the issue on a later point in time, as all the information is well documented. This effective collaboration results in a lower mean time to resolution.
The developers confirm the engineer’s hypothesis – it’s a bug. The engineer can respond to the customer that the problem has been identified and the bug will be fixed by the development team.
Being on the same platform allows the engineer to raise the bug in the development project and drive all required information from the incident to the bug issue. Furthermore, the two issues will be linked, so the development team will know what incident caused the bug.
Why not just use the incident to track the bug? This might seem like a proper solution, however incidents and bugs have different lifecycles and workflows. Typically, the bug created in the development project will show up on the backlog. While on contrary, the incident will be resolved once the cause is identified.
The development team can fix now the bug as they have everything at their fingertips thanks to the link between the incident and bug. They can refer back to the operations engineer, examine the incident ticket for further information, consult the discussion history, initiate a new discussion or link other related issues to the bug. Likewise, the operations engineer is kept up-to-date on the bug’s status, the allocated sprint, delivery date and other critical information. The customer can be automatically informed once the fix is deployed on production.
This short example illustrates how a tool can facilitate the collaboration. Of course, first you must establish a culture of collaboration and unfortunately there is no tool for this. The case illustrates simply how you can lower barriers between teams.
Have a question on how to manage your DevOps adoption? Get in touch with one of our Atlassian certified consultants by clicking below.