Hold the event daily, even if you don't use the whole time box allocated for the meeting. Don't skip it routinely, even if you think you have good reasons. Doing so may not bite you right away, but it probably will eventually.
If you're not finding value in the Daily Scrum, it's likely because the team isn't really performing just-in-time (JIT) planning, deferring decisions until the last responsible moment, or respecting the time box of the daily increment. There can be other reasons too, but these are usually the top reasons. More about the purpose and value of the event are covered in subsequent sections.
From a framework perspective, if you don't hold the Daily Scrum as a required event, whatever you're doing isn't actually Scrum. It may or may not work for your project—I've never seen routine skipping of the fifteen-minute Daily Scrum lead to real process improvement, but your mileage may vary—but the result of skipping core framework events is not Scrum.
If you complete all the objectives of the Daily Scrum in less than fifteen minutes, the Development Team can certainly end the meeting early. However, frameworks like Scrum work best with a predictable cadence and routine inflection points, so routinely discarding the daily meetings should never be part of your Scrum implementation.
More About the Daily Scrum
The Daily Scrum is a Mandatory Event
The Daily Scrum is a mandatory event if you intend to follow the Scrum framework rather than simply be "agilish." I would strongly recommend not tinkering with the framework until it's been mastered; even then, there are benefits to adhering to a well-known framework rather than rolling your own.
Event Purpose: Just-in-Time Planning and Intra-Team Coordination
The Daily Scrum is needed for just-in-time planning. Agile frameworks generally leave implementation decisions until the last responsible moment. In the case of Scrum, Sprint Planning is generally a higher-level activity that defers some amount of planning and coordination to the Daily Scrum.
You can also think of the Daily Scrum as a mini agile cycle within the Sprint. You can frame this event as:
- A planning event for the next 24 hours of work.
- An internal coordination meeting to synchronize work on the Sprint Backlog.
- A short-term dependency planning meeting for the Development Team.
- A chance to identify intra-team dependencies or impediments related to the day's work-in-progress.
- A formal place to raise risks to the Sprint Goal that should be addressed outside of the meeting's time box.
The first is explicitly covered by the Scrum Guide, but the other items are largely implicit in the framework's theory and values, as well as interpreted values and principles from the Agile Manifesto.
Process Predictability Trumps Efficiency (and Pseudo-Efficiency)
Having the Daily Scrum every day, even if you don't use the entire time box, provides a reliable cadence for the Sprint and a predictable inspect-and-adapt inflection point for the Development Team. Frameworks like Scrum typically value predictability over efficiency; while the Daily Scrum often delivers both, the predictability of reserving a daily event where unexpected issues or coordination activities can be addressed with the whole Development Team shouldn't be underestimated.
In many cases, skipping the Daily Scrum may look like an efficiency win, but it's actually an outgrowth of the 100% utilization fallacy. It often leads to information silos and reduces whole-team collaboration and swarming behaviors, which is definitely an anti-pattern that leads to reduced efficiency over time.
Even when efficiency gains are possible, Scrum values transparency and predictability over raw efficiency. Reducing the visibility of blockers or intra-team coordination is an anti-pattern that works against the framework's empirical control theory. Removing the predictable cadence of this daily whole-team, inspect-and-adapt event is even worse.
Failing to provide this routine and predictable framework event seeks to trade transparency and predictability for "efficiency" (real or imagined), and is almost always the wrong thing to do. There can certainly be edge cases, but a permanent reduction or elimination of core events is always a framework implementation smell—and a pretty ripe one at that!