In one of the companies where I used to work in, fifteen managers could get together in a meeting room and discuss the color of a button for forty minutes. They will speak, argue, scream, and shout, and I will be the only one doing his best to stay calm instead of taking out a gun. Does that sound familiar?
One could easily start drinking just because of those meetings. However, there is no need to point a finger; no one’s guilty. Nobody is forcing people to stay there and waste their time making points at nonsense. It’s just an enormous inertia of a human mind.
Not all meetings are evil.
There is a painless method to conduct quick yet effective meetings. This methodology can be established in a team in mere hours, and it is applicable to a wide variety of businesses, from the enterprise to a student’s project.
The software development industry has created a project management method called Scrum. “Scrum meeting” or “daily Scrum” is one of its necessary components. There is something remarkable about the software development industry: the outcome of our job is highly rational and highly verifiable. So it makes sense to learn from us how to get things done.
The roots
“Scrum” is a software development methodology, and “Scrum meeting” is just a fraction of it. Still, being small and quite independent, the idea of Scrum meetings is detachable and is valuable by itself.

Daily Meetings

The moderator conducts the Scrum meeting by asking three questions to each team member:

1. What have you done yesterday?
2. What will you get done today?
3. What are the problems you encounter?
By answering the first question, the team member is sharing positive results that he or she had achieved yesterday. These are the news that everyone’s receiving. Reply to the second question will announce promises; everyone is aligning to them. Answer to the third question will uncover difficulties that other people in the team might easily solve or should be aware of.
This is an exceptionally strong formula. It encapsulates pretty much everything that needs to be shared among colleagues every day. There is no place for the inertia of the mind and useless discussions. This kind of meeting won’t take longer than necessary. All of the participants will get something useful from it right away.
Scrum meeting is not a one-size-fits-all solution, and it is not a substitute for a meeting where a decision is to be made. The best application for the Scrum meeting is a daily meeting routine.
Three rules are to be respected to make the Scrum meeting truly effective:
1. Answers to these questions must be expressed in a positive form and in the present time.
You should tell what is accomplished at this moment, not what was accomplished (or what is done, not what was done). It is because we people listen to our own words spoken the same way we listen to somebody else’s words but with more confidence. Have you noticed that you could solve a problem just by telling a story about it to someone? It’s because hearing activates the additional resources of your brain.
By saying statements in present time and in a positive way, you are tuning up your brain to get to the result instead of diving into the process. There is a subtle difference between getting something done (process) and actually having something done (the result). The past is history that no one cares about. The future is uncertain, so there’s no need to worry. What people care about is now. So it is now that something is done, not yesterday. Say it. Otherwise, you could easily be sending a message of uncertainty to your colleagues, and you don’t want that. Present time sends a message of confidence and faith, and without faith, you are not getting anywhere.
Bad Good
I made the list of guests and rented hall for the event. A list of guests is written down; a hall has been rented, and the down payment has been wired.
I will learn how Ext JS works. Ext JS tutorials read, library integrated into the code base, and basic form editing screen has been rebuilt with Ext JS.
They drilled the walls in the office nearby so loudly that I couldn’t get myself to get anything done. Nothing has been done.
I will put down the report on toilet paper usage in the office. Staff survey complete, stats compiled, and toilet paper usage report has been sent.
Bad Good
By the way, it’s not only in Scrum meetings where this trick makes sense.
2. Tasks and goals must be clearly and precisely defined.
You can only plan to perform such actions that will end up with a definable result. An undefined goal cannot be achieved, and an undefined action cannot be taken. Fuzzy goals will not lead to fuzzy steps—they will lead to no steps at all because there is no place to step on to. Seriously, you cannot plan for “fixing lots of bugs” because it’s not clear what exactly must be done. At the end of the day, you will have to answer yourself the question, did I achieve my goals, or did I “fix lots of bugs”? You can easily give any answer to that, no matter how hard you have been working today (if ever). How much is “a lot”? What is “fixed” anyway? Anything will conform to that. No precision, not clear, not a goal, not a task.
What you are going to do must have a formally defined result, which could be verified. This is the answer to the first Scrum meeting question.
Most of the corporate goals are not something one man can do; they require a team. People cannot read each other’s mind, and unfortunately, they must discuss and synchronize their common activities.
It’s quite easy to think in defined results instead of images: if you take your time and actually think what will you do today, you will end up with a list of results, not actions or processes.
Bad Good
Will fix bugs. Tickets 234, 456 regarding screen rendering fixed; Bug 678 on commission calculation fixed.
Tested the new server. New server has been tested: configuration is correct and corresponds to the one we requested; server is added into load balancing and is serving 10% of web traffic.
Bad Good
Again, this is a trick to tune up your mind. A defined daily plan will draw you a road for this day. When you see the beginning and the end, you are a little bit more motivated to take that ride. After a few days of practice, you will find out it’s easier to concentrate on the job when you see the way. Mind you: additional brain resources for free!
3. Planned results must be verifiable.
If you are a programmer, you can think of it like this: it is a “unit test” for the actual goal or a TDD approach to your activities.
What you have done or will do must change the real world in a fashion that somebody else can verify and confirm it happened. Someone else must be able to check that the defined result is indeed delivered. As I said earlier, it’s impossible to verify if “a lot of bugs have been fixed” simply because no precise answer to that question could be given. Hence, it makes sense to formulate verifiable tasks.
This really helps to keep the goal in mind while you are doing something, not the process or the context (“I am fixing this line of code”) but the goal (“I am giving people the ability to change the avatar in the profile”).
Then you have to understand that a nonverifiable result is not a result. How do you tell valuable and useless activities apart if there is no definition of value?

(Note: Despite “have discussed” is said in past time, it still speaks about the current state of things.)
Bad Good
Will discuss the placement of chairs in the hall with construction workers. Have discussed chairs placement in the hall; a draft blueprint has been sketched along with the quote and sent to the financial department.
Bug 457 regarding wrong avatar picture fixed. Bug 457 regarding wrong avatar picture fixed; the correct avatar is now showing in the profile page.
Bad Good

The Protocol

The same person (moderator) must conduct the Scrum meeting every day at the same time in the morning. The meeting should last for a few minutes to half an hour. Think of it like a heartbeat.
The Scrum meeting must be conducted with all participants standing. People do not like to keep standing for too long, so the stand-up meeting will successfully finish much sooner. Not to mention that programmers must also step away from their computers at least once a day and have at least this level of physical activity.
Get ready. You must devote a couple of minutes before the Scrum meeting to define your targets for today and check yesterday’s achievements. Otherwise, you are going to painfully create this information during the Scrum meeting. By doing this, you are going to bore your teammates to death and permanently injure your moderator. The Scrum meeting is a process of information exchange, not creation.
The moderator should always speak the question. One can think to himself, why shout the same question every single day when everybody knows it precisely? Not true. If you skip the question, then the very idea of the Scrum meeting will eventually fade away. You have to ask those three mundane questions over and over again. If the Scrum meeting is the heartbeat of the project, consider those questions the heartbeat of the meeting.
Do not steer out of the lane. People easily switch between “what I have done” to “what I will do” right in the middle of a sentence. It’s understood: tasks sometimes come consecutively one after another, and it’s completely natural to start using common language for the future. Still, you have to keep the meeting in the flow. First, report the success of the previous day, and then you are allowed to start dreaming about today.
No discussions. The Scrum meeting is designated solely for the sharing of the work done, work planned, and troubles found. This is what everybody should focus on. While one person is speaking, others are carefully listening. Got a question or comment? Note it down and ask it later privately.
No reporting. It’s crucial that the meeting does not become a report to the management. The meeting is for information sharing and planning: this is a promise that allows everybody to be open and honest. Otherwise, the meeting will slowly transform to a factory of corporate bullshit that no one cares about.
…unless all you plan to do is to eat chocolate to have at least one thing done every day… (unknown author about GTD).
No criticism and opinions allowed. Even nonverbal exclamations are strictly prohibited. Nobody’s perfect, and no project is flawless. If your teammate says that he “only played World of Warcraft the whole day,” then it’s truly valuable that he actually can say it straight and be heard. We all sometimes fall in the days where the only thing you apparently can do is play a stupid game. If you are going to punish people for that, they are going to lie about what they did, and the value of the Scrum meeting will vanish.
100% attention. Complete prohibition of any communications during the Scrum meeting must be enforced: messengers offline and cell phones turned off. Break of context in the middle of a Scrum is going to cost everybody their attention.
Conduct a Scrum meeting for yourself if you alone are the whole team. Open a file and write down “What have I done yesterday?” Write the answer two lines below. There is nobody around to share information with, but you are still allocating resources of your mind to help you work better. You can conduct a Scrum meeting with a mirror; that works well too. Make sure though that your girlfriend doesn’t accidentally find out.
Return the question if not properly answered. It’s not at all easy to get used to all the principles and rules I stated here, so the first Scrum meetings in your project are going to be terribly long ones. For example, once in one of the teams where I ran the first Scrum meeting, one person could not formulate a positive answer in present time. He just couldn’t. This was the way his mind didn’t work. I returned the question to him for two hours in a row until he clicked. In one moment, he had this revelation, and the right answer came out. Poor buddy! The whole team won at this moment.
“Enough! I’m starting a new life (effective Monday)!” said Mr. Looser.
Just do it. Scrum meeting is something that pays back immediately in almost any team or project. It is easy to start. Do not wait for the end of the current iteration; begin conducting Scrum meetings right now. Do not look for the next project to begin with this practice. Do not even wait for the new day to come: start now, right now.

No Pain, No Gain

Scrum meeting is something new, and most of the time people do not like changes. Some people are going to hate it. Therefore, the management must enforce the practice of Scrum meeting in a team in the first place, but only if the decision maker is indeed aware about all the benefits that Scrum meeting is going to bring into the team. Otherwise, there could be lazy stubs like “Come on, it’s all clear today. Let’s skip the Scrum meeting.” This way, you will never get a heartbeat in the project. In time, the urge to skip another Scrum meeting will come up every other day and fail. Laziness hates daily meetings.
Even if your project is doomed, let it have at least one thing done right: the Scrum meeting. Call it a cornerstone. Projects come and go, but the cornerstone stays in its place.
About the author
My name is Egor Egorov. I am a project manager, a business analyst and a programmer with over 20 years of experience. I specialise in backend development of mass serving systems.