What the Stand-Up Meeting is For
The Stand-Up Meeting (a.k.a. the daily scrum) is designed to accomplish two main things:
- Coordinate task dependencies within the team.
- Identify process or resource issues (blockers) that need to be addressed outside the stand-up meeting.
Various scrum practices support these objectives. The individual practices are malleable, the actual objectives of the stand-up are not.
Time-Boxing is Essential to Scrum
Scrum is all about time-boxing. Iterations are time-boxed. Stand-ups are time-boxed. Can you fiddle with the size of the time boxes? Sure you can. However, there are always trade-offs in doing so, including increased overhead with shorter time boxes, and a loss of flexibility and turn-around time with longer boxes.
If your team can't spare 15 time-boxed minutes per day, then you have process issues far beyond Scrum. On the other hand, if the 15 minutes per day don't add value to your team's process, then read on!
Introspect the Purpose of Your Meetings
If you find that you aren't really working as a team (e.g. individuals all have non-interdependent tasks) then you really won't gain much benefit from regular stand-up meetings. The daily scrum is for coordinating tasks and making delivery commitments within the team, but if Alice never needs anything from Bob (and vice-versa), while Fred is always working on something entirely irrelevant to the rest of the team, then the value of the stand-up is zero unless you're treating it like a PM status pull.
I've certainly worked in plenty of shops where the "team" is a conglomeration of individuals, rather than a true team within the meaning of the Scrum framework. In such cases, limiting meetings to a few planning meetings and the occasional retrospective might still be valuable, but that will be highly dependent on the nature of the work and the organizational culture.
DevOps is Not Ideal for Scrum
If your team members are performing mostly operational tasks, with some supplementary projects, then Scrum may not be the best fit for your work-flow. Scrum is really designed for projects, especially software development projects, and while it can be adapted to ongoing operations or support, there are better tools available to agile project managers.
Whether your operations tasks are ticket-based or backlog-based, you may find a pull-process like Kanban to be a better framework for your needs. It's a leaky-bucket system: work pours into the bucket, and work-in-progress limits ensure that tasks trickle out of the bucket at a sustainable (and usually predictable) pace.
You can certainly adapt Scrum up to a point, but beyond that point it isn't really Scrum. If you find that the Scrum meetings, practices, and artifacts aren't meeting your objectives, I'd highly recommend looking at alternative agile frameworks and practices.