Yes, DevOps has fundamentally changed the way we operate in a good and healthy way. Development teams being part of the care and feeding of the systems they produce increase quality and will eventually automate the CICD pipeline as close to production as possible, if not all the way.
Even so, many of the Scrum teams I work with feel overwhelmed and even distraught about the work they don?t get done during the Sprint on their product. This is most common among teams who assume ad-hoc or interrupt work will not disturb their capacity to get work done on their core product.
There are 2 common sense ways to deal with this problem.
- Pull less work during Sprint planning.
- Pull less work during Sprint planning.
Most teams come to this realization on their own, but then struggle with the minutia of how to track the 2 types of work they are now responsible for: operations work and product development.
There are 2 main ways I have seen teams mitigate this tracking of work. One looks like the image below, and teams associate all operational work with a reserved User Story for just this purpose.
These teams will often pre-size the Ops User Story based on previous experience of how much operational work comes into the Sprint vs. product development.
I?ve seen examples of operational items with up to 50% of the team?s capacity reserved. This is a team in trouble. They are on the verge of becoming an operational team that no longer adds features to a product and thus no new value to the customer.
At any rate, in my experience most teams settle into about 10% of their time being reserved for operational duties in DevOps environments. This informs the size of the operational Sprint item during Sprint Planning and tends to work well enough.
The thing I don?t care for in this model is that it doesn?t shine a bright light on the operational work, which is, in fact, bad. If we had no operational work, after all, we would be adding product features.
Since we are focusing on the tracking mechanism, another other way I have seen teams visualize the operational work they must address is through a fire lane. A fire lane may take the form of the board we see below.
I far prefer the fire lane model as does not obscure the operational items and makes them very visible. This can lead to pattern recognition. ?We need to solidify our integration testing,? or ?We need to close the gap on automated container deployments.?
This technique makes each and every item visible to the team and can be examined during retrospectives, potentially causing a team to expand its definition of done.
While there are undoubtedly many other ways to track operational vs. product development work, the technique to do so should draw a very clear distinction between the two and highlight operational work in such a way as it can be mitigated over time. One step at a time, just like paying down technical debt.
I like to dedicate X team members to deal with fire-fighting / customer support / live site incidents each sprint, allowing the others to achieve better focus on feature development.
Hopefully they are spending some time mitigating the root causes that require them to offline while they are on temp duty.
That’s the kicker.
This may sometimes devaluate your project’s progress by closing the scope of people who engage in the implementation process. Unless you make a rotation, of course.