7 Barriers to Implementing Flexible Methodologies in Large Organizations
I work with large companies that are trying to apply Agile, starting with Scrum. Although each organization is in its sector, it uses different technologies and has its own management culture, everyone had one common disease - a kind of “gigantism”. This article contains a list of common flexibility issues in large organizations and explores how to avoid the “gigantism” symptom.
At first glance, the problems of the organization will look like “too many tasks” or “not enough resources” or “unstable situation in the market”. On closer examination, the key reasons will turn out to be bad habits, formed by “reflexes” and delusions.
One of the very well-known companies, which was an example of the successful use of Scrum in 1997, turned to Danube Technologies, Inc. for help. in 2009, because the “market” showed that they were less flexible than the competitors. The beginnings of the introduction of Scrum, which began in 1997, apparently could not withstand a decade of coexistence with the problems inherent in large enterprises. Unfortunately, most attempts to implement Scrum in large organizations do not lead to long-term transformations. Obstacles to the introduction of Scrum usually also hinder the achievement of business success in general, and established organizations are usually reluctant to get rid of them.
')
The PMBOK Guide says:
To resolve this paradox, let's consider the definition of "resource".
When a job is a new product development, the relevant resources are intangible: understanding the task, learning, interpersonal communication and innovation. Scrum teams try to maximize them by creating states of individual and group “flow”. According to psychologist Mihaly Csikszentmihalyi : “[in the stream] you are completely immersed in the task, and you use all your skills at the ultimate level” .
The Development Team members of the Scrum intensively interact with each other to create products in accordance with the objectives that they constantly discuss with the Product Owner. The Product Owner is responsible for making business decisions in a team. The results of the work are shown at the end of each Sprint (Sprint) of a fixed duration (for example, every two weeks). During the Sprint, team members develop an interest in common goals and learn to manage each other to achieve them. Even under ideal conditions (including talking about the room where the team works), the team needs to take part in several sprints to achieve success, and about a year to realize its full potential. The description of this organic process is widely known - “formation, assault, rationing, execution” of the model of Bruce Tuckman. ( Bruce Tuckman, “forming, storming, norming, performing” ).
It is naive to talk about people as resources. New members in a team will not guarantee an increase in the notion of a “team resource”, and may even reduce it. After a year of working on Scrum, one of my clients told me: “After a team is formed, it’s better to lose one team member than to add a new one.” Quite another, if the Scrum team came to the decision to hire a new employee, then adding a new team member would be a good decision. But, even if the team is able to independently hire employees, it is inappropriate to increase the size of a team of more than seven people.
In some cases, an increase in commands can lead to an acceleration of work, if this occurs taking into account the fact that these are intangible, uncountable resources.
Scrum teams are cross-functional teams that try to create a thoroughly tested product increment each sprint, gradually increasing functionality. The most popular book on Scrum uses the phrase “potentially“ Ready to release Product Increment ”(“ potentially shippable product increment ”) 18 times. Despite this, I meet people who claim to "practice Scrum", using "analytical sprints" or "design sprints" at the beginning of the project, postponing integration and testing for later, and engaging different teams to perform each part of the work. Habits acquired from the Waterfall Model of Project Management hide risks until it is too late to do something.
In Scrum, during each Sprint, a combination of various developmental activities is required. We gain flexibility through continuous requirements analysis, continuous design, continuous integration and continuous testing, all team members together.
Teams created to work on one component reduce business opportunities to reorient product capabilities, increase the number of bottlenecks in communication with managers and product owners and introduce additional integration risks.
Such teams would be effective if new product development was as predictable as production. In practice, priorities change, and estimates turn out to be incorrect. Therefore, it is difficult to attract the right people at the right time to lead a development that can affect several components.
The opposite of the Component Team is the Functional Team, focused on the development of new product features ( feature team ). A functional team encompasses both components and disciplines, and is thus capable of implementing functional tasks for a business in thin, fully tested “vertical sections” of the product. This approach is intended to replace the concepts of the past century, based on the concepts of team autonomy, self-organization and responsibility. The product backlog of Functional Commands is based on the needs of the business, not on technology dependencies. If you are still using Gantt Charts, most likely you have not yet organized Function Commands.
Creating Functional Teams is costly: developers will need to learn new skills, which will slow them down at the start. Fortunately, most developers love to learn new skills. Methods such as assigning a technical “component component guardian ” to each area can help protect architectural integrity as teams learn. As with any large-scale development, continuous integration (automated tests performed much more often than once a day) is crucial to prevent undetected defects in the overall health of the product.
After the organization learns to manage the Functional Teams, the next step may be the creation of General purpose Function teams with minimal dependencies on the functional areas. This process may require years of continuous learning within the organization.
Millions of dollars are spent in typical large organizations because of the unnecessary switching between tasks. Teams lack focus and months of stability with respect to the composition of the team in order to achieve the state of self-organization required for high performance and quality. Some people are constantly on several "critical paths" at the same time, which seriously limits the overall performance. To scale effectively, these people must become mentors, not task performers. To increase their influence, they must relinquish some control.
Traditional management techniques that enhance specialization will only exacerbate the problem. Work should be given to the Scrum team during a Sprint Planning Meeting. When the manager does not take this into account, assigning tasks to specific performers, specialists do not have the opportunity to instruct and train others in important skills. At one of the meetings for Planning Sprint, I was faced with the fact that the first question that was asked was: “Who will work with us on this Sprint?”. Persons who are constantly being pulled will not train others, although this is expected from Scrum teams. And organizations are digging into these problems every day more and more.
In higher positions, there are even more problems associated with multitasking, distraction, anxiety and the inability to gain control over what is happening. The Product Owner, at the same meeting, came annoyed, an hour late, and ran away again after 10 minutes. And they told me that it happens all the time.
And after lunch, the manager was unable to dedicate himself to meeting with 60 of his employees because he was simultaneously trying to solve another problem through services on his phone. The casual observer of these scenes could not have imagined that these rabid, event-driven slaves were responsible for the strategy for further development.
Effective horizontal communication between Scrum teams helps Product Owners to calmly focus on such duties as setting work priorities and determining final requirements.
When developing a product, the rate of detection of new tasks that need to be done is usually ahead of the speed of development itself. To cope with this, the Product Owner must conduct Refinement Meetings to review, prioritize and clarify the tasks in the Backlog of Products each Sprint. When too large tasks (“epics”) appear in Baclog, it is necessary to find their key aspects and divide them into small subtasks (usually called “User Stories”). The Product Owner controls the scope of work, deciding which tasks will be included in the Release, taking into account data on development speed and scope of work performed during the Sprint.
The problems of managing an organization are ultimately visible in the source code. And “technical debt” causes problems in the product and the high cost of change. Ideally, regression tests can be automated using the same programming language used in product development, without using proprietary tools that only increase dependence on specific knowledge. Skills such as Test Driven Development (TDD) proved their worth in the 20th century. In the 21st century, any developer is expected to have skills in flexible methodologies. And teams that do not yet possess these skills should try to work with “vertical task cuts” until they learn .
Scrum assigns one person per team (ScrumMaster) to focus on identifying and overcoming such obstacles . This requires courage, imagination and support from management. Too few Scrum Masters pay due attention to such problems, and management often does not support those who do it.
“Too many tasks” or “not enough resources” or “unstable market situation” is not a good excuse for not introducing Flexible methodologies specifically designed to solve these problems. And the people responsible for the changes should be better prepared to overcome the Obstacles to the implementation of Flexible Methodologies, recognizing that the key causes of problems in maintaining bad habits, formed “reflexes” and delusions.
Text of the original article: 7 Obstacles to Enterprise Agility
Posted by: Michael James
Translation: Daniel Chernyshev
Translated with the consent of the author.
At first glance, the problems of the organization will look like “too many tasks” or “not enough resources” or “unstable situation in the market”. On closer examination, the key reasons will turn out to be bad habits, formed by “reflexes” and delusions.
One of the very well-known companies, which was an example of the successful use of Scrum in 1997, turned to Danube Technologies, Inc. for help. in 2009, because the “market” showed that they were less flexible than the competitors. The beginnings of the introduction of Scrum, which began in 1997, apparently could not withstand a decade of coexistence with the problems inherent in large enterprises. Unfortunately, most attempts to implement Scrum in large organizations do not lead to long-term transformations. Obstacles to the introduction of Scrum usually also hinder the achievement of business success in general, and established organizations are usually reluctant to get rid of them.
')
Obstacle # 1: Naive Resource Management
The PMBOK Guide says:
“It is often necessary to increase the budget in order to add additional resources to perform the same amount of work in a shorter time”In terms of software, Fred Brooks (in the book Mythical Man-Month) gives a statement that contradicts the previous:
“If the project does not fit the deadlines, then adding labor will delay it even more”
To resolve this paradox, let's consider the definition of "resource".
When a job is a new product development, the relevant resources are intangible: understanding the task, learning, interpersonal communication and innovation. Scrum teams try to maximize them by creating states of individual and group “flow”. According to psychologist Mihaly Csikszentmihalyi : “[in the stream] you are completely immersed in the task, and you use all your skills at the ultimate level” .
The Development Team members of the Scrum intensively interact with each other to create products in accordance with the objectives that they constantly discuss with the Product Owner. The Product Owner is responsible for making business decisions in a team. The results of the work are shown at the end of each Sprint (Sprint) of a fixed duration (for example, every two weeks). During the Sprint, team members develop an interest in common goals and learn to manage each other to achieve them. Even under ideal conditions (including talking about the room where the team works), the team needs to take part in several sprints to achieve success, and about a year to realize its full potential. The description of this organic process is widely known - “formation, assault, rationing, execution” of the model of Bruce Tuckman. ( Bruce Tuckman, “forming, storming, norming, performing” ).
It is naive to talk about people as resources. New members in a team will not guarantee an increase in the notion of a “team resource”, and may even reduce it. After a year of working on Scrum, one of my clients told me: “After a team is formed, it’s better to lose one team member than to add a new one.” Quite another, if the Scrum team came to the decision to hire a new employee, then adding a new team member would be a good decision. But, even if the team is able to independently hire employees, it is inappropriate to increase the size of a team of more than seven people.
In some cases, an increase in commands can lead to an acceleration of work, if this occurs taking into account the fact that these are intangible, uncountable resources.
Obstacle # 2: Teams Organized by Functional Affiliation
Scrum teams are cross-functional teams that try to create a thoroughly tested product increment each sprint, gradually increasing functionality. The most popular book on Scrum uses the phrase “potentially“ Ready to release Product Increment ”(“ potentially shippable product increment ”) 18 times. Despite this, I meet people who claim to "practice Scrum", using "analytical sprints" or "design sprints" at the beginning of the project, postponing integration and testing for later, and engaging different teams to perform each part of the work. Habits acquired from the Waterfall Model of Project Management hide risks until it is too late to do something.
In Scrum, during each Sprint, a combination of various developmental activities is required. We gain flexibility through continuous requirements analysis, continuous design, continuous integration and continuous testing, all team members together.
Obstacle # 3: Teams, organized by architectural component
Teams created to work on one component reduce business opportunities to reorient product capabilities, increase the number of bottlenecks in communication with managers and product owners and introduce additional integration risks.
Such teams would be effective if new product development was as predictable as production. In practice, priorities change, and estimates turn out to be incorrect. Therefore, it is difficult to attract the right people at the right time to lead a development that can affect several components.
The opposite of the Component Team is the Functional Team, focused on the development of new product features ( feature team ). A functional team encompasses both components and disciplines, and is thus capable of implementing functional tasks for a business in thin, fully tested “vertical sections” of the product. This approach is intended to replace the concepts of the past century, based on the concepts of team autonomy, self-organization and responsibility. The product backlog of Functional Commands is based on the needs of the business, not on technology dependencies. If you are still using Gantt Charts, most likely you have not yet organized Function Commands.
Creating Functional Teams is costly: developers will need to learn new skills, which will slow them down at the start. Fortunately, most developers love to learn new skills. Methods such as assigning a technical “component component guardian ” to each area can help protect architectural integrity as teams learn. As with any large-scale development, continuous integration (automated tests performed much more often than once a day) is crucial to prevent undetected defects in the overall health of the product.
After the organization learns to manage the Functional Teams, the next step may be the creation of General purpose Function teams with minimal dependencies on the functional areas. This process may require years of continuous learning within the organization.
Obstacle # 4: Distraction
Millions of dollars are spent in typical large organizations because of the unnecessary switching between tasks. Teams lack focus and months of stability with respect to the composition of the team in order to achieve the state of self-organization required for high performance and quality. Some people are constantly on several "critical paths" at the same time, which seriously limits the overall performance. To scale effectively, these people must become mentors, not task performers. To increase their influence, they must relinquish some control.
Traditional management techniques that enhance specialization will only exacerbate the problem. Work should be given to the Scrum team during a Sprint Planning Meeting. When the manager does not take this into account, assigning tasks to specific performers, specialists do not have the opportunity to instruct and train others in important skills. At one of the meetings for Planning Sprint, I was faced with the fact that the first question that was asked was: “Who will work with us on this Sprint?”. Persons who are constantly being pulled will not train others, although this is expected from Scrum teams. And organizations are digging into these problems every day more and more.
In higher positions, there are even more problems associated with multitasking, distraction, anxiety and the inability to gain control over what is happening. The Product Owner, at the same meeting, came annoyed, an hour late, and ran away again after 10 minutes. And they told me that it happens all the time.
And after lunch, the manager was unable to dedicate himself to meeting with 60 of his employees because he was simultaneously trying to solve another problem through services on his phone. The casual observer of these scenes could not have imagined that these rabid, event-driven slaves were responsible for the strategy for further development.
Effective horizontal communication between Scrum teams helps Product Owners to calmly focus on such duties as setting work priorities and determining final requirements.
Obstacle # 5: Unwillingness to continually review, prioritize, and detail the backlog of the Product
When developing a product, the rate of detection of new tasks that need to be done is usually ahead of the speed of development itself. To cope with this, the Product Owner must conduct Refinement Meetings to review, prioritize and clarify the tasks in the Backlog of Products each Sprint. When too large tasks (“epics”) appear in Baclog, it is necessary to find their key aspects and divide them into small subtasks (usually called “User Stories”). The Product Owner controls the scope of work, deciding which tasks will be included in the Release, taking into account data on development speed and scope of work performed during the Sprint.
Obstacle # 6: “Technical Debt”
The problems of managing an organization are ultimately visible in the source code. And “technical debt” causes problems in the product and the high cost of change. Ideally, regression tests can be automated using the same programming language used in product development, without using proprietary tools that only increase dependence on specific knowledge. Skills such as Test Driven Development (TDD) proved their worth in the 20th century. In the 21st century, any developer is expected to have skills in flexible methodologies. And teams that do not yet possess these skills should try to work with “vertical task cuts” until they learn .
Obstacle # 7: Unwillingness to Change
Scrum assigns one person per team (ScrumMaster) to focus on identifying and overcoming such obstacles . This requires courage, imagination and support from management. Too few Scrum Masters pay due attention to such problems, and management often does not support those who do it.
“Too many tasks” or “not enough resources” or “unstable market situation” is not a good excuse for not introducing Flexible methodologies specifically designed to solve these problems. And the people responsible for the changes should be better prepared to overcome the Obstacles to the implementation of Flexible Methodologies, recognizing that the key causes of problems in maintaining bad habits, formed “reflexes” and delusions.
Text of the original article: 7 Obstacles to Enterprise Agility
Posted by: Michael James
Translation: Daniel Chernyshev
Translated with the consent of the author.
Source: https://habr.com/ru/post/327158/
All Articles