Why the guide does not accept agile and what can you do about it
This material is a translation of the article by Matthew Heusser, Managing Consultant in Excelon Developmen. Editing - Irina Makhmutova.
The first transition in my practice to agile had the full support of the company's top management. Top management provided funding for all necessary training, tools and consulting.
')
The leaders held meetings with all employees of the company, at which they explained the new approach to work and how the documentation, development and structure of the teams would change. The truth was one strange thing: project plans, portfolio management and budgeting should have remained 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. At the same time, all (except for the couple may be executives)) nodded in agreement.
Our tops often spend a lot of time and money on agile, but at the same time discredit initiatives that promote. This is not just a common problem; this is almost a universal problem, and universal problems tend to have systemic causes.
I’ll give you the five most common reasons why tops don't get agile - and what to do about it.
Enterprise Agile: Hurry up faster
Consider the situation: The usual agile "transformation" begins with the organization of personnel in the Scrum team. This reduces the time to transfer requirements to development, code from development to testing, but does not solve the issues of external dependencies of the team from IT, operation or HR.
As Mike Cottmeyer pointed out recently at Agile & Beyond, external dependencies destroy the command’s steady performance (velocity).
And when the performance of the team is unstable, it is impossible to say when the project will be completed.
Cottmeyer noted that it was at this moment that agile-coaches started having problems trying to persuade managers to “begin to trust teams.” Trust in teams is fine, but management has questions that are not answered. For example: “When can we open a new project? What should the marketing budget be spent on and when? How much to put in the budget to do the next thing? "
Cottmeyer says that external team dependencies are a key obstacle. He recommends that companies that stand in the way of adapting or “implementing Agile” remove dependencies, look for workarounds, revise any service level agreements (SLAs) to make functional teams more predictable. Scrum and XP are not designed to solve team interdependence problems, and I see these problems in any organization with three or more teams.
Almost always the real bottleneck is the interdependence of commands. And it is with him that the agile command-level techniques will not help, and the leaders will be without the desired results and will 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, management had a lot of ideas about how “those guys” should “do” the program, but it did not get 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 for a two-day training. Learning Scrum is useless to them anyway. As well, not all the software development books that teams usually read do not help much. Sites on how leadership is required to change are full of meaningful tips like “explore and adapt” or “learn quickly”, but these tips don't tell management how to manage projects in large organizations in reality.
Eric Willeke, CA Technologies Corporate Flexibility Advisor, claims that most agile coaches at the team level and the program 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 is required by management.
When the waterfall was a common practice, organizations tried to lead two dozen initiatives, once less, once more. Approximately the first eight were high priority, the next eight were high priority and the remaining eight were low priority. The dates in the plan appeared based on past experience and commitments, and the PMO created virtual teams to make the promise.
The good thing about this approach is that if something is delayed, the team can easily switch and focus on something that is marked as high priority. This avoids the unfortunate consequences of the Brooks Act (adding people in the final stages of the project lengthens it), because it simply increases the work 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 has been marked as low priority is done extremely long, if at all, but we know that they were low priority. The organization gets it. what was stated as necessary, approximately at the scheduled time. And of course, all known types of hidden waterfall inefficiency are present here: everything happens for a long time, and is full of hasty decisions, interdependencies and rework. But for management this is not so significant, because the projects are being completed.
The completed project is a fairly decent pressure relief valve, which the organization loses when it goes into agile development and limits the number of tasks in the work. Why? Because when teams are allocated to one project, there is no percentage of the time they can wring out from them, there is no way to shuffle to compensate for losses. Thus, the management gets one lever less for taxiing in the direction of 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 it will find that the tool available at the waterfall disappears in agile engineering. If the organization is blocked by multiple command interdependencies and the performance of the teams is unstable, the result will still be delayed.
To 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 that you can buy and install DevOps.
If you got a modern version control tool and added a bit of continuous integration, automated testing and one-button display, you magically shortened 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, bringing up efficiency in itself, rather than acquiring tools. When ScotiaBank conducted an agile experiment, they found seven levels of agreement to make changes to the production environment. The consulting company that started the process simply hired more people who were involved in the coordination in parallel with the development. This gave its results, and also replenished the accounts of the consulting company. Dave Dame and Aaron Sampson, who worked on this project, adhered to another 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 launch status of a continuous delivery, and the only obstacle that they see is “Doker-isation of the server farm”.
A complete agile transformation will include changes in organizational structure, development processes, and building technical competencies, culture, product management, procurement, contractual practices, and, yes, even HR. Focusing on one of these areas or even on several of them can lead to the creation of something like a pipeline with a lot of blockages, knees and a bunch of other problems.
Agile approach is not applied for its own sake, but to obtain the desired result. CA Technologies' Willeke is in a hurry to note that "flexibility without purpose is meaningless." The introduction of agile, in his opinion, should be inextricably linked with the business result - reducing time to market, reducing costs, better customer service, better product compliance with customer needs and higher quality. But if goals or “why” are not clear enough, then “what” and “how” will be confused. This very “what” may in the end turn out to be completely different from what the management thought it would get for itself.
Selecting a single goal for movement in agile can be extremely difficult and, in fact, not necessary: ​​in the end, the management was promised all of the above benefits (see point 1). But anything can happen.
If something is broken, it may not be too late to fix it. Just remember that fixing a broken is much more difficult than preventing a breakdown. In large organizations, all discussions will be limited to the errors described above. And if you have found these root causes (unstable performance, lack of time for training for management, statements like “there was no such thing before”, excessive attention to only one aspect of agile development, etc.) - this is an obvious 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 talking to the cooler about how the management "does not buy." And face it: just fixing people at 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 alignment of understanding, ask clarifying questions in order to identify inconsistencies. If the current waterfall hides problems and causes questions to agile, bring up historical data and solve the problem of predictability.
Think of management problems, not seeing “they don’t buy” as a constraint. Do not try to argue them. Find ways to expand your own capabilities.
Why the guide does not accept agile and what can you do about it
The first transition in my practice to agile had the full support of the company's top management. Top management provided funding for all necessary training, tools and consulting.
')
The leaders held meetings with all employees of the company, at which they explained the new approach to work and how the documentation, development and structure of the teams would change. The truth was one strange thing: project plans, portfolio management and budgeting should have remained 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. At the same time, all (except for the couple may be executives)) nodded in agreement.
Our tops often spend a lot of time and money on agile, but at the same time discredit initiatives that promote. This is not just a common problem; this is almost a universal problem, and universal problems tend to have systemic causes.
I’ll give you the five most common reasons why tops don't get agile - and what to do about it.
Enterprise Agile: Hurry up faster
1. Management considers agile to be 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 to transfer requirements to development, code from development to testing, but does not solve the issues of external dependencies of the team from IT, operation or HR.
As Mike Cottmeyer pointed out recently at Agile & Beyond, external dependencies destroy the command’s steady performance (velocity).
And when the performance of the team is unstable, it is impossible to say when the project will be completed.
Cottmeyer noted that it was at this moment that agile-coaches started having problems trying to persuade managers to “begin to trust teams.” Trust in teams is fine, but management has questions that are not answered. For example: “When can we open a new project? What should the marketing budget be spent on and when? How much to put in the budget to do the next thing? "
Cottmeyer says that external team dependencies are a key obstacle. He recommends that companies that stand in the way of adapting or “implementing Agile” remove dependencies, look for workarounds, revise any service level agreements (SLAs) to make functional teams more predictable. Scrum and XP are not designed to solve team interdependence problems, and I see these problems in any organization with three or more teams.
Almost always the real bottleneck is the interdependence of commands. And it is with him that the agile command-level techniques will not help, and the leaders will be without the desired results and will continue to ask uncomfortable questions.
2. Management does not receive the required level of training
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, management had a lot of ideas about how “those guys” should “do” the program, but it did not get 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 for a two-day training. Learning Scrum is useless to them anyway. As well, not all the software development books that teams usually read do not help much. Sites on how leadership is required to change are full of meaningful tips like “explore and adapt” or “learn quickly”, but these tips don't tell management how to manage projects in large organizations in reality.
Eric Willeke, CA Technologies Corporate Flexibility Advisor, claims that most agile coaches at the team level and the program 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 is required by management.
3. Waterfall model hides inefficiency from leadership
When the waterfall was a common practice, organizations tried to lead two dozen initiatives, once less, once more. Approximately the first eight were high priority, the next eight were high priority and the remaining eight were low priority. The dates in the plan appeared based on past experience and commitments, and the PMO created virtual teams to make the promise.
The good thing about this approach is that if something is delayed, the team can easily switch and focus on something that is marked as high priority. This avoids the unfortunate consequences of the Brooks Act (adding people in the final stages of the project lengthens it), because it simply increases the work 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 has been marked as low priority is done extremely long, if at all, but we know that they were low priority. The organization gets it. what was stated as necessary, approximately at the scheduled time. And of course, all known types of hidden waterfall inefficiency are present here: everything happens for a long time, and is full of hasty decisions, interdependencies and rework. But for management this is not so significant, because the projects are being completed.
The completed project is a fairly decent pressure relief valve, which the organization loses when it goes into agile development and limits the number of tasks in the work. Why? Because when teams are allocated to one project, there is no percentage of the time they can wring out from them, there is no way to shuffle to compensate for losses. Thus, the management gets one lever less for taxiing in the direction of 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 it will find that the tool available at the waterfall disappears in agile engineering. If the organization is blocked by multiple command interdependencies and the performance of the teams is unstable, the result will still be delayed.
To management in such companies, everything looks as if everything only got worse when they switched to agile.
4. Lead leaders are too focused on any one aspect.
DevOps is incredibly attractive and popular for many reasons. Top management really wants DevOps, but some believe that you can buy and install DevOps.
If you got a modern version control tool and added a bit of continuous integration, automated testing and one-button display, you magically shortened 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, bringing up efficiency in itself, rather than acquiring tools. When ScotiaBank conducted an agile experiment, they found seven levels of agreement to make changes to the production environment. The consulting company that started the process simply hired more people who were involved in the coordination in parallel with the development. This gave its results, and also replenished the accounts of the consulting company. Dave Dame and Aaron Sampson, who worked on this project, adhered to another 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 launch status of a continuous delivery, and the only obstacle that they see is “Doker-isation of the server farm”.
A complete agile transformation will include changes in organizational structure, development processes, and building technical competencies, culture, product management, procurement, contractual practices, and, yes, even HR. Focusing on one of these areas or even on several of them can lead to the creation of something like a pipeline with a lot of blockages, knees and a bunch of other problems.
5. Many conflicting goals at the executive level
Agile approach is not applied for its own sake, but to obtain the desired result. CA Technologies' Willeke is in a hurry to note that "flexibility without purpose is meaningless." The introduction of agile, in his opinion, should be inextricably linked with the business result - reducing time to market, reducing costs, better customer service, better product compliance with customer needs and higher quality. But if goals or “why” are not clear enough, then “what” and “how” will be confused. This very “what” may in the end turn out to be completely different from what the management thought it would get for itself.
Selecting a single goal for movement in agile can be extremely difficult and, in fact, not necessary: ​​in the end, the management was promised all of the above benefits (see point 1). But anything can happen.
How to fix it
If something is broken, it may not be too late to fix it. Just remember that fixing a broken is much more difficult than preventing a breakdown. In large organizations, all discussions will be limited to the errors described above. And if you have found these root causes (unstable performance, lack of time for training for management, statements like “there was no such thing before”, excessive attention to only one aspect of agile development, etc.) - this is an obvious 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 talking to the cooler about how the management "does not buy." And face it: just fixing people at 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 alignment of understanding, ask clarifying questions in order to identify inconsistencies. If the current waterfall hides problems and causes questions to agile, bring up historical data and solve the problem of predictability.
Think of management problems, not seeing “they don’t buy” as a constraint. Do not try to argue them. Find ways to expand your own capabilities.
Source: https://habr.com/ru/post/333032/
All Articles