NetOps team attempting Scrum
So I have inherited a new scrum team that primary does operational work and some project work. In the coming future they will have a series of network refresh projects. In order to understand their work I went to observed them work and pitched in as well. After observing and working with them for a few days I have come to a realization that they cannot really function as a traditional scrum team. They just do not have enough project work to continuously do sprints and ceremonies. For example their projects revolve around physical hardware being on hand. Currently the hardware that is needed for their projects have a lead time of 180 days. So even though they have some of the hardware there will be a gap in completing project work once they have installed the devices that they currently have on hand. This causes a hinderance because that would mean that the backlog would not move and we would not be unable to move into continuous sprints as a scrum team does. Furthermore, once the refresh project is completed they do not have any other projects in their backlog. From my point of view this team works more like a waterfall team because it is required that they have a defined scope at the start of a project as opposed to a scope that can be define over time. It seems that scrumban may be the methodology of choice for this team since scrumban. I think the benefit of scrumban would be the the fact that there is no estimation since the team would not be working in sprints, ordering the work based on priority, imposing WIP, visualizing the work and trigger planning. What I'm concerned about are the ceremonies. I've done my research on scrumban how ever there is no mention of the ceremonies. There is an explanation on how trigger planning works but nothing on including the ceremonies or excluding them. I would like a bit of clarity if anyone could help.
Scrumban is meant to describe a journey from Scrum to Kanban in which the scaffolding of events is removed. If the scaffolding is useful, which is likely to be case with a complex product (or service), then it may make sense to implement Kanban as a strategy within the Scrum framework.
Here are a couple of blog posts, one on managing flow at the Sprint boundary:
https://www.scrum.org/resources/blog/flow-optimization-sprint-boundary
and another on trigger planning:
I'm not sure if agile methods are appropriate for this team because of the nature of the work.
I'm not entirely familiar with all of the details of what goes into a "network refresh" project, but it seems like it's the kind of work that can be planned out in advance. The scope and dependencies are well-known in advance and the effects of changes (such as delays or problems) are well-defined. Even if there are risks with uncertain probabilities, the impact of those risks materializing is reasonably known. This is not the kind of work that agile methods are suited for.
Agile methods are better suited for efforts with more unknowns. The true scope of work needed to be successful is unknown, the dependencies are not known, it's difficult to detect and plan for risks over a long period of time. The iterative and incremental nature allows for planning in much smaller windows, focusing on a slice of work where it is possible to turn enough of the unknowns into knowns to enable more effective planning.
This isn't to say that operational work isn't suited to agile methods. In most of the cases that I've seen, operational work tends to be more interrupt-driven and more difficult to plan, so just-in-time methods like Kanban are more effective than time-boxed iterative methods like Scrum. However, in all of these cases, there is more unknown or uncertain about the work, so these methods make sense.
There may be some techniques to overlay a plan-driven project on top of Kanban. In this case, the cost of delay of completion is something that can probably be predicted if there are urgent issues that rise up. This is something that I'd look at over Scrum, with fixed-length cadences. Just-in-time backlog replenishment, planning, review, and retrospective would probably be more beneficial in this context.
I'd also point out that "Scrumban" isn't a well-defined term. I've seen it mean anything from a Scrum team using a Kanban board to represent their Sprint backlog to something more like Professional Scrum with Kanban.
I've worked in the networking/IT area in my past. I don't think that Scrum would be a good option. There are some projects where it could be useful but the vast majority of the work is pretty structured. If you want to have a way of making the work more visible, Kanban would be a good option. But I'm guessing that you already have some form of ticketing system that is used to keep track of work. I'd stick with that and some task based project plans to track the network refresh projects.