When it comes to scaling agile to the enterprise, there are two classes of challenges that must be addressed. The first- the challenges inherent in agile itself – present limits of technology because of the fixed rule bases and assumptions built into the methods.
The second – those imposed by the enterprise – are impediments that likely exist within the enterprise that will otherwise prevent the successful application of the new methods. Both types of challenges must be successfully addressed in order for the enterprise to achieve the full benefits of agile.
Here is brief introduction some of the issues which should be consider for scaling agile in enterprise.
Small Team size
XP and Scrum recommend teams of 8 or fewer people including product owner/managers or other customer proxy, developers and testers. In many cases, teams decide that even that number is too large, and they may subdivide into components or feature team of three to five people. To an enterprise with 1000 practitioners to deploy, thinking in terms of managing literally hundreds of teams boggles the mind, and there arises the need to understand how to fit this new model into the existing organizational hierarchy.
Customer is Integral to Team
XP Success in particular in a number of IT like environments where the customer was literally down the hall the business analyst who worked with that department was willing and able to participate in the fine grained, detailed review that stories and customer written acceptance tests require.
for many enterprises however, this is not the case, the customer maybe be remote or may not have the skills or time available to participate in such a manner. Or perhaps the enterprise is a large ISV where the application has tens of thousand of users and where there is no single customer to satisfy. Every customer is different, and the larger ones speak loudly indeed, and the information flow is attenuated through many groups before it reaches the team.
Collocation
Much of the productivity of agile comes from the paring contexts, daily stand up, visual signaling of stories and status, and constant informal communication that characterizes these methods. Developers, product owners, and testers are together, not separated by time zones and language barriers.
At scale, collocation is impractical even for large teams in the same building and other mechanisms must be devised. Moreover it is likely that many team members are in different countries and different time zones and perhaps even speak different languages.
Architecture Emerges
Agile and more specifically, XP trades off the ability to refactor code quickly with the cost and investment necessary to create a more forward looking architecture, some architectural runway, that coordinate the efforts of distributed teams.
With the large scale systems however, the refactor cost curve may not be the case, because hundreds of person years may be necessary to get even a first release deployed. Since agile generally does not coach how to approach architecting larger scale systems, that apparent limitation is often a real impediment for agile adoption.
Lack of requirements analysis and documented Specifications
Agile practice of working on a few stories at a time is a wonderfully focusing mechanism for the team. But in larger system, what drive these stories into existence? Who says these stories are the right stories? Will the summation of all these stories actually meet our customer needs?
Culture and Physical Environment
Effective agile environments look and sound different. Most team members work in an open or nearly open environment and often their manager and supervisors have left their offices and joined the team at those tables. Also the process does not look very efficient because there is a certain informality to stories posted on walls, whiteboards shoved hither and you, and teams of people seeming to do far more talking than coding.
Existing Formalized Policies and Procedures
As organization grow, they tend to put in infrastructure to control and measure project, program, human resource and other assets, these include all of the procedure, policies that organization use. And this is part of organization culture and knowledge base which is gained in past project.
Management Style – Fixed Schedule, Fixed functionality Mandates
If a mandate comes to team to deliver functionality X in period of Y with resources Z, then by definition it does not meet agile fixed time, variable scope mantra. And the teams will be discouraged right out of the starting gate.
This mode of management is routine in our industry and most likely, this imprediment will have to be addressed head on. It’s true that the teams would like to be able to predict exactly when they can deliver what functionality, but they know they can not, and it seems inherently silly to them when management just says, “Make it be so”.
People Organized by Discipline rather than Product line
The word Organization in itself can be a root cause of impediments to agile, for the enterprise is surely organized in some fashion already, and most likely it is organized along functional (product management, architecture, developers) rather than product or business application lines. In agile, teams quickly reorganize to assure they have a full complement of the resources necessary to define/build/test and deliver a component of feature.
This require dedicated (not heavy multiplexed) resources for the project, or else the team will fail to meet its commitment to the iteration. Reorganization typically requires redefinition of what makes a team a team in the enterprise.
High Degree of Distribution
The enterprise is an enterprise because it has grown with its successes. For most enterprises, success often involves acquisitions of teams or product lines or existing IT organization along the way. Rarely are these teams collocated and the large the enterprise, the less likely they are to be together in one place.
Moreover, raw size alone prevents pure collocation because there is no way physically to collocation even 100 people in one workspace, so the problem of distributed teams is endemic to agile at scale.
The second – those imposed by the enterprise – are impediments that likely exist within the enterprise that will otherwise prevent the successful application of the new methods. Both types of challenges must be successfully addressed in order for the enterprise to achieve the full benefits of agile.
Here is brief introduction some of the issues which should be consider for scaling agile in enterprise.
Small Team size
XP and Scrum recommend teams of 8 or fewer people including product owner/managers or other customer proxy, developers and testers. In many cases, teams decide that even that number is too large, and they may subdivide into components or feature team of three to five people. To an enterprise with 1000 practitioners to deploy, thinking in terms of managing literally hundreds of teams boggles the mind, and there arises the need to understand how to fit this new model into the existing organizational hierarchy.
Customer is Integral to Team
XP Success in particular in a number of IT like environments where the customer was literally down the hall the business analyst who worked with that department was willing and able to participate in the fine grained, detailed review that stories and customer written acceptance tests require.
for many enterprises however, this is not the case, the customer maybe be remote or may not have the skills or time available to participate in such a manner. Or perhaps the enterprise is a large ISV where the application has tens of thousand of users and where there is no single customer to satisfy. Every customer is different, and the larger ones speak loudly indeed, and the information flow is attenuated through many groups before it reaches the team.
Collocation
Much of the productivity of agile comes from the paring contexts, daily stand up, visual signaling of stories and status, and constant informal communication that characterizes these methods. Developers, product owners, and testers are together, not separated by time zones and language barriers.
At scale, collocation is impractical even for large teams in the same building and other mechanisms must be devised. Moreover it is likely that many team members are in different countries and different time zones and perhaps even speak different languages.
Architecture Emerges
Agile and more specifically, XP trades off the ability to refactor code quickly with the cost and investment necessary to create a more forward looking architecture, some architectural runway, that coordinate the efforts of distributed teams.
With the large scale systems however, the refactor cost curve may not be the case, because hundreds of person years may be necessary to get even a first release deployed. Since agile generally does not coach how to approach architecting larger scale systems, that apparent limitation is often a real impediment for agile adoption.
Lack of requirements analysis and documented Specifications
Agile practice of working on a few stories at a time is a wonderfully focusing mechanism for the team. But in larger system, what drive these stories into existence? Who says these stories are the right stories? Will the summation of all these stories actually meet our customer needs?
Culture and Physical Environment
Effective agile environments look and sound different. Most team members work in an open or nearly open environment and often their manager and supervisors have left their offices and joined the team at those tables. Also the process does not look very efficient because there is a certain informality to stories posted on walls, whiteboards shoved hither and you, and teams of people seeming to do far more talking than coding.
Existing Formalized Policies and Procedures
As organization grow, they tend to put in infrastructure to control and measure project, program, human resource and other assets, these include all of the procedure, policies that organization use. And this is part of organization culture and knowledge base which is gained in past project.
Management Style – Fixed Schedule, Fixed functionality Mandates
If a mandate comes to team to deliver functionality X in period of Y with resources Z, then by definition it does not meet agile fixed time, variable scope mantra. And the teams will be discouraged right out of the starting gate.
This mode of management is routine in our industry and most likely, this imprediment will have to be addressed head on. It’s true that the teams would like to be able to predict exactly when they can deliver what functionality, but they know they can not, and it seems inherently silly to them when management just says, “Make it be so”.
People Organized by Discipline rather than Product line
The word Organization in itself can be a root cause of impediments to agile, for the enterprise is surely organized in some fashion already, and most likely it is organized along functional (product management, architecture, developers) rather than product or business application lines. In agile, teams quickly reorganize to assure they have a full complement of the resources necessary to define/build/test and deliver a component of feature.
This require dedicated (not heavy multiplexed) resources for the project, or else the team will fail to meet its commitment to the iteration. Reorganization typically requires redefinition of what makes a team a team in the enterprise.
High Degree of Distribution
The enterprise is an enterprise because it has grown with its successes. For most enterprises, success often involves acquisitions of teams or product lines or existing IT organization along the way. Rarely are these teams collocated and the large the enterprise, the less likely they are to be together in one place.
Moreover, raw size alone prevents pure collocation because there is no way physically to collocation even 100 people in one workspace, so the problem of distributed teams is endemic to agile at scale.
Source: Scaling Software Agility Best Practices for Large Enterprises by Dean Leffingwell
No comments:
Post a Comment