It seems that many organisations have the problem with too many meetings, which means less time for doing the actual work that generates value to the customer. This regard both traditional organisations, and organisations changing to an agile way of working, especially at scale.
Let us start to divide meetings into four different types of meetings; line administration, project/product administration, problems and meetings within functions or transdisciplinary meetings between different functions for the solution of the actual work. The first three need to be minimised and can be seen as waste, as they do not generate any value to the customers.
Line administration meetings
The line administration is context independent and need to be done no matter what our organisation is doing and is a cost we need to take, with different kind of meetings. In most organisations we commonly have weekly, monthly, quarterly, etc, starting with the managers at the lowest level having the weekly meetings with their employees within their area of responsibility. The higher up in the line hierarchy, the fewer meetings for everyone below the manager organising the meeting. On top of this we of course have yearly salary, and follow-up and career meetings for every employee, a short meeting every week between the manager and the employee, educations and so on. This means that this kind of meetings do not differ very much if we have a traditional organisation working with projects or an organisation working with an agile mindset, since the line administration need to be held with meetings in some way or another.
Project/product administration meetings
Project/product administration is meetings needed to understand what, why, when, who in order to implement the product or service, and they are highly context dependent. Especially in organisations developing software and/or hardware products, these meetings will be too many, and generate an enormous waste, if our way or working are not efficient and effective. Here efficient means developing the product right and effective means developing the right product.
Problem meetings
The third type of meetings is meetings to discuss problems. Yes, only discuss problem, not solve them, which is unfortunately mostly what it is done, so another meeting needs to be booked for continuation, and so on. The reason is simply that the problem is only a symptom of something deeper rooted, and many organisations never look for these root causes. But to solve symptoms is impossible, just think about only wiping up the oil under the car. The oil is only a symptom, so wiping it up won’t help, it will come back. We instead always need to find the root causes to our problems, there is no other way of getting rid of the problems. And without any solution to the root causes of our problems that can be organisational or within our products, only more meetings are needed. As we can understand, unsolved problems within our products or organisations will generate a constant flow of meetings, if we only take care about the incident, since by only trying to put plaster on the symptom, will not dissolve the root cause. This means that the incident will come back, normally in the same way.
And here we need to be vigilant to the retrospectives done in agile, once again especially at scale, since then the teams have a lot of interdependencies between themselves, as well as the complexity is high. This means that we need to find the root causes to the problems that are hindering a team, which may be outside the control of the team, so we cannot frame the solution to be possible to be executed by a team, or team of teams. The root causes may also have occurred in the past, long before the start of the sprint or increment, where the retrospective is performed, so we can neither frame the solution to be found only in the examined time box. If the root causes only can be dissolved at a team of team levels, or even as high as the portfolio level, trying to do a solution on a lower level only means sub-optimisation, since we then are only trying to solve symptoms. This means also a waste of meeting time, and waste of time trying to solve the symptoms, which means no gain for the total organisation.
Let us take some examples what happens if we not dissolve the root causes to our problems.
Traditionally big organisations developing products had big projects, which due to the big size of the projects, could be handled by a majority of full-time resources, even though they were specialised (I-shaped competences), compared to broad competences (T-shaped). But, the last decades, smaller companies have started to compete by making smaller and faster projects. If we think about it, that means that smaller companies have the big advantage of broader (T-shaped) competences among their employees, while bigger companies normally are more specialised. This in turn means that bigger organisations need to use part-time resources in smaller projects, while smaller organisations can use full-time resources, which generates an enormous increase of project/product administration waste for the bigger organisations. If we estimate 25% waste (meeting time) for every project an employee is working in (and increasing for every project due to Miller’s magical number seven), some simple calculations give us that when any employee reaches 3-4 projects, only overtime can generate value for the customer. For smaller companies that are able to compete with bigger ones, often outside the bigger organisations core competencies, the efficiency can differ 2-3 times in speed or developing 2-3 times more products, mostly due to this waste.
If we instead make our activities smaller and smaller like agile way of working to achieve fast deliveries, we will have the same phenomena of project/production administration waste. This means, that even if we now can use the same employee or team, we instead need to put more and more effort in breaking down the activities in smaller activities meaning more coordination, which is actually needed when having specialised resources. And every time we start an activity means a context shift and a lot of energy to understand how to solve the activity, which also is waste. But small activities also mean something more, it means not only longer, but also more queues, which we can refer to as mean queues, which always are wasteful.
So with specialists, we have people (or teams) in queues to handle bigger activities, but in agile we instead have smaller activities in queues to people (or teams), and queues always generate more problems. Also, in agile development, especially at scale, where the teams work together, but where the too small activities easily generate quality issues on the whole, if not having an appropriate top-down approach.
But, as we stated, the difference between specialisation and small activities of work, is very small and both generates more meetings, where no actual value for the customers is added. And many times, when having problems with efficiency and effectiveness, both traditionally and at agile at scale, the solutions to these problems have to specialise even more for the former and even smaller parts for the latter. And note also that, the smaller the activities become, the more specific they will be, which over time in turn means a high risk for specialisation between employees and teams also using agile methods, especially when scaling agile in big organisations. The end point will be specialisation also for agile development, in the same way as for big traditional organisations, even if the starting point is different.
We can conclude that the second and third types of meetings need to be reduced to a minimum, because otherwise we will have too little time for the necessary meetings where we are solving our activities that brings value to the customers. And it is also easy to see, that if we not dissolve the root causes to our problems, it will not only generate more meetings for discussing problems, but it will in many cases also generate more project/product administration waste meetings and/or more participants at the existing project/product meetings.
Another thing to consider is that without looking for all possible root causes to the symptom of too many meetings, it is too easy to blame only one root cause. This is frequently happening now when we have been having covid-19 for 1,5 years, and working from home has piled up more meetings, blaming covid-19 for all the extra meetings, which can be true to some extent. But, if an organisation at the same time has made a transformation to another way of working, this can also be a root cause if the new way of working is not working as expected or promised, or the way of working is anti-systemic as Dr. Russell Ackoff would have stated it. Because if the new way of working is not functioning as expected, there will for sure be many problem meetings, especially if the new way of working does not check for its own internal malfunctions, which unfortunately is the normal case.
Therefore, dissolving the root causes to our organisational problems are always top priority to remove and reduce wasteful meetings. Otherwise, we cannot know when we have unnecessarily too many meetings and/or unnecessarily many participants at the meetings.
This was all for today.
C u soon again.