How to apply Scrum for Operations team

Have you looked at Kanban? It may be more appropriate.

Scrum is optimized for delivering complex software systems under conditions of uncertainty. Would you say that this describes your situation? Would value be maximized by achieving Sprint Goals, each of which mitigates a substantial element of risk?

Sanjay -

Alternatively you can try Scrumban - a hybrid of Scrum & Kanban which is often used as a transition method between Scrum and Kanban proper. Even with predefined tasks visualizing work in Kanban might help your team identify bottlenecks and improve the overal flow of work.

https://en.wikipedia.org/wiki/Scrumban

Scrum is designed to embrace change and facilitate empirical and frequent feedback.

The scenario you describe Sanjay consists of repeatable, known tasks, which are actually very well-suited for waterfall management.

I would agree that efficiencies and improvements may be gained through the use of Kanban to visually manage the work flow. Use the board to track all tasks, regardless of duration or frequency.

A daily stand-up within operations may improve communication and collaboration within operations. A periodic retrospective may also improve learning and making process improvements.

However, I feel the application of Scrum in this predictable and repeatable work environment introduces a lot of unnecessary overhead and waste.

Thanks Timothy & all other members for your valuable suggestion. I also think that Kanban will best suit for this situation which will improve transparancy. Daily stand-up and retrospective will also improve learning, process improvement and team work.

Ian's questions were quite insightful and Timothy's breakdown was very helpful.

I have often wondered, how to implement a workflow methodology to operations and development. 

From Ian's line of questions, I could see that prediction is the key to kanban. If you can anticipate what work will fall into the the first category, you will be able to determine how it will move through the workflow and end it the last category (assuming that means done for your kanban) . And then repeat it, over and over again. When something new or unpredictable happens, it can jam the workflow and essentially break down the operations. 

From Timothy's very insightful comments, I could see that scrum is a feedback model. And when new, unpredictable events occur, the workflow doesn't get jammed, it simply shifts to meet the new demand.

One might say, in terms of an analogy, that scrum is the startup searching for the business model and kanban is the execution of that business model. 

I believe management methods may be grouped in a pyramid such as

1. Operational -> day to day continuous, uniform activities
   1. Repeatable activities (e.g. mount wheel on car, check messaging discards every morning)
   2. Ordinary maintenance (e.g. add paint to the painting robot in the factory. manually create software backups according to procedure)
   3. Extra-ordinary maintenance (e.g. 6 weeks factory downtime for machine maintenance, big software production go-lives)
   4. Ticketing ( e.g. address production exceptions )
2. Project -> addressing change, with limited scope, time and budget, usually not repeatable. There are many methods, but let's just distinguish between
   1. Waterfall -> normally longer term, with few decision points and a preference to have decisions established upfront
   2. Agile -> elastic time horizon, but substantially having frequent decision points

To me SCRUM is a method addressing 2.2 Agile project management. I do not see it very applicable to operations, at least not for the classical meaning of the term.

To distinguish, if you have an invoicing application, drafting invoices is an operational activity. You normally do not put that in a kanban or scrum board. On the other hand, a "change" activity such as "modify default layout of invoices" is something you may manage with SCRUM. I would directly link this to the "adaptation" pillar.

Almost everywhere I looked at operations, the "adaptation" is limited to "keep the system inside operational parameters", which is not "continuous improvement".

I have reached this discussion because I am evaluating Atlassian Jira Software's SCRUM based project management tool. There is no way to define recurring tasks, that are operational. It seems to me they are also interpreting this "adaptation" key aspect of SCRUM as managing change for continuous improvement.