Do you want our logo?
Do you want our logo descriptionKnow our brand.
Do you want our logo?
Do you want our logo descriptionKnow our brand.
"We have many meetings", was the concise and categorical reflection of one of my office colleagues. Many meetings, too many. And the truth is that I agree with him. Also, many times these meetings are not celebrated with a clear objective and have common execution errors that make them, in general, unproductive.
Being more specific, my colleague specified: "in Scrum there are many meetings". And there, at that particular point, I could not agree with him. But why? Well, the time has come to justify it.
In my experience, this idea mainly has its origin in the following problems:
Scrum training cannot be left just to a simple introductory talk when a worker joins the company. During the first weeks/months, it must be clear what Scrum is and what it is not, and also to avoid that concepts blur slowly or get confusing with the passing of time.
In Paradigma we have this very internalized and very present in our day to day. Periodically we refresh concepts to the teams through new training and access to certifications, we try to make a community of good practices in the field of Agile and we are quite accessible when it comes to solving doubts.
The second one is that certain roles of certain relevance in teams (such as the Scrum Master or the Product Owner) bring with them a medley of ideas under the "Agile" moniker. This means that practices are encouraged on behalf of Scrum which are not Scrum. Doing this, we confuse people.
For example, I have been told about 45-minute daily meetings (hopefully they are not standing up). Or of reviews that are directly "demo to the clients", where the Product Owner does not intervene at all.
I have also read an article that proposes making micro-retrospective meetings on a daily basis, completely uncalled for.
Other cases such as the refinement of the product with the entire team to make an estimate of everything that was agreed. All of these are bad practices and, when in presence of it, the Scrum Masters (properly trained) should act as agents of change.
This has happened to me, for example, with the committees of senior management (steering committee). Since Scrum events are scheduled in a somewhat rigid manner, senior management, despite being invited, usually does not attend.
That's why we created these committees, due to the lack of presence of this layer in the day to day of the product. I am not saying that they should not be done, as they obviously solve this problem, but we do not take full advantage of the Sprint Review.
The same goes for weekly follow-up meetings that are pseudo-plannings and quasi-reviews.
It is true, on many occasions we do not use the Scrum events to innovate and to do an inspection and adaptation exercise and that makes the teams themselves have a somewhat negative view of them.
It happens with boring and eternal Sprint Planning, or repetitive Daily meetings in which the objective of the Sprint is not looked at. They are examples of low productivity.
With everything mentioned, it seems that there still seems to be too many meetings. Let's think for a moment what event we would remove if Jeff and Ken (creators of Scrum) gave us permission to eliminate it.
Planning? And we leave everything to the free will and the good work of the development team, which has not met at any time so that nobody explains what should be developed?
The review? And take the opportunity to see those interested and share with them the progress of the last period and make future projections?
The retro? Are we removing a fundamental moment for the team to meet, with the sole purpose of reviewing its process and improving it?
The daily meeting? You really cannot spend 15 minutes a day to see how we are doing in this Sprint and count the possible impediments?
Note: Refinement meetings are certainly not a Scrum event, but a means that some of us have found valuable to refine the product and that should not exceed 10% of the capacity of the Development team.
I find it very complicated to remove any Scrum event because they all have great value.
Nowadays, companies have a deeply rooted culture of meetings. Perhaps the first step, in addition to reducing and simplifying the meetings, is to get more out of them.
I have made a small inventory of some tricks to make your meetings more effective:
Before calling it, consider yourself: should it be done? I glanced at this page from our friends at Atlassian, where they work out that in the US they spend around 37,000 million dollars in meetings. Do we reflect in our companies what an unproductive meeting costs?
Sometimes we think that a "better" idea will come out of a meeting than a person alone could get to. But there are certain symptoms in the groups that tell us that you are not able to make correct decisions alone.
This is called groupthink and there are several examples in the history of wrong group decisions, such as the refusal of the American army to acknowledge that an attack on Pearl Harbor was possible. As Larry Page says, co-founder of Google, "no decision made by the company should wait to hold a meeting to adopt it".
It is something to be encouraged in the group as something fundamental. Something that can help set the start time is that the attendees mark the attendance or not in the call, this way you do not expect someone who will not come.
That there is a script known by all can help get to the point and once finished, does not make you wander more.
They must have a maximum time of duration and must be fulfilled. Even if you have several parts, you can set a maximum set time for each one.
That the room has the appropriate means such as papers, pens, blackboard and markers, HDMI connectors and screens/projectors...
This seems silly, but in certain areas of work I have found that there are no minimum conditions to work and if this is so, it is better not to set the meeting.
The actual distribution of the attendees in the room, trying to be circular (around a table evenly) and distributed (sitting in an interspersed way the closest, avoiding niches related to area or project), helps to improve communication and confidence among attendees .
You also have to pay attention to temperature, ventilation, smell, available water...
Meetings usually have a before (a prior preparation) and an after (consequences or actions). It is responsible and respectful towards the time of others to perform those tasks timely.
In the meeting there should only be those who have to be (I support the famous rule of the two pizzas of Jeff Bezos, Amazon).
Not all of us have the same character to give an opinion. Give space to everyone to express themselves. Seek consensus and try to avoid the dictatorship of the intransigent minority (the most intransigent impose their opinion on the rest, who are more conformist).
There are people who have the ability to impose their opinion and it does not have to be the right one. There is a technique of "bounce questions" that can be useful and that can be easily illustrated with phrases of this type: "It is interesting what you say, to see what the rest of the group thinks".
Sometimes the lack of trust among those present can ruin a meeting. This does not always apply, but if it is a group that will have to work together for a while, it can be interesting to perform previous team building dynamics.
Innovation is fundamental, always look for people to be active. This helps change the traditional concept of meeting and embraces a new one: collaborative, fun and learning. For example:
Last but not least: put the highlight (one of the Scrum values) and end your meetings giving solutions.
Oh, one more thing! In addition to taking care of meetings, also respect the moments of work and concentration of your colleagues. If we do not do "meetings" outside of meetings, we also encourage greater productivity.
Comments are moderated and will only be visible if they add to the discussion in a constructive way. If you disagree with a point, please, be polite.
We are committed.
Technology, people and positive impact.