July 14, 2017 at 09:55Why management does not accept agile and what you can do about it
This material is a translation of an article by Matthew Heusser, Managing Consultant, in Excelon Developmen. Editing - Irina Makhmutova.
The first transition to agile in my practice had the full support of the top management of the company. Top management provided funding for all necessary trainings, tools and consulting.
The leaders held meetings with all employees of the company, at which they explained a new approach to work and how the documentation, development and team structure will change. The truth was one strange thing: project plans, portfolio management and budgeting should remain the same, not to mention HR and finance. Since then I have heard this story many times, the difference was only in the details - what exactly should have remained unchanged. In this case, all (with the exception of maybe a pair of executives)) according to a nod.
Our tops often spend a lot of time and money on agile, but at the same time discredit the initiatives that promote. This is not just a common problem; this is an almost universal problem, and universal problems tend to have systemic causes.
I will give you the five most common reasons why tops don't get agile - and what to do about it.
Enterprise Agile: Hurry Up To Accelerate Faster
Consider the situation: The usual agile "transformation" begins with the organization of personnel in the Scrum team. This reduces the time of transferring requirements to development, code from development to testing, but does not solve the issues of the team's external dependencies on IT, operation or HR.
As Mike Cottmeyer pointed out at the Agile & Beyond conference recently, external dependencies destroy stable team performance (velocity).
And when the team's performance is unstable, it is impossible to say when the project will be completed.
Cottmeyer noted that it was at that moment that agile coaches started having problems trying to persuade leaders to "start trusting teams." Confidence in teams is great, but management has questions that have no answers. For example: “When can we open a new project? What to direct the marketing budget to and when? How much is budgeted to do the next thing? ”
Cottmeyer says team dependency is a key hurdle. He recommends companies that are on the path to adapting or “implementing Agile” to remove dependencies, look for workarounds, and review any service level agreements (SLAs) to make functional teams more predictable. Scrum and XP are not designed to solve the problems of team interdependence, but I see these problems in any organization with three or more teams.
Almost always, a real narrow throat is the interdependence of teams. And it is with him that agile command-level techniques will not help, and managers will find themselves without the desired results and continue to ask uncomfortable questions.
Recently, my colleagues conducted a two-day training for senior management of a very profitable company. The training was called "Agile for Executives", but it turned out that this was more of a Scrum training - it was about sprints, stories and self-organized teams. After the training, the management had a lot of ideas about how “those guys” should “make” the program, but it did not receive any real tools for managing dependencies or understanding what to do with the portfolio and budgets.
Most of the management is too busy to go on a two-day training. Training Scrum is useless anyway. As a matter of fact, not all books on software development that teams usually read will also help a lot. Sites about how management needs to change are full of meaningful tips such as “research and adapt” or “learn fast,” but these tips do not tell management how they really manage projects in large organizations.
Eric Willeke, Corporate Flexibility Advisor at CA Technologies, argues that most agile-coach-level teams and programs have never made decisions at a level that is everyday for management. And the fact that they do not have this absolutely necessary experience means that they are not ready to provide the training that management requires.
When the waterfall was a common practice, organizations tried to conduct two dozen initiatives, once less, once more. About the first eight were high priority, the next eight were medium priority and the remaining eight were low priority. Dates in the plan appeared based on past experience and commitments made, and the PMO created virtual teams to make the promise.
The good thing about this approach is that if something drags on, the team can easily switch and focus on something that is marked as high priority. This avoids the sad consequences of the Brooks law (adding people in the last stages of the project lengthens it), because it simply increases the working time or the percentage of participation of already involved project participants - yes, you do not add “more” people.
As a result, some companies using the waterfall managed to avoid some of the problems from delayed projects.
Of course, what was marked as low priority is done extremely long, if at all, but we know that they were low priority. The organization gets that. what was declared as necessary, at about the scheduled time. And of course, all the known types of hidden waterfall inefficiency are present here: everything takes a long time, and is full of rash decisions, interdependencies and alterations. But for management this is not so important, because projects are being completed.
The completed project is a pretty decent pressure relief valve that the organization loses when it goes into agile development and limits the number of tasks in the job. Why? Because when the teams are allocated to one project, there is not that percentage of the time that can be squeezed out of them, there is no way to play a shaman to compensate for the losses. Thus, the management becomes one less lever for taxiing towards the deadline.
Of course, it is always difficult to stay on course, but some organizations have learned to hide it with the help of a waterfall. Managers who need this will find that the tool available in the waterfall disappears in agile engineering. If an organization is blocked by multiple team interdependencies and team performance is unstable, the result will still be late.
For management in such companies, everything looks as if everything only got worse when they switched to agile.
DevOps is incredibly attractive and popular for many reasons. Top management really wants DevOps, but some believe DevOps can be bought and “installed."
If you have acquired a modern version control tool and added a little continuous integration, automated testing and one-click calculation, you have magically reduced the path from request to implementation from months to minutes.
All this may be true, there are really powerful tools, but the organization gets much more, cultivating efficiency in itself, and not acquiring tools. When ScotiaBank conducted an agile experiment, they discovered seven levels of alignment to make a difference in the production environment. The consulting company that launched the process simply hired more people who worked on approvals in parallel with the development. This bore fruit, and also replenished the accounts of a consulting company. Dave Dame and Aaron Sampson, who worked on this project, followed a different tactic: to change the process so that the control corresponded to the risks (now reduced).
At the same time, you will not be able to reduce risks if the only thing that interests the management is the status of the launch of continuous delivery, and the only obstacle they see is the "Dokerization of the server farm."
A complete agile transformation will include changes in the organizational structure, processes of development and building of technical competencies, culture, product management, procurement, contracted practices and, yes, even HR. Focusing on one of these areas or even several of them can lead to the creation of something like a pipeline with a bunch of blockages, knees and a bunch of other problems.
The Agile approach is not applied for its own sake, but to obtain the desired result. CA Technologies' Willeke hastens to note that "flexibility without a goal is meaningless." The implementation of agile, in his opinion, should be inextricably linked with the business result - reduced time to market, lower costs, better customer service, better product compliance with customer needs and higher quality. But if the goals or “why” are not clear enough, then the “what” and “how” will be mixed up. This very “what” may ultimately turn out to be completely different from what the management thought it would take for itself.
It can be extremely difficult to single out the only goal for movement in agile and, in fact, it is not necessary: in the end, the management was promised all the above advantages (see point 1). But anything can be.
If something is broken, it may not be too late to fix it. Remember only that it is much more difficult to fix the broken than to prevent breakage. In large organizations, all discussions will come down to the errors described above. And if you find these root causes (unstable performance, lack of time for training for leadership, statements like “there wasn’t such a thing before”, excessive attention to only one aspect of agile development, etc.) is a clear indicator that at the leadership level, there is a clear misunderstanding of what agile is and how to get there.
And you can’t fix it by chatting with the cooler about how the management “doesn’t buy”. And face it: just correcting people in meetings is a great way to nowhere.
On the contrary, find the most unpleasant root problem and deal with it. If these are trainings, make them informative. If the problem is equalizing understanding, ask clarifying questions in order to identify contradictions. If an in-place waterfall hides problems and raises questions for agile, pick up historical data and solve the problem of predictability.
Think of leadership issues without perceiving “they don't buy” as a limitation. Do not try to argue with them. Find ways to expand your own capabilities.
Why management does not accept agile and what you can do about it
The first transition to agile in my practice had the full support of the top management of the company. Top management provided funding for all necessary trainings, tools and consulting.
The leaders held meetings with all employees of the company, at which they explained a new approach to work and how the documentation, development and team structure will change. The truth was one strange thing: project plans, portfolio management and budgeting should remain the same, not to mention HR and finance. Since then I have heard this story many times, the difference was only in the details - what exactly should have remained unchanged. In this case, all (with the exception of maybe a pair of executives)) according to a nod.
Our tops often spend a lot of time and money on agile, but at the same time discredit the initiatives that promote. This is not just a common problem; this is an almost universal problem, and universal problems tend to have systemic causes.
I will give you the five most common reasons why tops don't get agile - and what to do about it.
Enterprise Agile: Hurry Up To Accelerate Faster
1. Management sees agile as exclusively team-level activities
Consider the situation: The usual agile "transformation" begins with the organization of personnel in the Scrum team. This reduces the time of transferring requirements to development, code from development to testing, but does not solve the issues of the team's external dependencies on IT, operation or HR.
As Mike Cottmeyer pointed out at the Agile & Beyond conference recently, external dependencies destroy stable team performance (velocity).
And when the team's performance is unstable, it is impossible to say when the project will be completed.
Cottmeyer noted that it was at that moment that agile coaches started having problems trying to persuade leaders to "start trusting teams." Confidence in teams is great, but management has questions that have no answers. For example: “When can we open a new project? What to direct the marketing budget to and when? How much is budgeted to do the next thing? ”
Cottmeyer says team dependency is a key hurdle. He recommends companies that are on the path to adapting or “implementing Agile” to remove dependencies, look for workarounds, and review any service level agreements (SLAs) to make functional teams more predictable. Scrum and XP are not designed to solve the problems of team interdependence, but I see these problems in any organization with three or more teams.
Almost always, a real narrow throat is the interdependence of teams. And it is with him that agile command-level techniques will not help, and managers will find themselves without the desired results and continue to ask uncomfortable questions.
2. Management does not receive training at the required level
Recently, my colleagues conducted a two-day training for senior management of a very profitable company. The training was called "Agile for Executives", but it turned out that this was more of a Scrum training - it was about sprints, stories and self-organized teams. After the training, the management had a lot of ideas about how “those guys” should “make” the program, but it did not receive any real tools for managing dependencies or understanding what to do with the portfolio and budgets.
Most of the management is too busy to go on a two-day training. Training Scrum is useless anyway. As a matter of fact, not all books on software development that teams usually read will also help a lot. Sites about how management needs to change are full of meaningful tips such as “research and adapt” or “learn fast,” but these tips do not tell management how they really manage projects in large organizations.
Eric Willeke, Corporate Flexibility Advisor at CA Technologies, argues that most agile-coach-level teams and programs have never made decisions at a level that is everyday for management. And the fact that they do not have this absolutely necessary experience means that they are not ready to provide the training that management requires.
3. The waterfall model hides inefficiency from management
When the waterfall was a common practice, organizations tried to conduct two dozen initiatives, once less, once more. About the first eight were high priority, the next eight were medium priority and the remaining eight were low priority. Dates in the plan appeared based on past experience and commitments made, and the PMO created virtual teams to make the promise.
The good thing about this approach is that if something drags on, the team can easily switch and focus on something that is marked as high priority. This avoids the sad consequences of the Brooks law (adding people in the last stages of the project lengthens it), because it simply increases the working time or the percentage of participation of already involved project participants - yes, you do not add “more” people.
As a result, some companies using the waterfall managed to avoid some of the problems from delayed projects.
Of course, what was marked as low priority is done extremely long, if at all, but we know that they were low priority. The organization gets that. what was declared as necessary, at about the scheduled time. And of course, all the known types of hidden waterfall inefficiency are present here: everything takes a long time, and is full of rash decisions, interdependencies and alterations. But for management this is not so important, because projects are being completed.
The completed project is a pretty decent pressure relief valve that the organization loses when it goes into agile development and limits the number of tasks in the job. Why? Because when the teams are allocated to one project, there is not that percentage of the time that can be squeezed out of them, there is no way to play a shaman to compensate for the losses. Thus, the management becomes one less lever for taxiing towards the deadline.
Of course, it is always difficult to stay on course, but some organizations have learned to hide it with the help of a waterfall. Managers who need this will find that the tool available in the waterfall disappears in agile engineering. If an organization is blocked by multiple team interdependencies and team performance is unstable, the result will still be late.
For management in such companies, everything looks as if everything only got worse when they switched to agile.
4. Lead leaders are too focused on one aspect.
DevOps is incredibly attractive and popular for many reasons. Top management really wants DevOps, but some believe DevOps can be bought and “installed."
If you have acquired a modern version control tool and added a little continuous integration, automated testing and one-click calculation, you have magically reduced the path from request to implementation from months to minutes.
All this may be true, there are really powerful tools, but the organization gets much more, cultivating efficiency in itself, and not acquiring tools. When ScotiaBank conducted an agile experiment, they discovered seven levels of alignment to make a difference in the production environment. The consulting company that launched the process simply hired more people who worked on approvals in parallel with the development. This bore fruit, and also replenished the accounts of a consulting company. Dave Dame and Aaron Sampson, who worked on this project, followed a different tactic: to change the process so that the control corresponded to the risks (now reduced).
At the same time, you will not be able to reduce risks if the only thing that interests the management is the status of the launch of continuous delivery, and the only obstacle they see is the "Dokerization of the server farm."
A complete agile transformation will include changes in the organizational structure, processes of development and building of technical competencies, culture, product management, procurement, contracted practices and, yes, even HR. Focusing on one of these areas or even several of them can lead to the creation of something like a pipeline with a bunch of blockages, knees and a bunch of other problems.
5. Many conflicting goals at the leadership level
The Agile approach is not applied for its own sake, but to obtain the desired result. CA Technologies' Willeke hastens to note that "flexibility without a goal is meaningless." The implementation of agile, in his opinion, should be inextricably linked with the business result - reduced time to market, lower costs, better customer service, better product compliance with customer needs and higher quality. But if the goals or “why” are not clear enough, then the “what” and “how” will be mixed up. This very “what” may ultimately turn out to be completely different from what the management thought it would take for itself.
It can be extremely difficult to single out the only goal for movement in agile and, in fact, it is not necessary: in the end, the management was promised all the above advantages (see point 1). But anything can be.
How to fix it
If something is broken, it may not be too late to fix it. Remember only that it is much more difficult to fix the broken than to prevent breakage. In large organizations, all discussions will come down to the errors described above. And if you find these root causes (unstable performance, lack of time for training for leadership, statements like “there wasn’t such a thing before”, excessive attention to only one aspect of agile development, etc.) is a clear indicator that at the leadership level, there is a clear misunderstanding of what agile is and how to get there.
And you can’t fix it by chatting with the cooler about how the management “doesn’t buy”. And face it: just correcting people in meetings is a great way to nowhere.
On the contrary, find the most unpleasant root problem and deal with it. If these are trainings, make them informative. If the problem is equalizing understanding, ask clarifying questions in order to identify contradictions. If an in-place waterfall hides problems and raises questions for agile, pick up historical data and solve the problem of predictability.
Think of leadership issues without perceiving “they don't buy” as a limitation. Do not try to argue with them. Find ways to expand your own capabilities.