[This article was co-written by Miel Donkers and Niels Talens.]
You could see DevOps as expanding the mindset, toolset and processes which started with Agile. Where Agile focuses on creating maximum business value as soon as possible, DevOps can help you to actually deliver this working software quickly. Finally a Minimal Viable Product makes real sense.
But just as we found out time after time with agile adoption projects, the gap between business and IT is often a bottleneck and not an easy one to resolve. With DevOps this often becomes an even bigger bottleneck since it adds the technical aspect of maintaining software in production.
DevOps is not just a matter of integrating Ops work into Scrum. In this blog-post we would like to focus on questions like; How are we going to …
- help the business with this changed reality?
- be able to cope with unplanned work (like incidents) while retaining a sustainable pace?
- show the benefits of DevOps to the business on short term?
- make sure features aren’t always prioritized above quality and security?
- make sure that all important work is going to be planned on time?
Helping the business with new team responsibilities
From the business (PO) point of view, the most important change by creating DevOps teams are the added responsibilities for the team. With agile, the responsibilities are roughly limited to delivering working software. With DevOps what is added are the responsibilities to put this software in production and keep it running.
The effect of these added responsibilities depends a lot on the company structure, team composition and which activities are necessary to put software into production. One effect will be more unplanned work popping up for the team, which we will describe further in the next section. Another effect has to do with long-term planning.
The challenge lies mainly in activities like security audits, penetration testing, approval processes etc – activities that cannot be executed by the DevOps team – for which other people in the company are required. We often see that while development teams are agile, the rest of the company is not. To plan the aforementioned activities takes time and often results in agile teams being blocked before these activities are finished.
Resolving these issues needs careful planning in order to let company departments work closer together to;
- Identify upcoming work for people outside the team as soon as possible,
- Limit the wait-times before these activities are picked up to an absolute minimum,
- As team give a higher priority to these activities to pull the risk forward.
Coping with unplanned work
With DevOps, the entire team has the responsibility to satisfy the customer by maintaining the software in production. Bugs and production issues will always occur. The difference with DevOps teams is that issues will also disturb the development process because there is less filtering upfront. Traditionally companies have 1st line support, 2nd line support, etc. But now that operations and developers are working together there are less boundaries and the entire team will immediately see these issues pop-up.
The good part is that because developers and operations form one team, they can work together on fixing the bugs and have them resolved much quicker. If something bad happens to the system, the root-cause analysis is done a lot faster with developers and operations sitting together. And because during regular work the operations people get a better understanding of the application, they themselves can already analyze problems better.
There isn’t much difference with doing agile, only that the impact may be higher because of the changed team composition. The first step to solve this is to make the work that is done more visible. Creating a “fast lane” on the scrum board is a good way to make (mainly the unplannable) work more visible. As you can see in the picture below this lane is placed above all other work on the board to make it clear it has the highest priority. It is adamant that all issues get registered so that it becomes clear what work is being done (this accounts also for all other tasks people execute).
A second step is to implement some proper filtering, for deciding which issues need to be picked up immediately, which issues can wait for some time (e.g. until the current story is done) and which issues are trivial enough to be planned into a sprint. Use a “definition of fast lane” and common sense here.
Definition of Fast lane (DoF):
It is very important to have a definition of the work that can be in the fast lane. Otherwise it has the risk to become a placeholder for bad planned features or bugs that aren’t that important. Since fast lane stories impact the sprint planning and thus the predictability, you really want to differentiate the plannable issues from the really urgent ones. The fast lane is only for work that can’t wait until the next sprint. Criteria for the fast lane can be:
- Does the issue affect business critical processes?
- Is the affected functionality used a lot?
- Is there a patch needed?
- Is there a workaround possible?
- What is the classification (Minor/major/critical)?
Keeping track of the output:
To have a good view of the amount of fast lane stories and the impact on the velocity we recommend that you will keep track of the spend time (in hours or points) after finishing each fast lane task or story. A fast lane item doesn’t need to be estimated upfront. It needs to be fixed as soon as possible. That’s the only justification for being on the fast lane in the first place.
In the picture below it is clearly visible that an increase of fast lane stories have an impact on the velocity. The output of the team, even with a decrease in velocity, is not less than other sprints.
Make sure all work is planned on time
In order to create both a short as a long term planning, the workload first has to be prioritized. In principle this is the same for development and operations work.
And just like new features that are picked up by developers, for all operations related work there is a necessity or not. If this necessity is high it needs to be on top of the backlog, otherwise it can be further down in the list. If there is no necessity at all it can be deleted from the backlog instead of polluting it.
Maintaining a good backlog is getting more complex and dynamic. By introducing operations in an agile environment the Product Owner gets more stakeholders. These are not new players but they are now within the scope of the program. Before DevOps, most of them worked in a different department with their own planning. With DevOps these people are the stakeholders who should know or find out the value of each item.
And that’s how they should operate: as stakeholders. The same techniques for prioritizing new features can be applied for all plannable other work. For Ops work the (value)necessity/effort rate have to be applied in order to get to a good prioritization. A value model can be at great service for a Product Owner:
- Get the proper value/necessity per item from stakeholders,
- Get the DevOps teams to give a rough estimation per item,
- Verify the value/necessity in combination with the effort estimation with the stakeholders,
- Create the release planning based on the prioritized backlog.
We hope to have given you, the Product Owner or any possible DevOps team member, some pointers about how to handle the changed reality. Mostly its a process of together making the right decisions and making certain agreements on how to handle specific situations.
If you have any questions or recommendations, please leave them in the comments below. We love to hear from you!
This article was co-written by Miel Donkers and Niels Talens.