ITFundamental Software has been following Agile practices in our development team for years now and sprints are a fact of life for everyone involved in the development workflow. However, until recently the IT operations team has been utilising the chaos theory of workload management. Which, and I am sure readers will agree, is a great way to subdue whoever is yelling the loudest at the moment, but not a great way to accomplish meaningful improvements to help your company achieve its business requirements.

We made a decision to embrace DevOps principles consciously, as opposed to by accident. After a lot of reading and investigating we reached the conclusion that a lot of commentators know what DevOps should be and what the underlying principles are. However, information on how to accomplish those lofty goals is in short supply (Please let me know in the comments if I have missed a great resource on implementing DevOps principles). The previous DevOps post on this site outlines how we implemented DevOps principles. This post is going to focus on transitioning our IT Operations Team to use the concept of a DevOps sprint.

Team buy in is important.

Change is an unwelcome presence in most people’s lives – it messes with their mojo or something. By introducing DevOps sprints you are introducing change, whether you are starting from the Chaos theory of workload management, like we were, or you are a strict ITIL|COBIT|etc shop that has everything written out in a SOP that is well written and communicated. If my years in IT have taught me anything, it is that end-users are resistant to change (big surprise there!) but the change that will make them dig in their heels and morph into a horde of angry, stubborn end-users is the procedural one – the change in the way they ask us for help and how we respond. Which is why getting the Team to buy in to the concept is key. It is they who will be facing that horde of end-users and forcing the behavioural change on them. Don’t get me wrong – there will still be plenty of fire fighting and unplanned work that needs to be attended to immediately, but there will be change for end-users. Either the way they interact with IT process or IT ‘s responsiveness to their problem or something. Otherwise, what you have works and why change.

If the Team doesn’t buy in, there will be no change. The Sprint will fall apart as everyone, IT staff and end-users continue with the comfortable and all the work to make the transition will be wasted.

Management buy in is important

I probably don’t need to expound the difficulties on making a fundamental change to process like this with the support of management. So I won’t.

Get control of your workload

At Fundamental the IT operations team has a broader scope of responsibility than other organisations I have worked at. One of the key milestones in transitioning to sprints was to understand the nature of the work hitting the team. In our case it fell into two broad categories, maintenance of existing process and technology, and project work. The project work was research into new technologies, improving existing process, creating new processes, implementing product changes internally and externally, consulting at clients, and more. It was the project work that was standing still, mainly because we treated it the same as maintenance work. As a result there was no concrete progress made on anything and no sense of accomplishment at finally closing down a piece of work.

Our resulting process was to review all existing logs in the system and decide what was and what wasn’t a project. The process took some months to complete. The effort was worth it as in the end we had a list (a long list) of projects that could be assigned to an individuals for 1 or more sprints with targets and that all important sense of accomplishment when a project was successfully completed.

The separation of project and maintenance work also had the important output of allowing us to define to management and get feedback from management on our priorities and why work was dragging due to high volume of maintenance work. A bonus benefit of the way we implemented management of the project backlog and active project was self documenting changes to the network! Information in the Project wiki page is migrated to the ‘live’ network documentation and that is the last item on every project before they are signed off as complete

Delegate Administration Whatever process you follow to manage your IT operations workload there is a level of administration. Sprint in a DevOps setup is no different. We found that delegating aspects of the DevOps admin overhead to team members helped create buy in to the process and allowed all team members to stay productive.

That is all that we needed in a nutshell to implement sprints in our DevOps team. Team buy in , management buy in, categorization of the workload into planned and unplanned, and a method not to get bogged down in all the administration a sprint requires. One aspect I did not touch on was managing the change with end-users, which I will not be covering. That is a topic that will have a different need at every organisation. All I can say is that slow and steady wins the race.