Can we do Scrum without meetings?

Developers hate meetings. They seem such a time-waster. But there are a lot of meetings in Scrum. Way too many for some people’s taste.

Completely dropping Scrum ceremonies is out of the question. They are the main sources of communication and feedback that enable empiricism – the main advantage of Agile. But do we really need meetings for these ceremonies? Can’t we get the feedback continuously?

  • Do we have to run daily scrums? We sit together in the same room. We can coordinate throughout the whole day, as needed, not only once a day in the morning.
  • Why review our work with stakeholders only once a sprint, in a big batch? They’re sitting at the same office. We can make a review feature by feature, just as they are completed.
  • Wouldn’t it be better to discuss improvement ideas immediately when one comes up, instead of waiting till the end of a sprint to make a formal meeting out of it?
  • We’re doing continuous integration. Why do we need sprints at all? What’s the benefit of arbitrarily timeboxing our work?

I hear a lot of arguments in this vein. And they sound reasonable. Isn’t Agile, after all, about getting feedback as frequently as possible? Isn’t it in the spirit of XP to amplify good practices to the max? Why, then, Scrum ceremonies are so rigidly scheduled? Is it possible to break free from the tyranny of meetings? What are the risks?

Why Scrum ceremonies have prescribed meetings?

In short: because it makes things simpler.

Blocking explicit time slots for ceremonies has a lot of benefits:

  • It’s easier to be consistent; it’s hard to skip a ceremony if there’s a preplanned time slot for it.
  • It’s easier to plan your work around a ceremony if it is scheduled in advance, so there are fewer interruptions.
  • It’s easier to find (and defend) time for a ceremony under pressure if it is a part of your fixed sprint schedule.
  • It’s easier to fully focus on a ceremony – and in effect get better results from it – if it’s an explicit, computers-off meeting.

Scrum purposefully prescribes fixed, distraction-free time for all its critical ceremonies to maximize the chance of doing them often enough and well.

Is doing Scrum ceremonies continuously bad, then?

No, of course not. Scrum is only a reasonable minimum, a starting point you can – and should – further build upon. You can’t drop any of the Scrum ceremonies without damage to your agility. They were designed to work together and they won’t work nearly as well if any of them is missing. But of course doing more of the good stuff won’t hurt.

Unfortunately, it’s not as simple as a “let’s drop a ceremony, it will happen continuously by itself just because we’re sitting together in one room”. Making Scrum ceremonies continuous requires a lot of deliberate effort and discipline. And it’s easy to fall into one of many traps waiting for the would-be continuous Agilists.

Potential pitfalls of continuous Scrum ceremonies.

Dropping a prescribed practice not because you can do better, but because the practice is hard.

Why are you considering Kanban-like flow based approach?

Is it because:

  • You consistently split user stories into tiny vertical slices and deploy them continuously?
  • A sprint boundary feels like an artificial limit, way longer than the build-and-release cycle you’re capable of?
  • You’re so good at Just-In-Time work that planning the whole sprint worth of stories in advance seems like a waste?

Or is it because:

  • You have trouble fitting any business value into such a short timebox as a single sprint?
  • As a result, your user stories frequently spill into the next sprint?
  • You feel the sprint boundary artificially limits the size of user stories you’re allowed to work on?

Are you sure you want to make a Scrum ceremony continuous because you can consistently do better, not because it feels like a struggle to adhere to what Scrum prescribes?

Diluting a ceremony to a point of losing its benefits.

If you drop the daily scrum meeting, will you really have the discipline to still get all the feedback and synchronization it is intended to provide?

Of course, it is ridiculous to wait till the next morning to move a card to a different column of a sprint board or to inform the team about a serious impediment. You should do it in “real-time”.

But what about evaluating how the team stands against the sprint goal? What about planning how to divide and parallelize work among all the team members? Does it also happen in “real-time”? Are you sure all team members are on the same page? Are you sure they still regularly pause to think how to reach the sprint goal most effectively?

And are you sure this synchronization isn’t neglected under pressure or when you are in a flow state, oblivious to the world around you?

Reducing the scope or transparency of a ceremony.

Of course, there’s no point in waiting for a scheduled sprint review if your stakeholders are close at hand, have time, and are willing to review features one-by-one, just as you finish them.

But did you consider this:

  • Are you doing such a just-in-time review for all stakeholders or only for a few key ones? What about the rest? How can they see your work and give feedback?
  • What about people who may not have time to do review just-in-time (e.g. your CEO)?
  • What about people interested only in a few selected features? Can you identify all these people? Do they know how to let you know they’re interested in seeing a particular feature? Will you remember about them?
  • What about other development teams? Will you also run individual reviews for each of them? Will you interrupt all of them several times per sprint, each time you complete a feature?

Are you sure you won’t leave some people out of the loop when doing a just-in-time review?

Not understanding interactions between a ceremony and other ceremonies.

Scrum is a complete package. Most of the ceremonies work together or provide input to other ones.

OK, so you have dropped sprints and are deploying continuously. Great! But after you deploy a feature, how do you know what feature to build next? You’ve just forced yourself to do also continuous planning. And to do proper planning, you need to know stakeholders’ feedback from the review and you need a refined backlog. Bam! By a chain reaction you’ve just forced yourself to do also a just-in-time review and a just-in-time backlog refinement.

Don’t get me wrong – doing everything just-in-time is awesome! But did you really consider all the implications when deciding to remove sprint boundaries? Did you consider the burden it will put on stakeholders, PO, domain experts and other teams? Are you sure your organization can handle it?

Breaking your focus or doing too much of a ceremony.

By doing a ceremony continuously you can not only dilute it – you can hit the opposite extreme and overdo it. It can also work against the first of the 5 Scrum Values: Focus.

If a sprint retrospective is scheduled as a meeting the focus is clear: during a sprint we focus on delivering the sprint goal, during a retrospective we focus on improving our process. We can discuss ideas, decide what actions to take, and afterwards during sprint planning, take these actions into consideration, so they don’t collide with our sprint goal.

But consider you can come up with improvement ideas anytime one comes to your mind:

  • How do you discuss such an idea with your team? Do you instantly interrupt their work? Or do you put the idea down in some backlog?
  • If you put the idea in a backlog, when do you discuss it? When do you decide what actions to take?
  • When do you implement your improvement ideas? How do you make sure you don’t endanger sprint goal by focusing too much on improvements? How do you make sure you implement any improvements at all when you’re focused on your sprint goal?
  • When do you evaluate improvement ideas you’ve implemented?

Are you sure you know what to do to properly focus both on your sprint and your improvement ideas when doing continuous retrospectives?

So when can we do Scrum ceremonies without meetings?

Scrum is like a factory car: it works pretty well out of the box (if you know how to use and maintain it) but it performs much better after tuning. Don’t try tuning a car, though, if you don’t know what you’re doing. You’re much more likely to break it than to improve its performance.

Before you decide about making any of Scrum ceremonies continuous, consider if:

  • You understand all the benefits the ceremony is intended to provide.
  • You understand the full scope of the ceremony: which people it influences, how does it interact with other ceremonies etc.
  • You understand which benefits of a fixed meeting you lose by making the ceremony continuous and how to mitigate this.
  • You’ll have enough discipline to maintain the practice even under pressure or when facing a crisis.

If you feel any doubts, there’s a high chance you’ll shoot yourself in the foot by making the ceremony continuous.

Over to you.

What do you think about meetingless Scrum? Is it worth trying or are the risks too high? What other pitfalls of such a continuous approach do you see? Please share your opinion in the comments!


2 thoughts on “Can we do Scrum without meetings?

  1. Brilliant article, lots of really good thoughts about agile and its drawbacks.
    I have exactly the same feeling in my team: when I add up all the time spent on meeting, I realise that we are actually not agile at all.
    From my perspective the frequency of meetings is less of a problem than the heaviness of those meetings, because several people take advantage of those meetings to overkill their input on the project.
    My scrum master and PM like to invite the whole planet for each meeting, including out of scrum people – this removed the focus and the efficiency if the team


  2. Thanks!

    Apart from the heaviness you mention, I also often encounter simple inefficiency of meetings: starting late, delaying because of technical problems (connecting remote people, preparing for note taking etc.), attending unprepared, having no agenda / no clear purpose of the meeting and so on.

    Because of these two factors (heaviness and inefficiency) there is often a strong pushback from the developers against meetings. This is unfortunate, because at their core these meetings are actually valuable – but the poor execution kills most of the benefits (and discourages people).

    Therefore, I usually recommend to try improve the meetings first: start on time, fit into a timebox, designate a dedicated moderator, prepare beforehand etc.

    Two most powerful things you can do are, in my opinion:

    – to invite fewer people (it seems counterintuitive for some, but it’s not necessary to invite the whole Scrum Team for *all* the Scrum meetings; 2 or 3 engaged, focused participants yield much better results – and in a shorter time! – than the room full of half-sleeping, yawning people)

    – to offload as much preparation and “post-processing” as possible outside of the meeting (for example to estimate User Stories you should read them *before*, not *during* a meeting)


What do you think?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s