Will SAFe be an industry standard in Enterprise Agile?
May 6, 2014 Scaled Agile, Inc. was named the 2014 finalist in the Red Herring Top 100 category in the United States. This news has become quite expected for specialists in Enterprise Agility and for consulting firms that provide services in the organizational transformation of companies. The reason for this is simple - the needs of the market have seriously changed.
A number of global companies such as ING, TomTom, T-Mobile and IBM have long shown interest in SAFe. Swiss companies such as Swisscom, SwissPost, Kuoni and Credit Suisse are also successfully implementing SAFe through their own certified and external consultants.
Unsolved problem
')
One of the reasons for the rapid spread of the Scaled Agile Framework (SAFe) is a fiasco, which suffered flexible approaches to managing software development in the eyes of program managers and VPs of large companies. Despite the conditional compliance with the values ​​and principles of Agile Software Development, the majority still sought to predict the delivery time of the product and a proven approach that can be “deployed” to the R & D department in several hundreds, or even thousands.
While small companies can afford the luxury of overlapping roles and other forms of process deviation, companies in the size of an Enterprise in their management rely on a clear structure and effective model of distribution of responsibility.
This is especially relevant for companies where you need to link project management solutions (based on "old school" and not the best approach for this task, such as PRINCE2) and dynamic development in the teams themselves through Scrum.
Imagine for a moment that you need to link together the release of a portfolio of more than 20 products, each of which has 5-10 key stakeholders, being developed in 4 different countries by 7-10 teams. The task of such a level makes even very hard-working CTO or VP to develop their efforts.
Unfortunately, it is indecent often in communication with our customers to hear that the company has successfully implemented Agile at the command level, but this does not fundamentally change anything in the company, because the management continues to think with old dogmas at the product portfolio level and cannot effectively use the potential business flexibility.
SAFe educational program
The grace of SAFe and its key advantage for large companies is to bring together a simple and transparent organizational structure paired with a clear responsibility-sharing model. Both ideas are rooted in RUP (Dean Leffingwell, author of SAFe, was responsible for the development and commercialization of RUP in Rational Software).
The SAFe model divides any enterprise into three levels: a portfolio, programs, and teams, and the management model in SAFe is represented by two verticals:
1) a vertical of “content” (that the company will produce) of a product that is represented by a team of product managers, UX and Architects
2) the vertical "supply" (How the company will release the product to the market) in the face of project and program managers.
Management is provided by the only responsible person at each level of each vertical, i.e. content and delivery, and requires regular synchronization between them. This principle is fundamental for large organizations where constant synchronization of delivery cycles at each level is necessary.
The juice is covered in the launch of Agile programs
Enterprises launch programs to create software products, platforms, or services. Thus, various types of project offices (PMO) are designed to support program execution in the most efficient way.
Approaches like Scrum have brought “hard times” for all sorts of PMOs. Classically, business initiatives formed at the portfolio level found expression in the form of projects for which separate, temporary project teams are created. Continuous creation of projects for the need for another initiative from the business takes place with a pronounced component structure of the organization (ie, there are teams that are responsible for the feature, technological layer, or system component).
Scrum, however, began to “demand” from PMO managers to achieve cross-functionality at the level of fixed teams, whose composition does not change for 6-12 months. For many companies, this has become a stumbling block in the transition to Agile-rails.
SAFe offers an elegant solution to this problem by moving the Scrum model to the level of program implementation. Let's see how it works.
Imagine a group of 5-7 people: developers, QAs and DevOps working on specific components of the platform (or represent a team working on individual functions of a software product: functional teams). Suppose the platform has another 5-7 component teams that are organized in a similar way. All teams work synchronously using 2-week sprints and quite predictably deliver working functionality after each sprint. Now imagine that your every team is “superman.” If you combine all your "supermen" in one team - you get a team that covers the entire platform. But what if we run the Agile development process for our “team of supermen", but on a larger scale? Since every "superman" makes a delivery every 2 weeks, the duration of our iteration (cycle) will be 2-3 months
Let's assign a product manager (aka Super Product Owner) and a delivery manager (aka Scrum Master) to our team. The team of supermen does the planning and undertakes obligations at the beginning of the iteration, determines and solves the dependencies between the "supermen". Weekly (or biweekly) meetings (aka Scrum of Scrum) are essential for synchronization of the “superman team”. At the end of the 2-3 month iteration, the team makes a demonstration of the results of work and produce a retrospective to improve their work in the future. And now let's go back again and convert individual “supermen” into component teams or teams working on a separate software function. In this not tricky way, we have just created an Agile-style program management layer.
GHM, sorry, but what about architecture?
As we already know, the Agile approach to the development of business functionality works perfectly across an enterprise. But what if an enterprise has a complex solution (as it usually is in real life) that includes a number of obsolete modules or components that require a new architecture or “refactoring” to create new functionality?
Early supporters of Agile principles sometimes went too far, denying the need to develop an architecture for future functionality for the future, relying only on evolutionary design principles. This approach may work for startups and medium-sized enterprises, but is likely to fail on a large scale due to the large number of teams and the need for synchronization between them.
Taking into account all the above, SAFe proposes a concept called the “Architecture runway”. In fact, there is no magic in this approach - it is based on simple logic. The team responsible for the architecture works for at least one two-three-month cycle ahead of the rest of the teams, creating an architectural reserve for functional / component teams that will effectively develop business functionality during subsequent cycles.
This approach connects the architectural team with the vertical content management and solves the dilemma that seems to always exist in the enterprises: to whom does the architectural team: product managers or managers responsible for the delivery of the product?
Summary
The article turned out to be longer than we originally planned, so we end it with a brief summary of the main ideas on the Scaled Agile Framework (SAFe):
What results to expect
The above-mentioned aspects are far from a complete list of the needs of large companies that would like to switch to Agile's rails or get from the transition already made something more than just a set of new roles and terms.
SAFe authors talk about the following results, referring to their clients:
Our experience is more modest, and nevertheless, a number of clients, by introducing principles from the SAFe approach, show a reduction in time to market a product by 20 percent, and also note an increased degree of transparency and controllability of the process, greater employee satisfaction.
Having a lot of discussions with other consulting firms and private consultants, we see similar results from the implementation of SAFe. A number of our partners share the opinion that SAFe is not a “silver bullet”, but it allows to solve a lot of problems in various areas of software development. This view is supported by the rapidly growing list of international companies, which by their example confirm the success of SAFe implementation and force us to consider SAFe as one of the approaches to the implementation of Agile for large organizations, which has all the chances to become an industry standard.
A number of global companies such as ING, TomTom, T-Mobile and IBM have long shown interest in SAFe. Swiss companies such as Swisscom, SwissPost, Kuoni and Credit Suisse are also successfully implementing SAFe through their own certified and external consultants.
Unsolved problem
')
One of the reasons for the rapid spread of the Scaled Agile Framework (SAFe) is a fiasco, which suffered flexible approaches to managing software development in the eyes of program managers and VPs of large companies. Despite the conditional compliance with the values ​​and principles of Agile Software Development, the majority still sought to predict the delivery time of the product and a proven approach that can be “deployed” to the R & D department in several hundreds, or even thousands.
While small companies can afford the luxury of overlapping roles and other forms of process deviation, companies in the size of an Enterprise in their management rely on a clear structure and effective model of distribution of responsibility.
This is especially relevant for companies where you need to link project management solutions (based on "old school" and not the best approach for this task, such as PRINCE2) and dynamic development in the teams themselves through Scrum.
Imagine for a moment that you need to link together the release of a portfolio of more than 20 products, each of which has 5-10 key stakeholders, being developed in 4 different countries by 7-10 teams. The task of such a level makes even very hard-working CTO or VP to develop their efforts.
Unfortunately, it is indecent often in communication with our customers to hear that the company has successfully implemented Agile at the command level, but this does not fundamentally change anything in the company, because the management continues to think with old dogmas at the product portfolio level and cannot effectively use the potential business flexibility.
SAFe educational program
The grace of SAFe and its key advantage for large companies is to bring together a simple and transparent organizational structure paired with a clear responsibility-sharing model. Both ideas are rooted in RUP (Dean Leffingwell, author of SAFe, was responsible for the development and commercialization of RUP in Rational Software).
The SAFe model divides any enterprise into three levels: a portfolio, programs, and teams, and the management model in SAFe is represented by two verticals:
1) a vertical of “content” (that the company will produce) of a product that is represented by a team of product managers, UX and Architects
2) the vertical "supply" (How the company will release the product to the market) in the face of project and program managers.
Management is provided by the only responsible person at each level of each vertical, i.e. content and delivery, and requires regular synchronization between them. This principle is fundamental for large organizations where constant synchronization of delivery cycles at each level is necessary.
The juice is covered in the launch of Agile programs
Enterprises launch programs to create software products, platforms, or services. Thus, various types of project offices (PMO) are designed to support program execution in the most efficient way.
Approaches like Scrum have brought “hard times” for all sorts of PMOs. Classically, business initiatives formed at the portfolio level found expression in the form of projects for which separate, temporary project teams are created. Continuous creation of projects for the need for another initiative from the business takes place with a pronounced component structure of the organization (ie, there are teams that are responsible for the feature, technological layer, or system component).
Scrum, however, began to “demand” from PMO managers to achieve cross-functionality at the level of fixed teams, whose composition does not change for 6-12 months. For many companies, this has become a stumbling block in the transition to Agile-rails.
SAFe offers an elegant solution to this problem by moving the Scrum model to the level of program implementation. Let's see how it works.
Imagine a group of 5-7 people: developers, QAs and DevOps working on specific components of the platform (or represent a team working on individual functions of a software product: functional teams). Suppose the platform has another 5-7 component teams that are organized in a similar way. All teams work synchronously using 2-week sprints and quite predictably deliver working functionality after each sprint. Now imagine that your every team is “superman.” If you combine all your "supermen" in one team - you get a team that covers the entire platform. But what if we run the Agile development process for our “team of supermen", but on a larger scale? Since every "superman" makes a delivery every 2 weeks, the duration of our iteration (cycle) will be 2-3 months
Let's assign a product manager (aka Super Product Owner) and a delivery manager (aka Scrum Master) to our team. The team of supermen does the planning and undertakes obligations at the beginning of the iteration, determines and solves the dependencies between the "supermen". Weekly (or biweekly) meetings (aka Scrum of Scrum) are essential for synchronization of the “superman team”. At the end of the 2-3 month iteration, the team makes a demonstration of the results of work and produce a retrospective to improve their work in the future. And now let's go back again and convert individual “supermen” into component teams or teams working on a separate software function. In this not tricky way, we have just created an Agile-style program management layer.
GHM, sorry, but what about architecture?
As we already know, the Agile approach to the development of business functionality works perfectly across an enterprise. But what if an enterprise has a complex solution (as it usually is in real life) that includes a number of obsolete modules or components that require a new architecture or “refactoring” to create new functionality?
Early supporters of Agile principles sometimes went too far, denying the need to develop an architecture for future functionality for the future, relying only on evolutionary design principles. This approach may work for startups and medium-sized enterprises, but is likely to fail on a large scale due to the large number of teams and the need for synchronization between them.
Taking into account all the above, SAFe proposes a concept called the “Architecture runway”. In fact, there is no magic in this approach - it is based on simple logic. The team responsible for the architecture works for at least one two-three-month cycle ahead of the rest of the teams, creating an architectural reserve for functional / component teams that will effectively develop business functionality during subsequent cycles.
This approach connects the architectural team with the vertical content management and solves the dilemma that seems to always exist in the enterprises: to whom does the architectural team: product managers or managers responsible for the delivery of the product?
Summary
The article turned out to be longer than we originally planned, so we end it with a brief summary of the main ideas on the Scaled Agile Framework (SAFe):
- clear separation of two verticals of responsibility (content and delivery)
- clear separation of team level, program level (joint efforts of several teams) and portfolio level (products / global initiatives that teams issue)
- joint planning by program teams in 2-3 monthly cycles
- highlighting the architectural channel for the development of functionality in advance.
What results to expect
The above-mentioned aspects are far from a complete list of the needs of large companies that would like to switch to Agile's rails or get from the transition already made something more than just a set of new roles and terms.
SAFe authors talk about the following results, referring to their clients:
- Reduction in time to market by 27 weeks
- Increase customer satisfaction by 25 percent
- 50 percent reduction in product development costs
Our experience is more modest, and nevertheless, a number of clients, by introducing principles from the SAFe approach, show a reduction in time to market a product by 20 percent, and also note an increased degree of transparency and controllability of the process, greater employee satisfaction.
Having a lot of discussions with other consulting firms and private consultants, we see similar results from the implementation of SAFe. A number of our partners share the opinion that SAFe is not a “silver bullet”, but it allows to solve a lot of problems in various areas of software development. This view is supported by the rapidly growing list of international companies, which by their example confirm the success of SAFe implementation and force us to consider SAFe as one of the approaches to the implementation of Agile for large organizations, which has all the chances to become an industry standard.
Source: https://habr.com/ru/post/242571/
All Articles