Process for day-to-day tasks, planning

[DeadDuck]

Hi,

I'm considering creating a DevOps project for a small Cloud Engineering team. Currently the team uses MS Planner. We have a backlog, some tasks with planned deadlines, and during the day we create tickets for support requests which may take an hour or a few.

Bringing it into DevOps will open more possibilities for the tickets, a better structure, better manageability, better integration with the other teams and their dependencies.

With a bigger team, I would consider separating the planned tasks and day-to-day tasks to different teams, but with a team of say, 3, with each specialized in certain subjects, I don't find it feasible.

I started with a copy from the Scrum process, one intention being implementing some standards which we can later use for the other projects. I know Scrum is not really suitable for projects where you keep adding daily tasks. At the end of a sprint we can go over the planned tasks, and take a look at what has been done in addition.

Does it sound reasonable? Would you recommend another process template?

[#2 · Accepted solution]

Hi @DeadDuck,

Your approach of starting with a Scrum-based process for your small Cloud Engineering team is a sensible choice, but you've rightly noted that Scrum may not be the best fit when there's a significant amount of unplanned work involved.

To address this challenge, you have a couple of options.

One approach is to consider a hybrid methodology called ScrumBan, which combines elements of Scrum and Kanban. With ScrumBan, you retain the sprint-based structure but also allow for a continuous flow of work. During each sprint, you plan the work you want to accomplish while leaving room for unplanned tasks. As these unplanned tasks arise, they're added to the backlog and prioritized. When there's capacity, the team can work on these unplanned items. This approach provides greater flexibility to handle unforeseen work while still benefiting from the structure of Scrum, including regular planning and retrospectives.

Another option is to adopt a Kanban-only process, where there are no sprints, and work is handled continuously. Tasks are visualized on a Kanban board with columns like "To do," "In progress," and "Done." Kanban offers maximum flexibility, making it suitable for teams dealing with frequent unplanned work. However, coordinating work between different teams may be more challenging in a Kanban setup.

The choice between these approaches should depend on your specific requirements and preferences. If you're dealing with a significant amount of unplanned work, a hybrid approach like ScrumBan is worth considering. On the other hand, if your unplanned work is minimal, a pure Kanban approach might be a better fit.

Please click Mark as Best Response & Like if my post helped you to solve your issue.
This will help others to find the correct solution easily. It also closes the item.

If the post was useful in other ways, please consider giving it Like.

Kindest regards,

Leon Pavesic
(LinkedIn)

[#3]

Thank you Leon for a nice answer.

Indeed I was also considering ScrumBan, though I wasn't sure if it would fit. So, the Scrum template is okay for starting ScrumBan, right?

Best,
Onur

[#4]

Hi @DeadDuck,

certainly yes, you can use the Scrum template as a starting point for implementing ScrumBan, combining the structure of Scrum with the flexibility of Kanban to handle unplanned tasks effectively.

This approach provides the best of "both worlds".

Please click Mark as Best Response & Like if my post helped you to solve your issue.
This will help others to find the correct solution easily. It also closes the item.

If the post was useful in other ways, please consider giving it Like.

Kindest regards,

Leon Pavesic
(LinkedIn)

[#5]

@DeadDuck 

Do you considering of Cloud Operation apart from Cloud Engineering?

[#6]

@Kidd_Ip  the team handles both the engineering for new projects and optimizations on the infrastructure, and also operations, like support requests for service issues, mostly from our own team.