Have you ever heard of this phrase “We do Scrum, but hate the meetings”? If you have any experience working with teams that are new to Scrum, I have a feeling you have heard this at least a few times. There are many misconceptions about Scrum that are formed either out of lack of understanding or lack of experience, but this is very common. Many organizations that are trying to adopt Agile/Scrum practices go through this learning process, which can be challenging and frustrating at times. In this article, I will give you a few tips on how to address a few common misunderstandings that often arise during an adoption.
First, let’s address the concept of a “meeting” within a broad context of any business organization. Nobody likes meetings. They are boring, inefficient most of the time, and often takes away precious time for “real work” to be done. The concept of a “meeting” usually carries a negative connotation simply because most business professionals have most likely experienced their share of poorly run, meaningless meetings that are simply perceived as a waste of time. Now, why does this matter to organizations that are trying to adopt a new way of thinking and working? This is important because terminology can often make a significant difference on how we (human beings) perceive something. As a result, my recommendation is that we make a concerted effort to avoid the term “meeting” whatsoever when we refer to various Scrum events (i.e. Sprint Planning, Sprint Review, Sprint Retrospective, and Daily Scrum).
While this may seem a bit drastic and meaningless to you, I can assure you that nomenclature does indeed make a difference. You don’t need to take my word for it. The founders of Scrum, Jeff Sutherland and Ken Schwaber, purposefully changed one of the terms within the Scrum Guide in recently years based on this very same principle. As you might recall, Scrum activities were referred to as “ceremonies”. Now, this term sounds very formal and heavy, doesn’t it? It didn’t feel very fitting to use this term for a framework that is intended to be light-weight and flexible. As a result, the Scrum founders decided to change “ceremonies” to “events”. This proves that there is an undisputable implication to the terminology due to the perceptions that are formed by that simple word.
So, if we avoid the term “meeting”, what should we call these Scrum-focused activities? Although “event” seems a bit less heavy than “ceremony”, it still sounds fairly involved. After all, the Olympics are considered an “event”, right? In effort to stay true to the Scrum Guide, I would suggest the term “event” or perhaps a variant, “collaboration event”. I believe that if you can stay away from the word “meeting” or “status meeting”, it is much more advantageous in encouraging your team members as well as your management to start developing an Agile mindset.
Terminology aside, when someone makes the statement “We hate the meetings”, do they truly hate what happens in those meetings, or do they simply not understand the value of the activities that take place?
I think that most professionals tend to fall into the latter group. Most folks new to Agile principles and practices feel that there is increased amount of “overhead” due to the numerous activities that are added, which may be perceived as “additional work”. I think this is very common and natural; if a team is used to meeting once a week to talk about where they are with their assignments (within the dreaded weekly project status meetings), they certainly need time to adjust to the additional effort and transparency that Scrum will bring to the team. The team will need time to get used to meeting (I mean collaborating) every single day. They will need to learn to plan their work as a team, and demonstrate progress, and be held accountable on a regular basis. They will need to understand that they can no longer hide in their cubicles and only pop up when they feel like it. This new way of doing work will be difficult for many people.
To management, all this “extra” overhead may seem like a waste of time. They may not understand why the team is playing poker, or why the team is putting Post-It notes all over the wall and talking about their problems. They may expect something completely different. As Agile practitioners, we need to educate those folks and help them understand WHY we do everything in Scrum; it is our responsibility to help them see the value in everything we do. Why do we meet every single day instead of once a week? Why do we NOT have a status meeting? Why do we reflect on our successes and challenges regularly instead of at the very end of the project? All these things need to be explained and communicated in order to dissolve the misconceptions that are formed easily, especially by those who are on the outside looking in.
In summary, do we expect folks who are new to Agile to fully understand the value of every activity? Probably not right away. It’s not easy to demonstrate the value of higher quality and lower rework, but it is much easier to demonstrate working product on a consistent basis. I encourage you to take a closer look at how your team and your organization uses Agile terminology, and how you are communicating the value and benefit to the stakeholders/customers. With a new minor tweaks, you may see dramatic changes in how people react to or perceive Agile/Scrum.