This past week, my daughter started back to school. It was a big change for her, because it was a move from primary school to middle school and to a new school. She decided that she was both excited and concerned. There would be lots of changes (new people, new building, moving from one classroom to another), but also a lot of new potential friends and challenges.

The adoption of DevOps represents similar challenges for the service desk. As organizations adopt DevOps inside their development organization, support organizations are going to see significant changes, but also opportunities for great improvement.

What is DevOps

Before I talk about how the support team’s world will change, here’s a brief definition of DevOps and how the development team’s world is changing.

“DevOps is a new term emerging from the collision of two major related trends. The first was also called ‘agile system administration’ or ‘agile operations’; it sprang from applying newer Agile and Lean approaches to operations work. The second is a much expanded understanding of the value of collaboration between development and operations staff throughout all stages of the development lifecyclewhen creating and operating a service, and how important operations has become in our increasingly service-oriented world [emphasis added]” –

This definition points out the two changes DevOps represents. The first is a change to the way that development teams work, using Agile or Lean approaches to the development process itself. The result of the change in the way the development team works is a second change: a change to the way that it interacts with other parts of the organization (like the service desk).

So what’s the impact of DevOps on the service desk

One of the biggest impacts of embracing DevOps is that the formal interactions and documentation that the service desk has will change both in format and volume. Let’s deal with the change in volume first. To understand why Agile development organizations produce less documentation, you need to understand why Agile emerged. Agile development practices emerged to make the development process faster and more flexible, drawing on Lean practices that emerged in manufacturing industries in the 1950s. The approach and the documentation associated with the traditional approach was seen as too bulky. Both needed to be cut down and streamlined. Regardless of the specific Agile process implementation, the service desk is likely to receive fewer documents from the development team than before (and some development organizations might interpret less documentation to mean nodocumentation).

The format of the knowledge the service desk receives will also change. Documents will likely change as development organizations adopt Agile processes. The documents will evolve to match the stages of Agile development (requirements documents will new contain user stories, for example) and some might disappear altogether as some elements of traditional, waterfall coding approach are removed.

Why should you care and what you can do about it

Changes to the knowledge you receive (both in format and volume will have a direct impact on the support organization. Any change affects productivity, but changes to documents that you receive from your development team will be easy to notice. Here’s why:

Changes to document structures cost time and effort

A new format to your documentation will make it harder to find and reuse documents. Even if the same knowledge is contained in the new documents, it will take time for team members to get used to reading and dissecting them. Your team might even lose access to knowledge that the team still wants or needs.

Without some action on your part, your team will be spending time searching new document types for what team members need or escalating cases/bugs to the development team because team members don’t have the knowledge they need. Or both.

But like the first day of school, DevOps isn’t just a challenge, it’s an opportunity. Since the development team is going to change the format of the documents they share with the support team, take time to collaborate with them on the format. Ideally, some of the documentation could come in as knowledge articles that could be easily imported into your knowledge tool, ready-made to reuse. A few discussions around the structure of the knowledge with the development team will be well worth your effort (check out our content standard template as a place to start).

Finally, remember your own experience when you implemented knowledge-sharing practices the first time. It was a massive change to the way your team worked and how team members documented their knowledge. But the change also created a sense of excitement. The development team is excited by Agile. It helps them do their job more rapidly and effectively. Take advantage of that excitement to build an effective bridge for knowledge between your organizations.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s