SAFe
m (→The Ten Essential Elements) |
|||
(37 intermediate revisions by 2 users not shown) | |||
Line 5: | Line 5: | ||
This article's purpose is to explain the SAFe methodology, its concept and its application in order to manage Programs composed of projects following Agile methods. | This article's purpose is to explain the SAFe methodology, its concept and its application in order to manage Programs composed of projects following Agile methods. | ||
− | The SAFe method is articulated around four core values<ref name="SAFe Whitepaper 4.5 | + | The SAFe method is articulated around four core values<ref name="SAFe Whitepaper 4.5">''SAFe® 4.5 Introduction: Overview of the Scaled Agile Framework® for Lean Enterprises'', Scaled Agile, Inc., August 2017</ref>: |
*'''Alignment''' of management and teams to a common mission, | *'''Alignment''' of management and teams to a common mission, | ||
Line 17: | Line 17: | ||
In order to pursue these values, SAFe organizes teams in stable teams of teams in the form of one or several Agile Release Train (ART). An ART is a networked organizational structure which relies on decentralized decision making for faster response times and higher reactivity. | In order to pursue these values, SAFe organizes teams in stable teams of teams in the form of one or several Agile Release Train (ART). An ART is a networked organizational structure which relies on decentralized decision making for faster response times and higher reactivity. | ||
− | SAFe is designed for scalability and is capable of supporting smaller scale programs involving less than a hundred team members as well as complex programs involving thousands of people. It is available in four different configurations depending on the needs of the user<ref name="SAFe Whitepaper 4.5 | + | SAFe is designed for scalability and is capable of supporting smaller scale programs involving less than a hundred team members as well as complex programs involving thousands of people. It is available in four different configurations depending on the needs of the user<ref name="SAFe Whitepaper 4.5"></ref>: |
− | *'''Essential SAFe''' the basic version of SAFe upon which the other configurations build on; | + | *'''Essential SAFe''' the basic version of SAFe upon which the other configurations build on. This version is what this article will be focused on; |
*'''Portfolio SAFe''' to apply the SAFe methodology to Portfolio Management; | *'''Portfolio SAFe''' to apply the SAFe methodology to Portfolio Management; | ||
Line 39: | Line 39: | ||
*'''Apply systems thinking''' | *'''Apply systems thinking''' | ||
− | In order to fix problems, it is necessary to understand complex | + | In order to fix problems, it is necessary to understand complex systems, which consist of multiples components related to each other. Focusing on one component of the system won’t make it possible to optimize the entire system. Moreover, it is important to be aware of the main goal of the system and to be committed to this goal. In order to apply SAFe, it is required to think of the system as a whole and not only of the organization which builds the system, but also to the systems under development. |
*'''Assume variability; preserve options''' | *'''Assume variability; preserve options''' | ||
− | SAFe follows different | + | SAFe follows a different approach for choosing design and life cycle practices from most practices. It keeps multiple design options and requirements for long time. SAFe uses empirical data to choose the right design and avoid excessively time consuming adjustments and suboptimal long-term design, which can result of a wrong design choice in early stages. |
*'''Build incrementally with fast, integrated learning cycles''' | *'''Build incrementally with fast, integrated learning cycles''' | ||
+ | |||
+ | One of the main principles is to build a working system in sequential iterations. Series of short iterations allow the teams to get fast feedback and give the opportunity to choose new routes and new courses of actions at early stages. Moreover, those iterations can be used as minimum viable products or prototypes. | ||
*'''Base milestones on objective evaluation of working systems''' | *'''Base milestones on objective evaluation of working systems''' | ||
+ | |||
+ | The sequential - traditional model of investments into new solutions fail to provide a risk free experience. On the other hand, Lean-Agile development offers safe model where integration points give objective milestones. This new model assures investors that they will have commensurate return. | ||
*''' Visualize and limit WIP, reduce batch sizes, and manage queue lengths''' | *''' Visualize and limit WIP, reduce batch sizes, and manage queue lengths''' | ||
+ | |||
+ | The continuous flow allows to move new system capabilities from concept to liquid money. There are few main points which need to be considered when implementing flow: | ||
+ | |||
+ | In order to restrict demand to the actual capacity, it is needed to limit the amount of work in progress; | ||
+ | |||
+ | To assist the progress of safe and fast flow through the system, it is needed to limit the size of work batches; | ||
+ | |||
+ | To decrease the waiting time for new capabilities, it is needed to carefully control how much work is queued. | ||
*'''Apply cadence, synchronize with cross-domain planning''' | *'''Apply cadence, synchronize with cross-domain planning''' | ||
+ | |||
+ | In order to minimize uncertainties and operate safely on the level of product development, it is important to implement synchronization, cadence, and cross-domain planning. Synchronization helps to understand and integrate numerous perspectives simultaneously. Moreover, cadence gives opportunity to create a rhythm for the development process and increases predictability. | ||
*'''Unlock the intrinsic motivation of knowledge workers''' | *'''Unlock the intrinsic motivation of knowledge workers''' | ||
− | Researchers proved that in order to achieve high level of employee engagement needed to show | + | Researchers proved that in order to achieve a high level of employee engagement it was needed to show purpose and give autonomy, and to put constraints at a minimum level. At the same time, individual incentive compensation will lead to internal competition and decrease cooperation, which will lead to longer times to achieve the goals of the system and will put both customers and the enterprise in an unfavorable position. |
*'''Decentralize decision-making''' | *'''Decentralize decision-making''' | ||
+ | SAFe uses decentralized decision-making, which allows to gain fast value delivery. Moreover, it allows to advance the product development flow, to decrease delays, to gain fast feedback and, lastly, to design inventive solutions. However, SAFe still uses centralized decision-making in some situations: centralized decision-making is sometimes necessary in order to make global, vital decisions for a company. In those cases, the SAFe principles give a foundation for solid decision-making. | ||
+ | |||
+ | It is important to point out that it is not enough to learn and apply principles alone. People working in an organization are usually afraid of organizational changes, so in order to help them achieve this change, it is needed to give them clear guidance about their roles and responsibilities. Therefore, SAFe offers detailed guidance about four configurations of SAFe. This article will be focused mainly on Essential SAFe which represents the core value of the SAFe method. | ||
== The Essential SAFe == | == The Essential SAFe == | ||
+ | |||
+ | [[File:SAFe-essential.png|256px|The Essential SAFe|thumb|right]] | ||
+ | |||
+ | The Essential SAFe configuration is a relatively simpler version of SAFe which allows in the future to transition to other more complete configurations. | ||
+ | |||
+ | It is centered around an Agile Release Train (ART) which includes agile teams and program-level leadership. All members of the ART work toward a single overarching goal. | ||
+ | |||
+ | === Essential SAFe Highlights === | ||
+ | |||
+ | The Essential SAFe covers the main elements of the Framework: | ||
+ | |||
+ | *The ART put together teams, stakeholders and management to achieve a main goal through the use of a common vision, program backlog and roadmap. | ||
+ | |||
+ | *ARTs provide user functionality and technical infrastructure in order to gain value on a sustainable basis. | ||
+ | |||
+ | *Team iterations use same start and end dates and work synchronously. | ||
+ | |||
+ | *System-level increments are evaluated every 2 weeks. | ||
+ | |||
+ | *Program Increments (PI) offer fixed periods of time where planning the work to be done, executing it, inspecting the results and adapting for the next PI is carried out in a cycle. | ||
+ | |||
+ | *Solutions can be released whenever needed, whether during the PI or at the end. | ||
+ | |||
+ | *Teams in the ART practice face-to-face PI planning in order to enable faster adaptation and reliable collaboration. | ||
+ | |||
+ | *ARTs provide a Continuous Delivery Pipeline, which enables the delivery of small increments of value. | ||
+ | |||
+ | *ARTs use Lean UX principles in order to provide consistent approaches to user experience. | ||
+ | |||
+ | *[[DevOps]] is culture, way of thinking, number of technical practices. It allows close connection and interaction within people needed to plan, test and release a solution. | ||
+ | |||
+ | === Roles === | ||
+ | The following roles help align multiple teams towards a common mission and vision, with the necessary coordination and governance. | ||
+ | |||
+ | *'''System Architect/Engineer''' can be an individual or a small team that takes care of system thinking. They decide what should be the overall architecture for the system and help define Nonfunctional Requirements. | ||
+ | *'''Product Management''' communicate with Product Owners and customers in order to define system features and participate in the validation of those. Moreover, Product Management takes care of defining the program backlog. | ||
+ | *'''Release Train Engineer''' (RTE) is one of the most important person for the ART. RTEs use several mechanisms such as the Program Kanban board, Inspect & Adapt (I&A) workshop, and PI Planning, in order to facilitate the flow of value. | ||
+ | *'''Business Owners''' are group of stakeholders who have both business and technical responsibility, including governance and return on investment. They are the main ART stakeholders. | ||
+ | *'''Customers''' are the main deciders of what constitutes value. | ||
+ | |||
+ | === The Ten Essential Elements === | ||
+ | |||
+ | Essential SAFe is based on ten essential elements from which most of the value of the SAFe method is extracted. | ||
+ | *'''Lean-Agile Principles''' The essence of SAFe is to be a program management method based on Lean-Agile principles. An organization that wants to apply the SAFe method should follow those principles, or at least the underlying ideas in cases where the practical application isn't relevant. | ||
+ | |||
+ | *'''Real Agile Teams and Trains''' Teams and train should be fully Agile and in particular shouldn't have to rely on other teams and trains to produce incremental value. This allows for shorter lead times in value production, in better customer engagement, and allows to extract more value from the Agile-specific roles like Scrum Masters, Product Owners, Product Managers, etc. as seen in the previous part about roles. | ||
+ | |||
+ | *'''Cadence and Synchronization''' Having a set cadence is important for making routine task actually routine, and synchronization helps solving problems across teams. | ||
+ | |||
+ | *'''PI Planning''' The PI planning is the event where all the teams in the ART meet and define what shall be done during the next PI - a cycle of ~10 weeks which represents the overarching cadence where medium-term objectives are achieved. All the teams working on it at the same time allows them to align together towards the same goal. | ||
+ | |||
+ | *'''[[DevOps]] and Releasability''' DevOps and Releasability are what allows a faster and more reactive delivery of value to the customers by enabling more frequent releases. | ||
+ | |||
+ | *'''System Demo''' SAFe places a big emphasis on measurable performance. The full system must be demoed to its stakeholders every two weeks so that the ART's progress can be measured and so that feedback can be taken into account as fast as possible. | ||
+ | |||
+ | *'''Inspect and Adapt''' Every PI an Inspect and Adapt (I&A) event shall be organized where stakeholders and teams work together to inspect the ART's products and decide what should be improved during the next PI. | ||
+ | |||
+ | *'''Innovation and Planning Iteration''' This is another event held during each PI to force the train to take some time and dedicate it to innovation, education and I&A so that the presence of urgent tasks doesn't completely prevent all those vital processes from taking place. | ||
+ | |||
+ | *'''Architectural Runway''' Having enough Architectural Runway means always having the infrastructure needed to accommodate all the high priority short term changes. Care must be taken not to run out of Architectural Runway or the train might have to slow down considerably while waiting for the infrastructure to be available or working around its limitations. | ||
+ | |||
+ | *'''Lean-Agile Leadership''' Leadership must take full responsibility for the adoption of Lean-Agile principles if the organization as a whole is to ever adopt those principles. | ||
+ | |||
= Implementation = | = Implementation = | ||
+ | |||
+ | |||
+ | [[File:SAFe-implementation-roadmap.jpg|256px|The SAFe Implementation Roadmap|thumb|left]] | ||
The implementation of SAFe is done in three main phases: | The implementation of SAFe is done in three main phases: | ||
* A preparation and planning phase | * A preparation and planning phase | ||
Line 69: | Line 152: | ||
During the first phase, key staff such as managers, leaders and change agents are trained in the SAFe method. ARTs and value streams are identified, and an implementation plan is created. Once this first phase is completed, the second phase starts by preparing for the ART launch and training the teams themselves in the SAFe method, then the first PI planning is organized and the ART is launched. A coaching in the SAFe ways is organized around that first ART, first focusing on the basics of SAFe but going deeper and deeper as the teams become more proficient. Once this first ART has been launched and a coaching team is organized around it, the third phase starts where SAFe is generalized and applied to more aspects of the company: more value streams and ARTs are launched, the method is extended to Portfolio management and the company globally tries to sustain and improve its processes. | During the first phase, key staff such as managers, leaders and change agents are trained in the SAFe method. ARTs and value streams are identified, and an implementation plan is created. Once this first phase is completed, the second phase starts by preparing for the ART launch and training the teams themselves in the SAFe method, then the first PI planning is organized and the ART is launched. A coaching in the SAFe ways is organized around that first ART, first focusing on the basics of SAFe but going deeper and deeper as the teams become more proficient. Once this first ART has been launched and a coaching team is organized around it, the third phase starts where SAFe is generalized and applied to more aspects of the company: more value streams and ARTs are launched, the method is extended to Portfolio management and the company globally tries to sustain and improve its processes. | ||
− | + | == The preparation and planning phase == | |
+ | === Reaching the tipping point === | ||
+ | The first phase's goal is to prepare the ground for the company to start using SAFe to manage a program consisting of projects that use Agile methods. This first step is usually taken after what SAFe calls '''Reaching the tipping point'''. | ||
+ | |||
+ | Every company tends to resist change in general and in particular to change in its way of working. However, change is sometimes needed and it becomes imperative for the company to achieve the change. In order to achieve such a massive change, it is needed to reach a tipping point where the required critical mass to enable rapid change is reached.<ref name="Gladwell, Malcolm">Gladwell, Malcolm (2000). The Tipping Point: How Little Things Can Make a Big Difference. Little Brown</ref> | ||
+ | |||
+ | There are two main reasons why companies embrace change.<ref name="scaled-agile-tp">https://www.scaledagileframework.com/reaching-the-tipping-point/</ref> The first is when the need for change is obvious: the performance of the company is dropping and the company needs to change its way of conducting business to survive, while the other is when leadership decided to achieve change proactively, believing implementing such a change will be beneficial for the future of the organization. | ||
+ | |||
+ | === Train Lean-Agile Change Agents === | ||
+ | At this point, the need for change has been recognized. A vision for this change must then be established. For an organization working in the Lean-Agile mindset, SAFe is one of the choices available to change their way of working and adapt to their evolving environment. To start preparing the implementation of this method, the first step is to '''Train Lean-Agile Change Agents'''.<ref name="SAFe_Whitepaper_4.5"/> The purpose of this step is to establish a powerful coalition that will drive the implementation of the change throughout the organization.<ref name="scaled-agile-tca">https://www.scaledagileframework.com/train-lean-agile-change-agents/</ref> | ||
+ | |||
+ | === Train Executives, Managers, and Leaders === | ||
+ | Once change agents have been trained, the next step is to '''Train Executives, Managers, and Leaders'''.<ref name="SAFe_Whitepaper_4.5"/> At its core, SAFe is a method used to manage a collection of projects along the Lean-Agile principles. Therefore, the principal stakeholders will be the program managers but also the project managers who manage the projects in the implicated programs. All those agents must be trained along with their leaders, those who will sponsor the change, and more generally all those who will be influencing or managing this change. This training occurs with the help of the change agents that were trained as part of the previous step. | ||
+ | |||
+ | === Identify Value Streams and ARTs === | ||
+ | After all the relevant stakeholders have been properly trained, the next step of the method is to '''Identify Value Streams and ARTs'''. This is done by first identifying the value streams: a value stream is basically a series of steps that are taken after some triggers the stream to achieve the production of value. For example, the trigger can be a customer ordering a product, the steps could be ordering raw materials, transforming them into the product that has been ordered, and delivering the product to the customer. The value produced is that of the final product, minus the costs incurred during the value stream. A value stream is of course identified by its trigger, its steps, and its value, but also by the people and systems it involves, as well as the time it takes to execute it. | ||
+ | |||
+ | After having identified the value streams, the organization needs to identify the ARTs that would enable it to execute those value streams as best as possible. An ART, standing for "Agile Release Train" is "a long-lived team of Agile teams, which, along with other stakeholders, incrementally develops, delivers, and where applicable operates, one or more solutions in a value stream."<ref name="SAFe-art">https://www.scaledagileframework.com/agile-release-train/</ref> Depending on the value streams identified, each ART can either be responsible for multiple smaller streams, be responsible for a single value stream in its entirety, or collaborate with other ARTs to enable one larger value stream to be operated. The key for choosing how to affect teams to ARTs is that each ART must be designed to be big enough for its responsibilities but small enough to be reactive to its environment (the method recommends 50 to 125 people in each ART), and each ART must have as little dependency on other ARTs as possible, and must be able to release (ie. produce value) independently from other ARTs. | ||
+ | |||
+ | === Create the Implementation Plan === | ||
+ | Finally, the last step of this first part is to '''Create the Implementation Plan'''. According to Agile principles, incremental value delivery is key for maximum reactivity and adaptability. Therefore at this stage, only one value stream is selected. Once a value stream has been selected, the ART most suitable for executing this stream is selected along with it, and it is time to prepare for the first ART launch. | ||
+ | |||
+ | == The minimum application phase == | ||
+ | |||
+ | === Prepare for ART Launch === | ||
+ | Now that the implementation plan has been drafted, the next step in the implementation of SAFe is to '''Prepare for ART launch'''. During this step the definition of the ART is refined so as to better understand the context in which it will operate, its boundaries, its interactions with other systems, etc. | ||
+ | |||
+ | After this, the launch date and the program calendar are set. The ART operates by cycles called ''Program Increment'' (PI), operating on a fixed cadence that can be set to any duration with eight to twelve weeks being recommended. Each PI includes a PI planning sessions at its start and can contain other items such as demos, introspective workshops, etc. | ||
+ | |||
+ | Once this calendar is set, teams are reorganized into Agile teams if necessary, and should include a Scrum Master and a Product Owner along with the team members that directly create the value. | ||
+ | |||
+ | At this point, Scrum Masters, Product Owners and Team managers receive training in SAFe, the launch readiness is evaluated, and once readiness is high enough the program's backlog is established. The program's backlog defines the scope of the Program by defining the various features that are to be developed, the non-functional requirements and the architectural work that define the future behavior of the system. | ||
+ | |||
+ | === Train Teams and Launch the ART === | ||
+ | The ART launch has now been defined. The next step at this point is to '''Train Teams and Launch the ART'''. At this point, all the team members receive SAFe training and, if necessary, Agile training as well. Each team must also establish its Team Backlog which identifies which features and requirements will be the responsibility of that team. Finally, the ART is launched with the first PI planning session. | ||
+ | |||
+ | === Coach ART Execution === | ||
+ | With the first ART having been launched, the preparatory work is now mostly finished and the next step is to '''Coach ART Execution''' to support the ART in its first iterations. Initially this coaching focuses on the individual teams to make them master their roles in the overall method. Coaching must also take place at program level, for example regarding PI planning sessions, demos, etc. | ||
+ | |||
+ | == The expansion phase == | ||
+ | |||
+ | The expansion phase mostly concerns a transition to large solution SAFe, Portfolio SAFe and Full SAFe which are mostly out of the scope of this article. | ||
+ | |||
+ | === Launch More ARTs and Value Streams === | ||
+ | |||
+ | At this point the organization has launched successfully its first ART responsible for a given value stream. Business benefits of the change should start to be measurable, helping to align all the personnel with the vision behind the change. It should now be easier to proceed with the next step: '''Launch More ARTs and Value Streams'''. Those ARTs are launched by repeating the steps that were taken to launch the first ART: ''Prepare for ART Launch'', ''Train Teams and Launch the ART'' and ''Coach ART Execution''. It is important however to not make the mistake of assuming that everyone already knows the process and skip on applying the same due process that was applied for the first ART. | ||
+ | |||
+ | When no more ARTs are needed for the value stream that was initally chosen, more value streams should also be launched along with one ART, starting over from the ''Identify Value Streams and ARTs'' step. Once this value stream and ART have been launched, more ARTs can be launched for that streams until the organization is ready to launch a new value stream, etc. | ||
+ | |||
+ | === Extend to the Portfolio === | ||
+ | |||
+ | After the previous step, SAFe has been applied to the whole program, and it is now possible to '''Extend it to the Portfolio'''. This is however out of the scope of this article. | ||
+ | |||
+ | === Sustain and improve === | ||
+ | |||
+ | Now that SAFe has been properly applied, it is necessary to keep applying it and improve in the use of SAFe. Metrics should be measured and value streams and ARTs reorganized for better value delivery, training and coaching should continue, architecture of the enterprise should be improved and improvement in general should be seeked at all time. | ||
= Limitations = | = Limitations = | ||
+ | |||
+ | SAFe's limitations pertain mainly to two categories. The first one is that it necessitates a lot of investment in training and coaching, or in the hiring of consultants in order to start applying it<ref name="qasymphony">https://www.qasymphony.com/blog/pros-cons-scaled-agile-framework-safe/</ref>. The second one is that it takes away a lot of power from the individual teams in favor of a more centralized approach, which goes against the values of agile methodologies<ref name="qasymphony"></ref> | ||
* Heavy training required | * Heavy training required | ||
Line 77: | Line 217: | ||
* Longer planning cycles than other methodologies based on Agile principles | * Longer planning cycles than other methodologies based on Agile principles | ||
* Requires relatively heavy administration, oversight and leadership layers | * Requires relatively heavy administration, oversight and leadership layers | ||
− | |||
= Bibliography = | = Bibliography = | ||
− | ''SAFe® 4.5 | + | |
+ | ''SAFe® 4.5 Reference Guide, Scaled Agile, Inc., August 2016'' | ||
+ | |||
+ | This book is the reference guide to the SAFe method and contains all the basic information one might want to know about how to apply SAFe. It constitutes an ideal reference regarding every SAFe concept and covers all levels of application be it team level, program level, large solution level or portfolio level. Since this book covers all the principles of SAFe, it should probably be read by every person who wish to apply SAFe in their organization. | ||
+ | |||
+ | ''Gladwell, Malcolm (2000). The Tipping Point: How Little Things Can Make a Big Difference. Little Brown'' | ||
+ | |||
+ | SAFe implementation relies on the fact that organizations tend to reach a point where change is needed for their futures, and therefore need to reach a tipping point where a critical mass of people is formed that enable massive change. This book discusses in general about those tipping point and how great changes can happen suddenly in the society in general. This is an interesting read for a SAFe practitioner as this tipping point effect is usually needed to apply SAFe in an organization that is already established with their own processes and ways of working. | ||
+ | |||
+ | ''The Standard for Program Management (2017), Project Management Institute'' | ||
+ | |||
+ | This book provides detailed knowledge about program management and gives clear information which could be used for most programs. Particularly Chapter 8.2 talks about Program Delivery phase activities. This information can help reader to understand contradictions between usual delivery phase activities as compared to SAFe activities. For example SAFe use close monitoring and frequent checks, which allows to change actions and chosen path if needed. This book enables the reader to understand standard project management methods. This in turn allows him to apply SAFe methods in a more informed way rather than in the dogmatic way someone who only knows about SAFe would behave. | ||
= References = | = References = |
Latest revision as of 12:58, 11 February 2021
Developed by Anna Shevchenko
Agile methods of project management are becoming increasingly popular even outside their origins as methods to organize software development teams. While these methods cover the project management aspect, they do not provide guidance as to how to manage programs as a whole, and due to the particularities of agile project management, special methods of program management have been developed to handle project teams using an agile methodology. SAFe is one such method of Program Management focusing on synchronizing agile project teams while also following Lean principles ie. trying to deliver a maximum of value to the customer in the shortest sustainable lead time.
This article's purpose is to explain the SAFe methodology, its concept and its application in order to manage Programs composed of projects following Agile methods.
The SAFe method is articulated around four core values[1]:
- Alignment of management and teams to a common mission,
- Built-in quality practices,
- Transparency,
- Program execution.
In order to pursue these values, SAFe organizes teams in stable teams of teams in the form of one or several Agile Release Train (ART). An ART is a networked organizational structure which relies on decentralized decision making for faster response times and higher reactivity.
SAFe is designed for scalability and is capable of supporting smaller scale programs involving less than a hundred team members as well as complex programs involving thousands of people. It is available in four different configurations depending on the needs of the user[1]:
- Essential SAFe the basic version of SAFe upon which the other configurations build on. This version is what this article will be focused on;
- Portfolio SAFe to apply the SAFe methodology to Portfolio Management;
- Large Solution SAFe for complex solutions that involve multiple ARTs but do not need to consider Portfolio management;
- Full SAFe that is meant to apply the SAFe methodology at every level.
Contents |
[edit] Concept
[edit] SAFe Principles
SAFe is based on nine main principles[2] :
- Take an economic view
The main aim of SAFe is to make it possible for a company to deliver as much value as possible in the shortest sustainable lead time. SAFe achieves this through incremental value delivery and decentralized decision-making, which requires the creation of a strategy and an economic framework in the light of which decisions can be taken.
- Apply systems thinking
In order to fix problems, it is necessary to understand complex systems, which consist of multiples components related to each other. Focusing on one component of the system won’t make it possible to optimize the entire system. Moreover, it is important to be aware of the main goal of the system and to be committed to this goal. In order to apply SAFe, it is required to think of the system as a whole and not only of the organization which builds the system, but also to the systems under development.
- Assume variability; preserve options
SAFe follows a different approach for choosing design and life cycle practices from most practices. It keeps multiple design options and requirements for long time. SAFe uses empirical data to choose the right design and avoid excessively time consuming adjustments and suboptimal long-term design, which can result of a wrong design choice in early stages.
- Build incrementally with fast, integrated learning cycles
One of the main principles is to build a working system in sequential iterations. Series of short iterations allow the teams to get fast feedback and give the opportunity to choose new routes and new courses of actions at early stages. Moreover, those iterations can be used as minimum viable products or prototypes.
- Base milestones on objective evaluation of working systems
The sequential - traditional model of investments into new solutions fail to provide a risk free experience. On the other hand, Lean-Agile development offers safe model where integration points give objective milestones. This new model assures investors that they will have commensurate return.
- Visualize and limit WIP, reduce batch sizes, and manage queue lengths
The continuous flow allows to move new system capabilities from concept to liquid money. There are few main points which need to be considered when implementing flow:
In order to restrict demand to the actual capacity, it is needed to limit the amount of work in progress;
To assist the progress of safe and fast flow through the system, it is needed to limit the size of work batches;
To decrease the waiting time for new capabilities, it is needed to carefully control how much work is queued.
- Apply cadence, synchronize with cross-domain planning
In order to minimize uncertainties and operate safely on the level of product development, it is important to implement synchronization, cadence, and cross-domain planning. Synchronization helps to understand and integrate numerous perspectives simultaneously. Moreover, cadence gives opportunity to create a rhythm for the development process and increases predictability.
- Unlock the intrinsic motivation of knowledge workers
Researchers proved that in order to achieve a high level of employee engagement it was needed to show purpose and give autonomy, and to put constraints at a minimum level. At the same time, individual incentive compensation will lead to internal competition and decrease cooperation, which will lead to longer times to achieve the goals of the system and will put both customers and the enterprise in an unfavorable position.
- Decentralize decision-making
SAFe uses decentralized decision-making, which allows to gain fast value delivery. Moreover, it allows to advance the product development flow, to decrease delays, to gain fast feedback and, lastly, to design inventive solutions. However, SAFe still uses centralized decision-making in some situations: centralized decision-making is sometimes necessary in order to make global, vital decisions for a company. In those cases, the SAFe principles give a foundation for solid decision-making.
It is important to point out that it is not enough to learn and apply principles alone. People working in an organization are usually afraid of organizational changes, so in order to help them achieve this change, it is needed to give them clear guidance about their roles and responsibilities. Therefore, SAFe offers detailed guidance about four configurations of SAFe. This article will be focused mainly on Essential SAFe which represents the core value of the SAFe method.
[edit] The Essential SAFe
The Essential SAFe configuration is a relatively simpler version of SAFe which allows in the future to transition to other more complete configurations.
It is centered around an Agile Release Train (ART) which includes agile teams and program-level leadership. All members of the ART work toward a single overarching goal.
[edit] Essential SAFe Highlights
The Essential SAFe covers the main elements of the Framework:
- The ART put together teams, stakeholders and management to achieve a main goal through the use of a common vision, program backlog and roadmap.
- ARTs provide user functionality and technical infrastructure in order to gain value on a sustainable basis.
- Team iterations use same start and end dates and work synchronously.
- System-level increments are evaluated every 2 weeks.
- Program Increments (PI) offer fixed periods of time where planning the work to be done, executing it, inspecting the results and adapting for the next PI is carried out in a cycle.
- Solutions can be released whenever needed, whether during the PI or at the end.
- Teams in the ART practice face-to-face PI planning in order to enable faster adaptation and reliable collaboration.
- ARTs provide a Continuous Delivery Pipeline, which enables the delivery of small increments of value.
- ARTs use Lean UX principles in order to provide consistent approaches to user experience.
- DevOps is culture, way of thinking, number of technical practices. It allows close connection and interaction within people needed to plan, test and release a solution.
[edit] Roles
The following roles help align multiple teams towards a common mission and vision, with the necessary coordination and governance.
- System Architect/Engineer can be an individual or a small team that takes care of system thinking. They decide what should be the overall architecture for the system and help define Nonfunctional Requirements.
- Product Management communicate with Product Owners and customers in order to define system features and participate in the validation of those. Moreover, Product Management takes care of defining the program backlog.
- Release Train Engineer (RTE) is one of the most important person for the ART. RTEs use several mechanisms such as the Program Kanban board, Inspect & Adapt (I&A) workshop, and PI Planning, in order to facilitate the flow of value.
- Business Owners are group of stakeholders who have both business and technical responsibility, including governance and return on investment. They are the main ART stakeholders.
- Customers are the main deciders of what constitutes value.
[edit] The Ten Essential Elements
Essential SAFe is based on ten essential elements from which most of the value of the SAFe method is extracted.
- Lean-Agile Principles The essence of SAFe is to be a program management method based on Lean-Agile principles. An organization that wants to apply the SAFe method should follow those principles, or at least the underlying ideas in cases where the practical application isn't relevant.
- Real Agile Teams and Trains Teams and train should be fully Agile and in particular shouldn't have to rely on other teams and trains to produce incremental value. This allows for shorter lead times in value production, in better customer engagement, and allows to extract more value from the Agile-specific roles like Scrum Masters, Product Owners, Product Managers, etc. as seen in the previous part about roles.
- Cadence and Synchronization Having a set cadence is important for making routine task actually routine, and synchronization helps solving problems across teams.
- PI Planning The PI planning is the event where all the teams in the ART meet and define what shall be done during the next PI - a cycle of ~10 weeks which represents the overarching cadence where medium-term objectives are achieved. All the teams working on it at the same time allows them to align together towards the same goal.
- DevOps and Releasability DevOps and Releasability are what allows a faster and more reactive delivery of value to the customers by enabling more frequent releases.
- System Demo SAFe places a big emphasis on measurable performance. The full system must be demoed to its stakeholders every two weeks so that the ART's progress can be measured and so that feedback can be taken into account as fast as possible.
- Inspect and Adapt Every PI an Inspect and Adapt (I&A) event shall be organized where stakeholders and teams work together to inspect the ART's products and decide what should be improved during the next PI.
- Innovation and Planning Iteration This is another event held during each PI to force the train to take some time and dedicate it to innovation, education and I&A so that the presence of urgent tasks doesn't completely prevent all those vital processes from taking place.
- Architectural Runway Having enough Architectural Runway means always having the infrastructure needed to accommodate all the high priority short term changes. Care must be taken not to run out of Architectural Runway or the train might have to slow down considerably while waiting for the infrastructure to be available or working around its limitations.
- Lean-Agile Leadership Leadership must take full responsibility for the adoption of Lean-Agile principles if the organization as a whole is to ever adopt those principles.
[edit] Implementation
The implementation of SAFe is done in three main phases:
- A preparation and planning phase
- A minimum application phase
- An expansion phase
During the first phase, key staff such as managers, leaders and change agents are trained in the SAFe method. ARTs and value streams are identified, and an implementation plan is created. Once this first phase is completed, the second phase starts by preparing for the ART launch and training the teams themselves in the SAFe method, then the first PI planning is organized and the ART is launched. A coaching in the SAFe ways is organized around that first ART, first focusing on the basics of SAFe but going deeper and deeper as the teams become more proficient. Once this first ART has been launched and a coaching team is organized around it, the third phase starts where SAFe is generalized and applied to more aspects of the company: more value streams and ARTs are launched, the method is extended to Portfolio management and the company globally tries to sustain and improve its processes.
[edit] The preparation and planning phase
[edit] Reaching the tipping point
The first phase's goal is to prepare the ground for the company to start using SAFe to manage a program consisting of projects that use Agile methods. This first step is usually taken after what SAFe calls Reaching the tipping point.
Every company tends to resist change in general and in particular to change in its way of working. However, change is sometimes needed and it becomes imperative for the company to achieve the change. In order to achieve such a massive change, it is needed to reach a tipping point where the required critical mass to enable rapid change is reached.[3]
There are two main reasons why companies embrace change.[4] The first is when the need for change is obvious: the performance of the company is dropping and the company needs to change its way of conducting business to survive, while the other is when leadership decided to achieve change proactively, believing implementing such a change will be beneficial for the future of the organization.
[edit] Train Lean-Agile Change Agents
At this point, the need for change has been recognized. A vision for this change must then be established. For an organization working in the Lean-Agile mindset, SAFe is one of the choices available to change their way of working and adapt to their evolving environment. To start preparing the implementation of this method, the first step is to Train Lean-Agile Change Agents.[1] The purpose of this step is to establish a powerful coalition that will drive the implementation of the change throughout the organization.[5]
[edit] Train Executives, Managers, and Leaders
Once change agents have been trained, the next step is to Train Executives, Managers, and Leaders.[1] At its core, SAFe is a method used to manage a collection of projects along the Lean-Agile principles. Therefore, the principal stakeholders will be the program managers but also the project managers who manage the projects in the implicated programs. All those agents must be trained along with their leaders, those who will sponsor the change, and more generally all those who will be influencing or managing this change. This training occurs with the help of the change agents that were trained as part of the previous step.
[edit] Identify Value Streams and ARTs
After all the relevant stakeholders have been properly trained, the next step of the method is to Identify Value Streams and ARTs. This is done by first identifying the value streams: a value stream is basically a series of steps that are taken after some triggers the stream to achieve the production of value. For example, the trigger can be a customer ordering a product, the steps could be ordering raw materials, transforming them into the product that has been ordered, and delivering the product to the customer. The value produced is that of the final product, minus the costs incurred during the value stream. A value stream is of course identified by its trigger, its steps, and its value, but also by the people and systems it involves, as well as the time it takes to execute it.
After having identified the value streams, the organization needs to identify the ARTs that would enable it to execute those value streams as best as possible. An ART, standing for "Agile Release Train" is "a long-lived team of Agile teams, which, along with other stakeholders, incrementally develops, delivers, and where applicable operates, one or more solutions in a value stream."[6] Depending on the value streams identified, each ART can either be responsible for multiple smaller streams, be responsible for a single value stream in its entirety, or collaborate with other ARTs to enable one larger value stream to be operated. The key for choosing how to affect teams to ARTs is that each ART must be designed to be big enough for its responsibilities but small enough to be reactive to its environment (the method recommends 50 to 125 people in each ART), and each ART must have as little dependency on other ARTs as possible, and must be able to release (ie. produce value) independently from other ARTs.
[edit] Create the Implementation Plan
Finally, the last step of this first part is to Create the Implementation Plan. According to Agile principles, incremental value delivery is key for maximum reactivity and adaptability. Therefore at this stage, only one value stream is selected. Once a value stream has been selected, the ART most suitable for executing this stream is selected along with it, and it is time to prepare for the first ART launch.
[edit] The minimum application phase
[edit] Prepare for ART Launch
Now that the implementation plan has been drafted, the next step in the implementation of SAFe is to Prepare for ART launch. During this step the definition of the ART is refined so as to better understand the context in which it will operate, its boundaries, its interactions with other systems, etc.
After this, the launch date and the program calendar are set. The ART operates by cycles called Program Increment (PI), operating on a fixed cadence that can be set to any duration with eight to twelve weeks being recommended. Each PI includes a PI planning sessions at its start and can contain other items such as demos, introspective workshops, etc.
Once this calendar is set, teams are reorganized into Agile teams if necessary, and should include a Scrum Master and a Product Owner along with the team members that directly create the value.
At this point, Scrum Masters, Product Owners and Team managers receive training in SAFe, the launch readiness is evaluated, and once readiness is high enough the program's backlog is established. The program's backlog defines the scope of the Program by defining the various features that are to be developed, the non-functional requirements and the architectural work that define the future behavior of the system.
[edit] Train Teams and Launch the ART
The ART launch has now been defined. The next step at this point is to Train Teams and Launch the ART. At this point, all the team members receive SAFe training and, if necessary, Agile training as well. Each team must also establish its Team Backlog which identifies which features and requirements will be the responsibility of that team. Finally, the ART is launched with the first PI planning session.
[edit] Coach ART Execution
With the first ART having been launched, the preparatory work is now mostly finished and the next step is to Coach ART Execution to support the ART in its first iterations. Initially this coaching focuses on the individual teams to make them master their roles in the overall method. Coaching must also take place at program level, for example regarding PI planning sessions, demos, etc.
[edit] The expansion phase
The expansion phase mostly concerns a transition to large solution SAFe, Portfolio SAFe and Full SAFe which are mostly out of the scope of this article.
[edit] Launch More ARTs and Value Streams
At this point the organization has launched successfully its first ART responsible for a given value stream. Business benefits of the change should start to be measurable, helping to align all the personnel with the vision behind the change. It should now be easier to proceed with the next step: Launch More ARTs and Value Streams. Those ARTs are launched by repeating the steps that were taken to launch the first ART: Prepare for ART Launch, Train Teams and Launch the ART and Coach ART Execution. It is important however to not make the mistake of assuming that everyone already knows the process and skip on applying the same due process that was applied for the first ART.
When no more ARTs are needed for the value stream that was initally chosen, more value streams should also be launched along with one ART, starting over from the Identify Value Streams and ARTs step. Once this value stream and ART have been launched, more ARTs can be launched for that streams until the organization is ready to launch a new value stream, etc.
[edit] Extend to the Portfolio
After the previous step, SAFe has been applied to the whole program, and it is now possible to Extend it to the Portfolio. This is however out of the scope of this article.
[edit] Sustain and improve
Now that SAFe has been properly applied, it is necessary to keep applying it and improve in the use of SAFe. Metrics should be measured and value streams and ARTs reorganized for better value delivery, training and coaching should continue, architecture of the enterprise should be improved and improvement in general should be seeked at all time.
[edit] Limitations
SAFe's limitations pertain mainly to two categories. The first one is that it necessitates a lot of investment in training and coaching, or in the hiring of consultants in order to start applying it[7]. The second one is that it takes away a lot of power from the individual teams in favor of a more centralized approach, which goes against the values of agile methodologies[7]
- Heavy training required
- Less initiative left to the team members, less decision making occurs at the team level contrary to Agile principles
- Longer planning cycles than other methodologies based on Agile principles
- Requires relatively heavy administration, oversight and leadership layers
[edit] Bibliography
SAFe® 4.5 Reference Guide, Scaled Agile, Inc., August 2016
This book is the reference guide to the SAFe method and contains all the basic information one might want to know about how to apply SAFe. It constitutes an ideal reference regarding every SAFe concept and covers all levels of application be it team level, program level, large solution level or portfolio level. Since this book covers all the principles of SAFe, it should probably be read by every person who wish to apply SAFe in their organization.
Gladwell, Malcolm (2000). The Tipping Point: How Little Things Can Make a Big Difference. Little Brown
SAFe implementation relies on the fact that organizations tend to reach a point where change is needed for their futures, and therefore need to reach a tipping point where a critical mass of people is formed that enable massive change. This book discusses in general about those tipping point and how great changes can happen suddenly in the society in general. This is an interesting read for a SAFe practitioner as this tipping point effect is usually needed to apply SAFe in an organization that is already established with their own processes and ways of working.
The Standard for Program Management (2017), Project Management Institute
This book provides detailed knowledge about program management and gives clear information which could be used for most programs. Particularly Chapter 8.2 talks about Program Delivery phase activities. This information can help reader to understand contradictions between usual delivery phase activities as compared to SAFe activities. For example SAFe use close monitoring and frequent checks, which allows to change actions and chosen path if needed. This book enables the reader to understand standard project management methods. This in turn allows him to apply SAFe methods in a more informed way rather than in the dogmatic way someone who only knows about SAFe would behave.
[edit] References
- ↑ 1.0 1.1 1.2 1.3 SAFe® 4.5 Introduction: Overview of the Scaled Agile Framework® for Lean Enterprises, Scaled Agile, Inc., August 2017
- ↑ SAFe® 4.0 Reference Guide, Scaled Agile, Inc., August 2016, page 35 and 43-71
- ↑ Gladwell, Malcolm (2000). The Tipping Point: How Little Things Can Make a Big Difference. Little Brown
- ↑ https://www.scaledagileframework.com/reaching-the-tipping-point/
- ↑ https://www.scaledagileframework.com/train-lean-agile-change-agents/
- ↑ https://www.scaledagileframework.com/agile-release-train/
- ↑ 7.0 7.1 https://www.qasymphony.com/blog/pros-cons-scaled-agile-framework-safe/