The imprisonment caused by Timebox

The problem

You should be extremely ashamed of yourself if you are in a meeting, which is neither a lecture or a training, and I will explain the reasons why.

It is very common to find selfies on the social networks of Agile Coaches. These selfies show a multitude of backgrounds, with a beautiful smile accompanied by the words: “starting another release planning” or “another review of a roadmap is ready, thank God!” This is a pride that is very common among the new generation of Agile Coaches. However, it should bring them shame, since it is a crime against the time of all people involved; against the service itself, and against financial efficiency.

It does not mean that you should get rid of super-crowded meetings immediately, but you should be ashamed of them, as they are inefficient mammoths throwing resources of the company in the drain and trash. Those resources should actually be applied on company’s improvement, improving the positioning and recognition of organization to the market.

This culture, widely disseminated by the poor understanding of what is, in fact, a horizontal company, has been widespread with the popularization of Scrum and its scale frameworks that attempt to solve the problems that Scrum itself creates. In that regard, we can perceive a paradox, since, in an environment where self-organization is preached, these solutions increase the cost of coordination by creating constraints — such as date, time, place, agenda — thus, being harmful to the emergency, fundamental property that makes a complex system to organize itself.

Proponents of such a model try to justify it with the old well-known shield of the “context,” repeating the mantra that “in their company, things work differently.” Part of that is fact and part of that is fiction, for there are universal principles, especially in the study of complexity, which are transversal to any context, from Biology to Economics.

The point here is that we cannot call a meeting with time and location scheduled a self-organizing complex system by just changing the name ‘the meeting conductor’ to “facilitator”. Far from fostering self-organization, this mindset chains what we call complexity by hampering the wonderful phenomenon of emergence.

In attempting to cope with it, popular scale frameworks such as SAFe create more moorings of the same nature, desperately trying to reduce the growing lot size on railway structures, to the detriment of the much-needed freedom of complex systems. Thus, they kill the emergency.

I’ve seen myself in several situations where I needed to “facilitate” a meeting with 10, 20, 30 or more people. I had a microphone and a stage. It may sound absurd here and now, but believe me, within some giant projects, in giant companies, trying to follow in the footsteps of agility, it seemed to “make a lot of sense” to me!

But it definitely did not, and it never will. That is not the way to solve things. But I was ashamed of that. I was ashamed of the amount of money invested for such low results. A few people involved come out with some concrete action, a few people involved help in the decision-making process.

If you release the timebox collar, allowing the system to organize itself in its natural environment, it will reap the rewards of the results that will appear from the time left on people’s business day.

The Solution

The fact of me being ashamed led me to some action towards to addressing the problem of meeting effectiveness, such as measuring the costs of the meeting and outlining new governance structures that would maximize the meeting results with less investment.

A Fractal Structure

The governance of the portfolio suggested here is based on a fractal structure, that is, at each level of vision and analysis, we only look at what is important to make decisions at that level. This kind of organization allows us to quickly access the information needed at that moment, in that decision making, streamlining the whole process. Each level of it has a well-defined and organized history of the measured data. This facilitates their return, whenever necessary for analysis, to some state of the past.

The solution suggested is based on channels of distribution of information and decisions. With that, we try to organize the decision-making process, making only a small and well-selected group have their time dedicated to what is being discussed.

The image below uses Kanban’s cadences and Klaus Leopold’s flight levels to show how to organize governance by targeting the effectiveness of meetings.

This model does not go against any horizontalization and democracy of the companies that have more modern ideas since we encourage representatives of all levels to be present at all levels, with the exception of the top management, which should be with its vision concentrated at the highest level, in the strategic directions. This model believes that a good c-level only goes into detail in very specific cases, trusting that the system is doing its best at all levels.

Here we take the hook as the keyword of this model: trust. Believing that decisions will be made without the need for a “facilitator,” this model tends to reduce costs and then maximize the outcome of meetings, ceremonies, and reviews.

You should have only those ones who are needed to make decisions and to propagate the information. You should keep the information channels clear. Additionally, you should make the policies and narratives stick to everything.

It is very important to note that all channels of communication are “two-way” and any decision made at any level can be challenged by anyone. Any challenge to a decision or idea can originate in a meeting, and in this meeting, only the necessary people will participate.

Defenders of big rooms may argue that there is a need for this type of meeting. Because if the one who challenged the idea was at the original meeting, then the company would have avoided one meeting. This would be true, except for two main points: the low frequency with which this happens; and that we had no guarantee that that specific person would have the same idea synchronously within the meeting without the time he/she had to think about it.

We have here the great intelligence of this model, because it profits from the meetings for what they should be profited from, that is, to refine ideas and possibilities, triggering the results for the company as a whole that can work asynchronously in the points and suggest improvements and evolution of these results, effectively creating a learning organization. Collaborators do not need to be under the control of facilitators and timeboxes to decide, learn and evolve. This is one of the reasons that makes SAFe an unnecessary burden.

This model is based on Don Reinertsen’s idea of ​​decentralization, in the book, Flow:

In contrast, many companies compartmentalize information, insisting that important information is closely held. This approach is dangerous because it undermines the ability of decentralized actors to support the overall mission. If the locus of control is decentralized, then decision-making information must be available at the decision-making point.

Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development (pp. 260–261). Celeritas Publishing. Kindle Edition.

The book has a whole chapter on the economic benefits of decentralization and we strongly suggest you to read it.

We will now look at a list of some meetings that we find inefficient and how to optimize costs and results:

• Release planning

In the view of this model, this meeting should be conducted by the business analyst, the flow manager, clients (if possible) and one or two team representatives. At Taller, we replaced this ceremony with the “product roadmap review”. The results of this kind of meeting are distributed along the review of the operation.

We strongly suggest the participation of clients here, but we know that in many contexts this is not possible, unfortunately. However, the absence of clients is not a reason why this review should not happen because it is important to clients and to whom the governance is working.

• Sprint planning and backlog grooming

At Taller, we believe in just in time and the demands are refined and planned throughout a well-defined upstream process. Here again, the problem is the lot. It involves people with demands they do not know if these demands will be solved at that moment. It involves developers in demands that will not be carried out by the very same developers.

Involving the whole team in these ceremonies and refinement is a crime.

Defenders of this crime argue that without the involvement of the team in these ceremonies we run the risk of losing sight of the whole. Bullshit! Again, the problem here is related to trust, because they simply do not believe that the team is able to achieve the vision of the whole without a facilitating messiah.

Here we believe that the team is aligned with their ideas and they talk to themselves, whether during the day, during the daily, during the coffee break, or on the board. In the operations review, in a presentation format, we discuss the vision of the whole when it is necessary.

With this model, we refine the demand as we walk in the cone of uncertainty to the point where it is prepared for the point of commitment. We encourage our developers to improve the ability for business analysis, for problem analysis, and solution design. They are often encouraged to participate in the upstream, but they realize that the main difference lies in not being in a mandatory all-time meeting/ceremony for the entire team at a time and location set for that. This is simply flow, and flow facilitates understanding and collaboration.

Thus, in pulling up the story, the developer of the team makes a micro-planning on top of that demand where he will start his work, looking at the acceptance criteria and the definition. He gets any questions that might come up from there. Note that the certainty that this demand will be executed at this specific time is as high as possible. It is not simply high, but the highest possible because the developer is pulling the demand to carry it out.

With these small changes aimed at decentralization, we save thousands of dollars a month, avoiding throwing precious labor force time in the trash.

• Planning e grooming for deadline estimation

If the previous point is considered a crime, this next one is then punishable with death penalty.

Besides all the aforementioned problems, we still have the aggravation of stopping the whole team, often for several days, to refine and estimate (by development effort) an entire backlog to cope with a date for the director or for clients.

People get together for days, they break into tasks (in the illusion of increased certainty), they estimate development effort. Finally, they check on their speed and come out with a magic date. They refine and estimate demands with a high degree of business and technical uncertainty.

The first mistake here is to estimate the development phase (it’s even worse when it comes to breaking in tasks) and to use this estimate to design the behavior of a flow. Note that an estimate of a flow phase is used as the project estimate itself. Queues are ignored, feedbacks are ignored.

The second mistake is in once again stopping your productive force to do something useless that the flow math can provide you with much less effort and greater accuracy. In a few minutes, it considers the entire work system and not just a small portion of it.

One of the good reasons for using flow math for projections and monitoring is the use of a scientific (repeatable) method that can have its variance monitored weekly. Options of action can be immediately tested on a model because we only need one person leading a simulation in a few minutes.

By designing and evaluating the outcome of the options, we will be more assertive in the decisions we make.

A downside is the lack of data at the beginning of the project, the product or even the company. Yet we advise you to use data from the past, from other projects, from other similar products, from similar technologies that will still be far more accurate than a guess of development effort.

If you have none of these, try the guesses of developers, but keep in mind that the behavior of queuing is difficult to estimate. Then, you will be at the worst level of the uncertainty cone, that is, the maximum uncertainty.

The ideas of this model have already been applied, separately or jointly, in helping the restructuring of governance of small, medium and large companies, the private sector or government. Its principles do not depend on context.

We are preparing a book that will detail this governance model in order to maximize results and minimize costs. Stay connected to our networks and subscribe to our newsletter!

Originally posted in pt-BR at https://blog.taller.net.br/a-prisao-do-timebox-por-que-um-processo-de-decisao-centralizado-e-nocivo/