Agile Release Train
From apppm
(Difference between revisions)
| Line 4: | Line 4: | ||
== '''The Agile Release Train (ART)''' == | == '''The Agile Release Train (ART)''' == | ||
| − | In the Scaled Agile Framework (SAFe®), the Agile Release Train (ART) is a long-lived team of Agile teams, which, along with other stakeholders, incrementally develops and delivers one or more solutions in a value stream. They organize around value streams and exist to achieve a promised value by building solutions that deliver an expected benefit. Their final purpose is to deliver a continuous flow of value. | + | In the Scaled Agile Framework (SAFe®), the Agile Release Train (ART) is a long-lived team of Agile teams, which, along with other stakeholders, incrementally develops and delivers one or more solutions in a value stream.<ref name="ARTs"> They organize around value streams and exist to achieve a promised value by building solutions that deliver an expected benefit. Their final purpose is to deliver a continuous flow of value. |
ARTs solve one of the most common problems with traditional Agile development, this is teams working on the same solution, operating independently and unaligned, which makes it extremely difficult to integrate full systems. This way, the risk of bypassing problems and late discoveries increases, and in these cases the risk management turns to be difficult and ineffective. Instead, applying cadence and synchronization, ARTs ensure that the system is iterating as a whole organism, focusing on the evolution and assessment of the full system rather than its separate elements. | ARTs solve one of the most common problems with traditional Agile development, this is teams working on the same solution, operating independently and unaligned, which makes it extremely difficult to integrate full systems. This way, the risk of bypassing problems and late discoveries increases, and in these cases the risk management turns to be difficult and ineffective. Instead, applying cadence and synchronization, ARTs ensure that the system is iterating as a whole organism, focusing on the evolution and assessment of the full system rather than its separate elements. | ||
| − | + | ||
| + | == Agile Release Train and Project, Programs and Portfolios == | ||
Organizations address the need for change by creating strategic business initiatives to produce results or change the organization, its products, or its services. Portfolios of programs and projects are the vehicles for delivering these initiatives(reference book). Organizations seek to improve their abilities to deliver benefits and usually these are delivered in the form of business value. Portfolio management allows organizations to define how they will pursue their strategic goals through programs and projects, optimizing the pursuit of business value. Program management seeks to enhance the management of related component projects and programs to improve the generation of business value. Project management seeks to optimize the delivery of business value by improving the efficiency of organizations as they deliver new products, services, or results. | Organizations address the need for change by creating strategic business initiatives to produce results or change the organization, its products, or its services. Portfolios of programs and projects are the vehicles for delivering these initiatives(reference book). Organizations seek to improve their abilities to deliver benefits and usually these are delivered in the form of business value. Portfolio management allows organizations to define how they will pursue their strategic goals through programs and projects, optimizing the pursuit of business value. Program management seeks to enhance the management of related component projects and programs to improve the generation of business value. Project management seeks to optimize the delivery of business value by improving the efficiency of organizations as they deliver new products, services, or results. | ||
In the 3-Level Safe structure, divided into Teams, Programs, and Portfolios, the ARTs are located at the Program level and are defined as a conjunction of Agile teams, synchronized and focused on a specific goal. In the SAFe methodology, a portfolio is considered a sum of value streams, business value goals, called Business Epics are discussed at this level. These epics and visions are then passed to the program level where they are broken down and scheduled on the appropriate ARTs. Each ART is associated with a specific value stream. | In the 3-Level Safe structure, divided into Teams, Programs, and Portfolios, the ARTs are located at the Program level and are defined as a conjunction of Agile teams, synchronized and focused on a specific goal. In the SAFe methodology, a portfolio is considered a sum of value streams, business value goals, called Business Epics are discussed at this level. These epics and visions are then passed to the program level where they are broken down and scheduled on the appropriate ARTs. Each ART is associated with a specific value stream. | ||
| + | |||
== Structured ARTs == | == Structured ARTs == | ||
| + | |||
ARTs operate based on a number of principles which are engraved in the SAFe methodology and align with the Agile manifesto. The key to understanding ARTs is envision them as trains, with a fixed scheduled, tempo and coordinated parts that function as a single organism. The principles, listed below, align to this analogy: | ARTs operate based on a number of principles which are engraved in the SAFe methodology and align with the Agile manifesto. The key to understanding ARTs is envision them as trains, with a fixed scheduled, tempo and coordinated parts that function as a single organism. The principles, listed below, align to this analogy: | ||
| Line 25: | Line 28: | ||
*Develop on Cadence and Release on Demand: ARTs apply a specific rhythm and synchronization to help manage the variability of the projects. However, releasing the final product is usually independent from the development cadence, as ARTs can release a solution at any time as long as it meets the release criteria. | *Develop on Cadence and Release on Demand: ARTs apply a specific rhythm and synchronization to help manage the variability of the projects. However, releasing the final product is usually independent from the development cadence, as ARTs can release a solution at any time as long as it meets the release criteria. | ||
| − | == | + | |
| + | == Differences from traditional structures == | ||
| + | |||
The way ARTs are organized differs from traditional functional units, while there are advantages to these functional units, the value doesn’t flow quickly as it has to cross through the different units and levels. Therefore, it is necessary to have close control from the managers to move the work across and as a result, progress is slow. Instead, ART applies systems thinking and it organizes around value to build a cross-functional organization. This structure helps the flow of value from ideation through deployment, release, and into operations. | The way ARTs are organized differs from traditional functional units, while there are advantages to these functional units, the value doesn’t flow quickly as it has to cross through the different units and levels. Therefore, it is necessary to have close control from the managers to move the work across and as a result, progress is slow. Instead, ART applies systems thinking and it organizes around value to build a cross-functional organization. This structure helps the flow of value from ideation through deployment, release, and into operations. | ||
The ART, as a cross-functional organization, has all the people required to define, deliver, and operate the solution. This creates a far leaner structure, where daily task controls and project management are not necessarily required. This improves the flow of value with a minimum of control. | The ART, as a cross-functional organization, has all the people required to define, deliver, and operate the solution. This creates a far leaner structure, where daily task controls and project management are not necessarily required. This improves the flow of value with a minimum of control. | ||
| + | |||
== Solution Train == | == Solution Train == | ||
| + | |||
When a needed solution becomes too big and too complex it needs a conjunction of ARTs to achieve it. A Solution Train organizes and coordinates multiple ARTs into one, coordinating hundreds of individuals towards accomplishing a common mission. According to the SAFe methodology, Solution Trains are “organizational constructs used to build large and complex solutions that require the coordination of multiple Agile Release Trains (ARTs)” (reference). In terms of the 3 Level Structure mentioned before, Solution Trains are an amalgamation of programmes with a shared strategic goal, in other words a portfolio. They are useful to focus ARTs with a shared mission and synchronise and align the objectives, allowing adaptable changes even when large solutions are being built. | When a needed solution becomes too big and too complex it needs a conjunction of ARTs to achieve it. A Solution Train organizes and coordinates multiple ARTs into one, coordinating hundreds of individuals towards accomplishing a common mission. According to the SAFe methodology, Solution Trains are “organizational constructs used to build large and complex solutions that require the coordination of multiple Agile Release Trains (ARTs)” (reference). In terms of the 3 Level Structure mentioned before, Solution Trains are an amalgamation of programmes with a shared strategic goal, in other words a portfolio. They are useful to focus ARTs with a shared mission and synchronise and align the objectives, allowing adaptable changes even when large solutions are being built. | ||
| + | |||
== ART process == | == ART process == | ||
| + | |||
As mentioned before, ARTs are formed to continuously deliver value to customers. This is achieved using a Continuous Delivery Pipeline, which contains the workflows and activities needed to support the release of new products. Each ART builds and maintains a pipeline with the assets needed to deliver solution value as independently as possible. | As mentioned before, ARTs are formed to continuously deliver value to customers. This is achieved using a Continuous Delivery Pipeline, which contains the workflows and activities needed to support the release of new products. Each ART builds and maintains a pipeline with the assets needed to deliver solution value as independently as possible. | ||
As shown in the picture, the first three elements of the pipeline work together to support the deployment of small batches of new functionality, which are released to meet market demands. Continuous Exploration is the process of exploring the user needs and defining the set of hypotheses to address those needs. It is followed by Continuous Integration which is the process of taking features from the program backlog and developing, testing, integrating, and validating them in a staging environment where they are ready for deployment and release. Then continues to Continuous Deployment where the teams take validated features and deploy them into the production environment, where they’re tested and ready for release. The final element, Release on Demand which is the process of making the value available to the end-user, measuring and learning from the results of the hypotheses, and operating the solutions. | As shown in the picture, the first three elements of the pipeline work together to support the deployment of small batches of new functionality, which are released to meet market demands. Continuous Exploration is the process of exploring the user needs and defining the set of hypotheses to address those needs. It is followed by Continuous Integration which is the process of taking features from the program backlog and developing, testing, integrating, and validating them in a staging environment where they are ready for deployment and release. Then continues to Continuous Deployment where the teams take validated features and deploy them into the production environment, where they’re tested and ready for release. The final element, Release on Demand which is the process of making the value available to the end-user, measuring and learning from the results of the hypotheses, and operating the solutions. | ||
| + | |||
== '''How to apply ARTs?''' == | == '''How to apply ARTs?''' == | ||
| − | Defining the ART is one of the | + | |
| + | Defining the ART is one of the steps in the SAFe implementation plan. In the planning stage, ARTs are identified and outlined with scarce details, this stage is useful to identify potential ARTs. The parameters and boundaries of these potential ARTs, their stakeholders, and their relationship to the value streams can be captured and summarized in the ‘ART canvas’ (figure). | ||
[[File:ART_Canvas.jpg|upright=2.0|]] | [[File:ART_Canvas.jpg|upright=2.0|]] | ||
| Line 49: | Line 60: | ||
A key benefit of the canvas is to help identify the principal roles since ARTs only work when the right people are assigned the correct tasks. All the necessary responsibilities have to be accomplished for the system to function properly. Using the canvas and registering the key roles easies these discussions and highlights new responsibilities. | A key benefit of the canvas is to help identify the principal roles since ARTs only work when the right people are assigned the correct tasks. All the necessary responsibilities have to be accomplished for the system to function properly. Using the canvas and registering the key roles easies these discussions and highlights new responsibilities. | ||
| + | |||
== Implementation process == | == Implementation process == | ||
| Line 78: | Line 90: | ||
*Smaller value streams can be implemented by a single ART | *Smaller value streams can be implemented by a single ART | ||
*A larger value stream must be supported by multiple ARTs | *A larger value stream must be supported by multiple ARTs | ||
| + | |||
== Designing ARTs == | == Designing ARTs == | ||
| + | |||
When designing the ARTs is important to keep in mind that several roles need to be present to ensure a successful execution. These roles are listed below: | When designing the ARTs is important to keep in mind that several roles need to be present to ensure a successful execution. These roles are listed below: | ||
| Line 95: | Line 109: | ||
*Platform team: organized around the development and support of platforms that provide services to other teams. | *Platform team: organized around the development and support of platforms that provide services to other teams. | ||
*Enabling team: is organized to assist other teams with specialized capabilities and help them become proficient in new technologies. | *Enabling team: is organized to assist other teams with specialized capabilities and help them become proficient in new technologies. | ||
| + | |||
== '''ART Limitations and challenges''' == | == '''ART Limitations and challenges''' == | ||
| + | |||
As part of the SAFe methodology, ARTs share some of the same limitations. For instance, defining concepts and terms, the bibliography available explains the basic concepts correctly, but while applying them outside their specific framework organizations soon run out of guidance. It is also important to mention that balancing the organizational structure with the SAFe framework can become challenging when dealing with industry changes and trying to maintain competitiveness. ART limitations can be related to the complexity of the structures or the amount of workload needed to start and define the trains. Secondly, the fact that SAFe emphasizes the big picture can often lead to longer planning cycles and more fixed roles within development cycles which opposes the continuous value flow dogma. Furthermore, challenges related to defining and structuring the organization around value streams have been reported as well as struggles with handling cross-team dependencies between ARTs and integrating teams with less dependencies into ARTs. | As part of the SAFe methodology, ARTs share some of the same limitations. For instance, defining concepts and terms, the bibliography available explains the basic concepts correctly, but while applying them outside their specific framework organizations soon run out of guidance. It is also important to mention that balancing the organizational structure with the SAFe framework can become challenging when dealing with industry changes and trying to maintain competitiveness. ART limitations can be related to the complexity of the structures or the amount of workload needed to start and define the trains. Secondly, the fact that SAFe emphasizes the big picture can often lead to longer planning cycles and more fixed roles within development cycles which opposes the continuous value flow dogma. Furthermore, challenges related to defining and structuring the organization around value streams have been reported as well as struggles with handling cross-team dependencies between ARTs and integrating teams with less dependencies into ARTs. | ||
Revision as of 20:18, 28 February 2021
Abtract
In order to align the different teams on an equal mission, as a part of the Agile Methodology, they are organized in an Agile Release Train (ART). The ART team organization is based on a long-lived combination of Agile Teams, formed to develop and deliver one or more solutions as part of a value stream. ARTs operate based on a set of common principles of SaFe such as fixed schedules, programmed incremented schedules, and agile dedicated teams. Opposite to functional organization, ARTs focus on value forming cross-functional teams. Each team has everything it needs to define, deliver, and operate solutions and every team has well-defined responsibilities that are based on the team type. To simplify the team design it is possible to apply SaFe four fundamental team topologies, where each of them is organized around a specific set of responsibilities. The challenges that arise at the time of forming an ART are related to defining and structuring the organization around value streams, handling cross-team dependencies between ARTs, and integrating teams with fewer dependencies into ARTs.
The Agile Release Train (ART)
In the Scaled Agile Framework (SAFe®), the Agile Release Train (ART) is a long-lived team of Agile teams, which, along with other stakeholders, incrementally develops and delivers one or more solutions in a value stream.[1]
Cite error:
<ref> tags exist, but no <references/> tag was found
