November 7, 2014 at 13:24Will SAFe become the industry standard for Enterprise Agile?
May 6, 2014 Scaled Agile, Inc. was named the finalist of the 2014 year in the nomination Red Herring Top 100 in the United States. This news was quite expected for specialists in Enterprise Agility and for consulting firms providing services in the organizational transformation of companies. The reason for this is simple - market needs have changed dramatically.
A number of global companies such as ING, TomTom, T-Mobile and IBM have long been interested in SAFe. Swiss companies such as Swisscom, SwissPost, Kuoni and Credit Suisse also successfully implement SAFe through their own certified and external consultants.
Unresolved issue
One of the reasons for the proliferation of the Scaled Agile Framework (SAFe)is a debacle that has suffered flexible approaches to managing software development in the eyes of program managers and VPs of large companies. Despite conditional compliance with the values and principles of Agile Software Development, the majority nevertheless sought to predict the delivery time of the product and a proven approach that could be “deployed” to the R&D department of several hundred, or even thousands of people.
While small companies can afford the luxury of overlapping roles and other forms of process deviation, Enterprise-sized companies rely on a clear structure and an efficient responsibility allocation model.
This becomes especially relevant for companies in which it is necessary to combine solutions for managing a portfolio of projects (based on “old school” approaches that are not best suited for this task like PRINCE2) and dynamic development within the teams themselves through Scrum.
Imagine for a moment that you need to link together a portfolio of more than 20 products, each of which has 5-10 key stakeholders, is developed in 4 different countries by 7-10 teams. A task of this level makes even the very seasoned CTO or VP of development work hard.
Unfortunately, it’s indecent to often hear in communication with our customers that the company has successfully implemented Agile at the team level, but this doesn’t fundamentally change anything in the company, because management continues to think with old dogmas at the level of the product portfolio and cannot effectively use potential flexibility in business.
SAFe educational program
SAFe grace and its key advantage for large companies is to develop a simple and transparent organizational structure, coupled with a clear model of responsibility distribution. Both ideas are rooted in RUP (Dean Leffingwell, author of SAFe, was responsible for developing and commercializing RUP at Rational Software).
The SAFe model breaks down any enterprise into three levels: portfolio, program and team, and the SAFe management model is represented by two verticals:
1) the vertical “content” (which the company will release) of the product, which is represented by the product management team, UX and Architects
2) the vertical “Deliveries” (How the company will release the product to the market) in the person of project and program managers.
Management is provided by the sole 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 supply cycles at each level is required.
The very juice lies in starting Agile programs
Businesses launch programs to create software products, platforms, or services. Thus, various types of project offices (PMOs) 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 under the need of another initiative from the business occurs with a pronounced component structure of the organization (i.e. there are teams that are responsible for the feature, technological layer, or component of the system).
Scrum began to “require” PMO managers to achieve cross-functionality at the level of fixed teams, the composition of which has not changed for 6-12 months. This has become a stumbling block for many companies in the transition to Agile-rails.
SAFe offers an elegant solution to this problem by moving the Scrum model to the program implementation level. 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 imagine 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 each of your teams is a “superman”. If you combine all your “supermen” into one team, you will get a team that covers the entire platform. What if we run the Agile development process for our “superman team," but on a larger scale? Since each "superman" delivers 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 supply manager (aka Super Scrum Master) to our team. A team of supermen makes planning and takes responsibility at the beginning of the iteration, defines and solves the relationships between the "supermen". Weekly (or bi-weekly) meetings (aka Scrum of Scrum) are essential for synchronizing the “Superman team.” At the end of a 2-3 month iteration, the teams demonstrate the results of work and retrospectively improve their work in the future. And now let's go back again and convert individual “supermen” into component teams or into teams working on a separate software function. In such a tricky way, we just created an Agile-style software management layer.
Ghm, excuse me, but what about architecture?
As we already know, the Agile approach to developing business functionality works great across the enterprise. But what if an enterprise has a complex solution (as a rule, it 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 adherents 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, most likely, it will fail on a large scale due to the large number of teams and the need for synchronization between them.
Taking all of the above into account, SAFe offers 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 architecture works at least one two-three-month cycle ahead of the rest of the teams, creating an architectural reserve for functional / component teams that will allow you to effectively develop business functionality during subsequent cycles.
This approach connects the architectural team with the content management vertical and solves the dilemma that seems to always exist in enterprises: to whom does the architectural team report: to product managers or managers responsible for product delivery?
Summary
The article turned out to be longer than we originally planned, so we conclude 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 go on the Agile track or get something more than just a set of new roles and terms from the already completed transition.
SAFe authors talk about the following results, citing their customers:
Our experience is more modest, and nevertheless, a number of clients, through the implementation of the principles from the SAFe approach, talk about reducing the time to market a product by up to 20 percent, and also note an increased degree of transparency and manageability of the process, more satisfaction of employees.
After 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 you to solve a lot of problems in various areas of software development. This view is supported by a rapidly growing list of international companies that exemplify the success of SAFe implementation and make us consider SAFe as one of the approaches to implementing Agile for large organizations that has every chance of becoming an industry standard.
A number of global companies such as ING, TomTom, T-Mobile and IBM have long been interested in SAFe. Swiss companies such as Swisscom, SwissPost, Kuoni and Credit Suisse also successfully implement SAFe through their own certified and external consultants.
Unresolved issue
One of the reasons for the proliferation of the Scaled Agile Framework (SAFe)is a debacle that has suffered flexible approaches to managing software development in the eyes of program managers and VPs of large companies. Despite conditional compliance with the values and principles of Agile Software Development, the majority nevertheless sought to predict the delivery time of the product and a proven approach that could be “deployed” to the R&D department of several hundred, or even thousands of people.
While small companies can afford the luxury of overlapping roles and other forms of process deviation, Enterprise-sized companies rely on a clear structure and an efficient responsibility allocation model.
This becomes especially relevant for companies in which it is necessary to combine solutions for managing a portfolio of projects (based on “old school” approaches that are not best suited for this task like PRINCE2) and dynamic development within the teams themselves through Scrum.
Imagine for a moment that you need to link together a portfolio of more than 20 products, each of which has 5-10 key stakeholders, is developed in 4 different countries by 7-10 teams. A task of this level makes even the very seasoned CTO or VP of development work hard.
Unfortunately, it’s indecent to often hear in communication with our customers that the company has successfully implemented Agile at the team level, but this doesn’t fundamentally change anything in the company, because management continues to think with old dogmas at the level of the product portfolio and cannot effectively use potential flexibility in business.
SAFe educational program
SAFe grace and its key advantage for large companies is to develop a simple and transparent organizational structure, coupled with a clear model of responsibility distribution. Both ideas are rooted in RUP (Dean Leffingwell, author of SAFe, was responsible for developing and commercializing RUP at Rational Software).
The SAFe model breaks down any enterprise into three levels: portfolio, program and team, and the SAFe management model is represented by two verticals:
1) the vertical “content” (which the company will release) of the product, which is represented by the product management team, UX and Architects
2) the vertical “Deliveries” (How the company will release the product to the market) in the person of project and program managers.
Management is provided by the sole 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 supply cycles at each level is required.
The very juice lies in starting Agile programs
Businesses launch programs to create software products, platforms, or services. Thus, various types of project offices (PMOs) 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 under the need of another initiative from the business occurs with a pronounced component structure of the organization (i.e. there are teams that are responsible for the feature, technological layer, or component of the system).
Scrum began to “require” PMO managers to achieve cross-functionality at the level of fixed teams, the composition of which has not changed for 6-12 months. This has become a stumbling block for many companies in the transition to Agile-rails.
SAFe offers an elegant solution to this problem by moving the Scrum model to the program implementation level. 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 imagine 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 each of your teams is a “superman”. If you combine all your “supermen” into one team, you will get a team that covers the entire platform. What if we run the Agile development process for our “superman team," but on a larger scale? Since each "superman" delivers 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 supply manager (aka Super Scrum Master) to our team. A team of supermen makes planning and takes responsibility at the beginning of the iteration, defines and solves the relationships between the "supermen". Weekly (or bi-weekly) meetings (aka Scrum of Scrum) are essential for synchronizing the “Superman team.” At the end of a 2-3 month iteration, the teams demonstrate the results of work and retrospectively improve their work in the future. And now let's go back again and convert individual “supermen” into component teams or into teams working on a separate software function. In such a tricky way, we just created an Agile-style software management layer.
Ghm, excuse me, but what about architecture?
As we already know, the Agile approach to developing business functionality works great across the enterprise. But what if an enterprise has a complex solution (as a rule, it 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 adherents 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, most likely, it will fail on a large scale due to the large number of teams and the need for synchronization between them.
Taking all of the above into account, SAFe offers 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 architecture works at least one two-three-month cycle ahead of the rest of the teams, creating an architectural reserve for functional / component teams that will allow you to effectively develop business functionality during subsequent cycles.
This approach connects the architectural team with the content management vertical and solves the dilemma that seems to always exist in enterprises: to whom does the architectural team report: to product managers or managers responsible for product delivery?
Summary
The article turned out to be longer than we originally planned, so we conclude it with a brief summary of the main ideas on the Scaled Agile Framework (SAFe):
- clear separation of the 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 issue teams)
- joint planning by program teams in 2-3 month cycles
- the allocation of the architectural channel for the study 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 go on the Agile track or get something more than just a set of new roles and terms from the already completed transition.
SAFe authors talk about the following results, citing their customers:
- 27 weeks shorter product time to market
- 25 percent increase in customer satisfaction
- 50 percent reduction in product development costs
Our experience is more modest, and nevertheless, a number of clients, through the implementation of the principles from the SAFe approach, talk about reducing the time to market a product by up to 20 percent, and also note an increased degree of transparency and manageability of the process, more satisfaction of employees.
After 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 you to solve a lot of problems in various areas of software development. This view is supported by a rapidly growing list of international companies that exemplify the success of SAFe implementation and make us consider SAFe as one of the approaches to implementing Agile for large organizations that has every chance of becoming an industry standard.