0

I'm looking for some advice on how to navigate the choppy waters of DevOps/SCRUM with in a team.


Background: A team is very operational and has 3 products and 2 engineers, 1 Product Owner, 1 Manager (no scrum master, team lead, or tech lead) and their delivery sprint is 1 week. This team follows "you build it, you own it" and also tracks team hours via tasks assigned to stories.

Scenario: For 1 sprint, an engineer found himself working on incidents (application availability affected, due to a mix of upstream systems and the application itself) for half of the sprint. The team decided the remediations were not what customer asks, but instead operational work.


This is a real world problem I'm trying to tackle. Obviously, this situation can be mapped well to Agile principles, but this department heavily follows DevOps/SCRUM for product mapping and tracking purposes.

What do you think would be the best way for the engineers to track their work?

1
  • 1
    The only reporting done within the Scrum framework is the Sprint Review meeting at the end of each iteration, where the team showcases their achievements. Whatever hour reporting/work tracking you need to do probably comes from the management of the company and not from a framework. – Bart van Ingen Schenau Feb 1 at 6:52
3

If you frequently have incidents and other pop-up work that needs to be prioritized, Scrum probably isn't a good fit. The core of Scrum is the Sprint. If you can't consistently hold a planning session to select a goal and work that supports that goal for the Sprint, execute the work, synchronize with stakeholders, and then improve your way of working on that Sprint cadence, you're going to struggle with Scrum.

The rest of your context isn't well-suited to Scrum, either.

Scrum is built around a team supporting a single product, yet your team is supporting 3. If you were to "do Scrum", you would have three Product Owners and three Product Backlogs. Even if you were to have fewer Product Owners, you should still have three Product Backlogs. However, the team would struggle to focus on a cohesive goal for the Sprint unless each Sprint can be dedicated to a single product. This is especially true if the products are all operational and need ongoing monitoring and potential support for incidents.

The team size is also on the small side for a formal methodology. Unless the manager is actively developing the product as well, you only have two developers. The Scrum framework is designed to coordinate the work among a team, so some of the activities described in the Scrum framework will probably be excessive or even add additional overhead rather than making the team's life easier.

The best course of action would be to look outside of Scrum since the practices there aren't suited to your current context. However, if you are stuck in Scrum, you still have options.

All work that is done in the Sprint must be visible. If there are incidents, they need to be in your Sprint Backlog, on your Sprint Board, and everyone needs to be aware that these incidents came up. When you get to the Sprint Review and Sprint Retrospective, the team needs to communicate the impact of these incidents. At the Sprint Review, should be able to explain the issues that came up and how those impacted the team's ability to achieve the Sprint Goal.

Going forward, the Sprint Planning session should include incidents when considering capacity. If your organization embraces DevOps, you should have extensive monitoring of applications that can provide information about incidents. Using past performance on how long it takes to resolve an incident, the team needs to set aside time and not plan their Sprint to capacity. The Sprint Goal should be generally achievable, considering a "normal" amount of incidents and time to resolve those incidents across the supported systems.

At an organizational level, there needs to be a strong effort to address the incidents' root causes. By reducing the number of incidents or developing ways to restore the system to a normal operating state faster, the team's capacity for development will increase.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.