Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
Let's suppose we have a small development team: a front-end developer, a back-end developer and a tester working in the same room and therefore able to communicate freely throught a day.
Is it reasonable to have daily StandUp's for such team (whether they use Scrum or Kanban)?
Scrum prescribes these daily StandUp's, but they just don't seem to be always necessary.
One of the advantages of having such a small team is that, indeed, the people in the team are able to communicate freely throughout the day. A lot of the daily stand-ups might thus often end very quickly and may look like they are a waste, but they can still have a purpose even in a small team like this: to provide extra focus.
The daily standup allows people to keep the sprint goal in sight so that they don't just organize their work, but organize their work to make progress towards the goal. That's the important thing. Your team might work and communicate efficiently, but sometimes they might focus too much on the work they are doing. A daily discussion around the goal of the sprint reminds people of why they are doing that work.
Of course, nobody forces you to have daily standups if not much is discussed or agreed upon there. You can build your own process around whatever events or artifacts you want, basically keeping from Scrum what works for you and discarding the rest, but the result can no longer be called Scrum, it will be your own thing.
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.
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.
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:
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.
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!
