For the last few months I have been thinking about the best ways to use agile methodologies in an operational environment. Having done some research it seems there are two popular concepts surrounding this idea – Agile Operations and Dev Ops. Both are essentially intended to bridge the gap between application development and IT operations, using agile methodologies which work in software development to improve practices within operations. Agile Operations focuses more on identifying agile practices and principles that can be applied to operations irrespective of where the hardware or software involved is coming from or how it is developed. DevOps is aimed more at addressing concerns of developers that ops staff (mainly sys admins) can’t keep up with the increased pace and communication needs that an agile environment requires.
Here are some of the things I have learnt whilst trying to apply some agile concepts to my own operations team.
Firstly let’s be clear about one thing: Agile (both with a capital and without) is a software development methodology. That is what it was designed for, and indeed it works very well in such a situation. There are a host of reasons for this, but the main ones to focus I have focused on are:
- Shared ownership
- One task at a time
- Short iterations
I have highlighted these areas because they are the ones where I have focused most in transferring these processes to an operations environment. Whilst all fit better in a development team, there are certainly elements operational teams can take away.
In an operational team there are often many different threads of work being undertaken concurrently by different members of the team. This can make it difficult to see the bigger picture as everyone does their own thing. The dangers with getting too immersed in your own world are obvious and do not need to be highlighted here. If we assume that most operational teams work to provide a service to others, it follows that they will have close and regular contact with many other teams. There is thus the argument for a single member of the team being responsible for a specific work area, to provide a single point of contact. In many cases this can work well. However it does also raise the crucial question: what if something happened to that single point of contact? People go on holiday, people get sick. What happens then? A system that relies on a single individual is setting itself up for a fall. Shifting to the agile way of sharing ownership will not only eliminate that risk, but also mean that the whole team is accountable for all work. This encourages teams to work together and collaborate with each other to achieve the best results. I read about something called InfraScrum which essentially tries to apply concepts from Scrum to infrastructure project management. Specifically the author highlights the fact that having team members focused on specific individual responsibilities can reduce agility and cause silos within a team. He suggests knowledge be shared between team members on a regular basis in the form of training and knowledge-sharing sessions.
One task at a time
This is not necessarily possible for an operations team, particularly if we consider they are heavily reliant on outside teams. Work is often blocked by external factors so it is sensible to have more than one task on the go at a time. This means that efficient task management is essential. What operations teams can take from agile here is the need to make everything visible. The use of whiteboards in agile means that it is always and immediately obvious who is doing what task, and what stage that task is currently at. If team members are split across different locations a whiteboard may not be the ideal solution. There are online solutions such as Jira although arguably this can never be as effective as a physical board where you can actually pick things up and move them around. Nevertheless, the key point to take away here is visibility. Tasks need to be displayed somewhere central for everyone on the team to see.
Unlike a development project there are no clear iterations – work is more continuous. Moreover as there are often many different small tasks going on at the same time, these can overlap. One of the best things about agile is that both processes and progress are regularly reviewed in the end of iteration retrospective. This way any problems are picked up early on, before they have a chance to escalate. Without clear iterations, there is no clear time for this to happen. While it may not be appropriate to enforce set iterations for an operational team, it is important to set time aside to review how things are being done, what is working well, and what is not. This has the added benefit of forcing you to take a step back from whatever you are doing, and from this position you can view tasks from a different perspective. Luckily the working week is set up with a clear beginning (Monday) and end (Friday), so adding a retrospective-type-thing at the end of the week is not a major paradigm shift.
Ultimately there is a lot operational environments can borrow from agile practices, and I have by no means covered everything in my research. As I said there is a massive amount written about this on the web, but a lot of it is specific to a particular operational environment. I guess it is important to realise that there is no single correct way to do things, it is simply all about finding out what works best for you and your team. In true agile spirit, it is all about People over Processes.