Overcoming the Third Law of Organizational Gravity
Flexibility is one of the most obvious and understandable reasons why companies put Agile in the first place among the tasks. However, many companies still have serious difficulties with a radical change in the course of development, even though the employees of these companies, including top managers, agree with the critical role of adaptability in achieving success. Matt LeMaycalls the main reason for such problems the third law of organizational gravity: a project in motion will remain in motion while the senior manager who approved this project is responsible for it. In other words, if a specific project, initiative or product idea is signed by a senior manager, then work on the project will continue at the same pace, even if at some point it becomes obvious that it does not meet the needs of customers and the goals of the company. After all, why bring bad news to directors if responsibility for the inevitable failure of the project rests with the manager?
Let us return to the first law of organizational gravity: top managers who must intervene in the process are often as far removed as possible from direct interaction with customers. This creates a closed system in which companies are not able to adjust the development course to the new information received from customers. Reviews that hint at a change in development course are combed and disguised to the point where they sound like “Great job, boss!” And the manager receives them in this form.
Such dynamics explain why people in companies often continue to work on a project, even if they know about its doom to failure. It also explains why frankly terrible marketing campaigns and #socialmediafails predominate in the era of instant feedback. From an organizational policy point of view, public shame seems less risky than having to tell the boss that the project he signed is a bad idea.
Personal courage is one aspect that may work against the third law of organizational gravity, but this is not enough. The only way to make sure that changes happen is to make such changes part of the process. In other words, managers who sign their projects must understand that they need to leave space for change, which is an integral part of any project. In such a case, a change of course seems more a laudable example of foresight than an unfortunate failure.
Catherine Kuhn, an experienced Agile practitioner and attorney at Teradata, Oracle, and Hewlett-Packard, explained to me how large financial companies learned to plan for uncertainty by adding shorter quarter-cycle cadences to existing year-long planning cycles and integrating it into the overall company policy.
We cannot always force a company to stop creating annual planning cycles. However, we can get them to add quarterly results reports. It is extremely simple - you begin to describe the achievements for the quarter, then add additional information that others should know. Perhaps Gartner has released a new study on market changes, new regulatory requirements, new initiatives by company executives, or new information about our customers. Bring this information to the rest, describe what you have learned from the last discussion of the plans, and after that look ahead. Take a look at your projects and evaluate their readiness based on the knowledge you just gained. If you have achieved 85% of the goal in one project, can you strategically transfer all resources to another project, which is only 20% ready?As this example shows, even companies with annual planning cycles are able to find opportunities for sharing knowledge and changing course. Using a language that is understandable within a particular company can clear the way for new ideas and methods, even if they are significant changes to “business as usual”.
With this approach, we were able to accustom the entire company to the quarterly cadence of event planning. This allowed them to cover all possible aspects - for example, they began to undergo audits with thousands of corrections that would previously stall the entire work of the bank. They were able to divide the work into parts thanks to quarterly planning, to understand what they could do and what they could not, and highlight the highest priorities. We began to discuss aspects that customers liked and to develop the necessary services on their basis. They began to discuss the shortcomings of each approach, and not let the processes go by their own accord.
Another key to success was that we began to speak the company’s internal language - to use the phrases “not bad at the moment” and “enough done”. Or: "a great idea, but later." People got a vocabulary for talking about setting priorities and stopped talking too abstruse or condescendingly.
Agile paradox: use structure to achieve flexibility
Most Agile methodologies are based on the paradoxical idea that regular cadence leaves more room for flexibility. This is because a definite and final cadence, such as the Agile sprints, discussed in Chapter 3, makes reaction to changes a part of the work process, and not an obstacle to this process.
When I started learning Agile, I was worried that a more specific structure would slow down my team and make it less responsible. Obligations to perform certain tasks every two weeks turned out to be more rigid and systemic than planning rough tasks for every couple of months or, even better, “for the near future”. To my surprise and delight, a shorter cadence led the team to make a clear and interesting choice. We were able to create and test prototypes of new product lines, while realizing that we would be able to abandon these areas at any time if they prove to be useless to customers. We were also able to better plan the quarterly and annual goals of the company, because we realized that every two weeks we could adjust the course of development in case of deviation from the goals.
In fact, almost all companies operate within the framework of plans that go far beyond the two-week standard sprints, whether it is a quarterly schedule in a small technology startup or the annual budget of a large enterprise. Agile practitioners (especially those who have undergone serious ideological training at various trainings) often regard any long-term cadence as a threat to true flexibility and gradually begin to state that the principles of Agile "are completely unsuitable for large and bureaucratic organizations." Alan Bans, a consultant and former head of marketing at IBM and Salesforce.com, explained to me how the most successful Agile professionals find a middle ground between long-term planning and short-term adjustments:
All the companies I worked for, regardless of their commitment to Agile principles, started the fiscal year with budget planning. If you work in a company that is going to enter the open market, you can’t just take it and say “Hmm, well, we don’t yet know how much we will have to spend, because we adhere to the Agile principles!” Budget cycles are formed on the basis of the assumptions of the sales teams and their leaders regarding realistically achievable indicators and goals for next year. On the basis of this, a marketing budget is formed.This example, like Catherine Kuhn’s short story above, shows that year-long planning does not force us to give up flexibility. Rather, on the contrary, we need to more actively and thoughtfully form short cadences, with which we will be able to ensure that the work of the team coincides with long-term plans and make adjustments as new information is received from clients.
Agile principles often impose a feeling of “Yes, we can reorganize at any time” - no, that’s not so! You have a budget. And very quickly this budget begins to disappear. You still have a lot of room for flexible solutions, but you do not start from scratch. A balance must be struck between long-term and spontaneous.
Such a balance largely depends on how the company uses its long-term cycles. They can be carved in stone, and can have many directions of development, taking into account possible adjustments. If these long-term directions are not the ultimate truth, but rather provide guiding recommendations, then this leaves room for flexibility. But as soon as steadfastness and bureaucracy appear, “you said 10.1 million dollars, not 9.9”, then everything becomes more confused.
Here are some steps you can take to combine short-term cadences, long-term goals, and planning structures.
List the established cadences of your company and work with them, not against them
Does your company have a one-year budget planning cycle? Biennial strategic planning cycle? The quarterly goal setting process? Take a piece of paper, write out all the cycles and indicate what exactly was decided on each cycle, who made these decisions and what result they expect. Then think about how you could build short cadences around these cycles to provide flexibility and adhere to company planning cycles that are not subject to change.
Celebrate change
If we plan only long-term cycles, any changes may seem like another tedious work on mistakes. Short-term cycles give us more time to adapt to changes in the initial plan and align new information with long-term goals. We can draw attention to newfound flexibility by noting changes, rather than mourning them. In other words, if after two short cycles within one long cycle we understand that we are going the wrong way, instead of the words “Damn, four weeks of working up the drain” we can say: “We are very lucky that we noticed an error at this stage “Now we can change the course of development and meet the quarterly indicators with the same success.”
Focus on the possible
The tension between short-term flexibility and long-term planning will never completely disappear, so from time to time you will find yourself in situations where your team is not able to complete the desired task on time. However, you should not blame the entire company for “non-compliance” with the Agile principles, as this will negatively affect the motivation and mood of the team. Instead, focus on what you can do, given the real limitations of the company.
In many cases, the “do what you can do” approach can add value to long-term planning cycles by clarifying their goals and expectations. While teams and companies are working to find the right balance between short-term and long-term planning, they better understand and feel the values that they themselves can offer.
Experimental work - double-edged sword
Planning for uncertainty certainly means that we make the best assumptions and move forward before we know that our actions will succeed. In many Agile approaches and methods close to Agile, especially in the lean startup world, “experimental work” is often referred to as the best way to endorse new ideas and directions for teams and organizations in a rapidly changing world.
Unfortunately, existing companies are not able to ensure the sterility of a well-equipped laboratory. The idea of conducting experimental work is of great importance to the company, but it can be fraught with danger if it contains a sense of scientific confidence that completely contradicts the restless and changeable nature of the real world. At best, experimental work will help to understand the whole uncertainty of the world, but it will never save us from this uncertainty.
This can be a bitter lesson for teams and professionals who are striving for making the right decisions. Without a doubt, there are certain types of solutions that are easier to prove by experiment. For example, if you need to decide whether the Home button on a website page is round or square, then A / B testing will be the most effective solution. Now suppose that you need to decide whether to develop a new line of business, or what awaits an existing product in a new market. Of course, you can conduct an experiment that will help find answers to these questions and will cost all the costs, but no such experiment will provide you with the same irrefutable scientific certainty as a simple A / B testing.
Theoretically, this means that teams should stop wasting time on complicated and complicated experiments that confirm complex market-oriented solutions. However, in practice this often means completely different: teams and organizations spend a disproportionate amount of time on experiments that provide evidence in absolute quantitative form, even if these experiments do not have a particular impact on the business.
When we worked with companies with my business partners, we often asked them to display the ongoing experiments on a graph called Integrated Data Analysis. Similar graphs with four quadrants represent initiatives related to data along the axes “discovery - optimization” and “qualitative - quantitative”. Sudden Compass partner Tricia Vaughn developed this framework after she had to deal with many companies that relied too much on quantitative optimization work, such as A / B testing, and neglected the more complex and work of approving decisions at the opening level and conducting experiments that by their nature provide quality data.Almost every company with which we performed this exercise filled a graph with a pronounced bias towards quantitative optimization in the lower right quadrant. However, when we asked the same organizations to display the questions that concern them greatly, along the x axis from “opening” to “optimization”, the bias went to “opening”. Companies are often asked general questions that relate to discoveries: “How can we introduce our business to new markets?”, While continuing to carry out most of the experiments with regard to additional optimization of existing products, markets or promises. Simply recognizing this fact is often not enough for companies to pay attention to this problem and begin to study new ways of conducting high-quality experiments at the level of discoveries in the upper left quadrant.
One of the most striking examples of such an experiment is taken from the book "Lean startup" . Former president and co-founder of Lean Startup Productions, Sarah Milstein explained to me how she was able to conduct simple, low-cost experiments to evaluate new product ideas and why quality data played an important role in these experiments:
When we launched the new conference as part of Lean Startup Productions, we thought about selling online tickets. We did not think that it would turn out to be so popular, so we expected to sell about ten tickets. On the day of sales, we sold one hundred tickets. This was a serious signal, because we could not analyze the behavior of our customers. If we had not considered this idea, we would not have seen the difference between ten and one hundred tickets. A similar experiment, based on a hypothesis, is no less useful if you make a mistake; in addition, you do not have to strive for correctness, you need to strive to evaluate your own judgments about the client you serve.As this story shows, the simplest things to measure are not always the most important and relevant. When we start with the most important questions related to business and customers, and not with the questions that are most easily answered using a quantitative experiment, we recognize the complexity and uncertainty of the world around us.
It is also worth noting that people are often very keen on experiments, because of which their meaning begins to be lost. Sometimes an experiment gives exceptionally high-quality signals: for example, when people start using a phrase from your marketing materials. This approach is officially called "artifact analysis." For example, if we call the feedback on our site “questions”, will the content of the inbox change? We do not always have numbers, but we know what and where to look.
Excerpt from Agile for All
