OLYMPUS DIGITAL CAMERA

Most Agile frameworks are built on the basis empirical models of process control. These, in turn, are based on periodic observation and adaptation. Each instantiation of the process may be different due to the circumstances any specific team faces. The empirical mode is often compared to the defined process approach, which posits a standard process for all teams that evolves based on the needs of the collective whole rather than a team or small group of teams. Scaled Agile Framework Enterprise (SAFe) program increments are no different. Program increments are similar to a large Scrum sprint beginning with planning and completing with a demonstration and retrospective, known as inspect and adapt. The empirical process of inspect and adapt is one of the core principles in SAFe. At the team level, each sprint culminates with the classic demonstration and retrospective. The same type of discipline is leveraged for program increments. PI level inspect and adapt is composed of three components:

  1. The teams involved in the program increment demonstrate the system with the new features, architectural changes and non-functional requirements that have been completed during the PI. The goal of the demonstration is to evoke feedback based on the overall current status of the overall application from the Agile release train (ART) stakeholders.
  2. Metrics Review. Program metrics are reviewed and discussed as a team. The goal of the metrics review and the ensuing discussion is to ensure that everyone involved understands performance based on tactical experience and measured performance. The combination of experience and measurement helps the team see through their individual cognitive biases.
  3. Retrospective/Problem Solving Workshop. The problem solving workshop provides a platform for the PI participants to first identify the issues experienced during the increment, then to identify which of those that they would like to solve and finally to develop a corrective action plan. SAFe recommends that a structured, root cause analysis is used to analyze the issue and define a corrective action plan (the preferred method uses the “five whys” and Ishikawa Diagrams/Fishbone diagrams – both of these are tried and true techniques used in the quality and process improvement arena). The goal of the process is to generate tangible improvement actions that can be taken into the release planning event for the next program increment.

The inspect and adapt process in SAFe is a means of generating feedback on the product that is being developed and the processes being used to do the work. Feedback is a means of ensuring the Agile release train stays on track. Inspect and Adapt provide feedback so that changes can be made the trajectory of the product being build and to make changes in how work is being done.

Lots of varied roles!

SAFe’s release planning event is has been considered both the antithesis of Agile and the secret sauce for scaling Agile to programs and the enterprise. The process is fairly simple, albeit formal. Everyone involved with a program increment (an 8 – 12 week segment of an Agile release train) get together and synchronize on the program increment objectives, plan and then commit to the plan. Who is the “everybody” in a release planning event? The primary participants include:

  1. The Scrum Teams.   Release trains are typically comprised of 50 – 125 people with Scrum teams of 5 – 9 people comprising the lion’s share. Scrum teams are comprised of a Scrum master, product owner and technical personnel. The teams plan, identify risks and dependencies, share knowledge and commit to the plan.
  2. Release Train Engineer. The RTE facilitates the release planning meeting. The RTE is often called the Scrum master of Scrum masters. I have also heard the RTE called a cat herder.
  3. Product Management. Product management provides the vision for the program increment. They interpret the product roadmap and program epics providing direction.
  4. Business Owners. Business owners are the voice of the business. They interact with the teams in the ART to influence and generate an alignment between the program-level program increment objectives and the individual team-level program increment objectives.

Others that are involved include:

  1. CTO, Enterprise Architect and System Architect. These roles provide the architectural vision and an assessment of the Agile environment including changes since the beginning of the last program increment.
  2. Customer Representatives. Customer representatives are an adjunct to the product management personal providing interpretation of the vision.
  3. Release Managers. Release managers assist in planning, managing governing releases. The release manager may be involved in several ARTs.
  4. Engineering Development Managers. The development managers responsible for the applications involved in the release train need to be aware and provide support and knowledge capital to help ensure success.
  5. Tech Lead and Representative Team Members, Developers, QA/Test, Documentation, etc. Representatives from groups the ART must interface with during the program increment need to participate and have decision making power to commit personnel and resources needed to support the ART.
  6. VPs and Executives Responsible for Product Strategy, Delivery and/or other Affected Operations. Anyone that would typically need to review, provide support or resources or approve a plan or direction should be at hand during the release planning event.

It has been said that it takes a village to raise a child. It takes an equally complex number of roles and participants to plan and then generate commitment to that plan.

OLYMPUS DIGITAL CAMERA

The release planning event in the Scaled Agile Framework Enterprise (SAFe) is a two-day program-level planning event that focuses the efforts of a group of teams to pursue a common vision and mission. As we have noted, the event includes participation by everyone involved in the Agile release train (ART), participation is in-person (if humanly possible), occurs every 8 – 12 weeks and has a formal structured agenda.   The agenda has five major components:

  1. Synchronization.  This component seeks to get everyone involved in the ART on the same page in terms of:
    1. Business Context
    2. Product Vision
    3. Architectural Vision
    4. Technical Environment and Standards

Each of these subcomponents provide the team with an understanding of what they are being asked to do and the environment they are being asked to operate within. The flow begins by grounding the team the business context for the program increment (the 8 -12 weeks). Each step after the business context increased in technical detail.

  1. Draft Planning. Leveraging the context, vision, architecture and environmental standards, the teams develop a draft plan. We will explore the process in greater detail in a later essay, however this where the team breakdown the stories they will tackle during the program increment, breaks them down, exposes risks and identifies and minimizes dependencies.   Draft planning usually consumes the second half of the day. The Release Train Engineer will gather the scrum masters together periodically during the draft planning process to ensure teams are sharing dependencies and understand the direction each is heading.
  2. Management Review and Problem Solving. At the end of draft planning, any significant problems with the scope of the program increment, staffing or other resource constraints are generally apparent. After the majority of team has completed their work for the day the management team (including RTE and scrum masters) meets to share what was learned and make the decisions needed to adjust to the constraints. This is must be completed before the beginning of day two.
  3. Final Planning. The teams review the adjustments made during the during the management review the previous evening as a whole group and then break out into teams again to continue planning converting the draft plans into final(ish) plans. Plans are finalized when they are accepted by the business owners.
  4. Review, Re-planning and Acceptance. When the teams plans are finalized they are reviewed by the whole team, the risks are ROAMed, the whole team votes on acceptance (a form of peer review and acceptance), any rework is performed on the plan and finally a retrospective is performed and next steps identified.

The release planning meeting operationalizes a program increment. A program increment represents 8 – 12 week planning horizon within a larger Agile Release Train. The large scale planning event helps keep all of the teams involved in the ART synchronized. The release planning meeting might be SAFe’s special sauce.

If you're running at a different cadence, someone is always falling behind.

If you’re running at a different cadence, someone is always falling behind.

The Scaled Agile Framework Enterprise (SAFe) uses the concept of a hierarchy to translate business strategy and needs to the work a Scrum team does on a daily basis. The hierarchy begins with value streams that are actualized by agile release trains (ART). ARTs are a long lived team of teams this is organized to deliver the support the value stream. While the value stream provides a goal and the ART the long term vehicle for the that support additional structure is needed before teams are set loose. As anyone that has watched teams interact knows, without structure shenanigans will ensue. The program increment provides a structure to connect the long term vision and the scrum teams. Program increments are similar to sprints, but at higher level.

The scrum teams within an ART use sprint cadence as a synchronization and motivational tool to develop solutions in a coordinated manner. Cadence provides short feedback cycles that provide focus. Program increments aggregate a fixed number of sprints together to peruse a common theme or goal such as a group of related features that might comprise one or more releases. The program increment process provides a framework to synchronize planning and development through group planning, group demonstrations and larger scale retrospectives. The program increment functions in much the same manner as the Sprint in Scrum. Here are the attributes of a program increment:

  1. Time-bound planning cycle. Program increments are typically 8 – 12 weeks, four two-week or three-week sprints.
  2. Common theme/goal. The program increment acts a container to focus development on the features and functions needed to deliver common theme or goal. The program increment and release plan do not have to synchronize. Using an example of a hypothetical customer facing website. A program increment could be focused of developing an integrated shopping cart solution with releases being made during the 8 – 12 weeks as major components reach done.  The mantra of SAFe and Agile development is, “develop to cadence, release on demand.” Said more bluntly, develop using sprints and program increments to provide cadence and synchronization and be ready to release when the business needs the functionality.
  3. Ceremonies demarcate program increments. Much like sprint planning and demonstrations and retrospectives mark the beginning and the ending of a sprint, program increments are bounded by ceremonies. The release planning meeting marks the beginning of the program increment and the “inspect and adapt cycle” marks the outer boundary.

A program increment is a time-boxed container with a common theme or goal that helps the multiple teams involved in an ART to stay synchronized. Teams further enhance their synchronicity by integrating frequently, participating in Scrum of Scrums, management dependencies as well as team and system-level demonstration. The duration of the program increment is often syncronized to release schedules and plan, however the two concepts do not have to be synonymous. Agile development is about building implementable functionality every sprint, the macro cadence of the program increment allows that functionality to be bundled into features which can be released as planned or as needed.

The Release Train Engineer is part of the crew that guides the train.

The Release Train Engineer is part of the crew that guides the train.

As groups of coordinated work get larger the tools, techniques and roles needed to keep the work coordinated expand. Complexity requires more controls to keep the train on the tracks. The Release Train Engineer (RTE) is one of the techniques the Scaled Agile Framework Enterprise (SAFe) uses to keep the 50 to 125 cars (number of people in an Agile Release Train or ART) on the track. Formally RTE is a scaled scrum master, however practically the role tends to take on a broader footprint. It could be viewed as a mixture of Scrum master and program leader. The roles and responsibilities of a RTE include:

  • Provides guidance to the release train. While the ART and the teams that are part of the train are predominately self-managing and self-organizing, the RTE provides guidance to help teams adapt to the environment.
  • Organizes, runs and facilitates the release planning meeting. The release planning meeting  is a two day meeting that includes all of the people involved with the ART. The meeting is crucial meeting that kicks-off and drives each program increment.
  • Assists in tracking the ART. In many organizations tracking and reporting fall on the shoulders of the RTE. The function is better placed in a Program Management Office with the RTE providing assistance. Let the RTE focus on facilitating and leading rather than on owning standard administration tasks.
  • Chairs the scrum of scrums (SoS). As a leader and the scrum master of scrum masters, the RTE is perfectly positioned to ensure that teams interact and share cross-team issues and risks by facilitating the SoS.
  • Resolves and/or escalates impediments. Scrum masters facilitate the resolution of impediments within their span of influence. Once an impediment is outside of a scrum master’s span of influence the RTE steps in to remove or escalate the impediment to someone that can remove the impediment.
  • Facilitates intergroup communication and dependency resolution. Much of the role of the RTE is facilitating communication between groups. In a perfect world all teams would have the proper understanding of what was going on in other teams that they could impact or could impact them, however many times the environment precludes that possibility. The RTE helps to keep information moving so that the teams can focus on delivery.
  • Facilitates process improvement at the ART level. While teams pursue improvements based on retrospectives, the RTE facilitates ensuring the overall processes are continually being refined. An example of one of process improvement events that the RTE leads is the retrospective that caps the release planning meeting.
  • Cajoles, leads and In general, helps make stuff happen. All leaders use their social influence to attain a goal. RTE’s are no different. SAFe (and most other frameworks) use goals that can be traced from business value to the work a team delivers. Work in ALL organizations is goal oriented. Leaders help everyone involved focus on those goals.

The release train engineer has a hand on the throttle of the agile release train, but just like the engineer on the freight train they are only one part of the process that that decides speed and direction. Locomotive engineers inspect their trains, monitor performance, communicate and interact with team members and passengers. They support getting the train to its appointed destination not only on-time but safely.

A value stream is a set of activities that are intended to create and deliver a consistent set of deliverables that are of value to customers. Using the train metaphor, value is the cargo the train delivers.

A value stream is a set of activities that are intended to create and deliver a consistent set of deliverables that are of value to customers. Using the train metaphor, value is the cargo the train delivers.

The Agile Release Train (ART) in SAFe is the primary high-level tool used to organize activity to deliver value. Other frameworks (Agile and classic) use projects and programs to organize around the delivery of value and value’s alter ego, funding. ARTs are used to deliver, enhance and support the functionality needed for business facing value streams to exist within an organization.

A value stream is a set of activities that are intended to create and deliver a consistent set of deliverables that are of value to customers. Using the train metaphor, value is the cargo the train delivers. The term consistent in the definition is important to delineate an ART from a typical project or program. The Project Management Institute defines a project as a temporary group activity designed to produce a unique product, service or result. A project or program might initiate or support a value stream in a non-scaled Agile organization, however the focus is on a temporary endeavor rather than on support an ongoing or consistent endeavor. The long-term focus makes it significantly easier to embrace Agile principles.

Value streams reflect a business orientation that integrate strategic themes and needs into how an organization delivers value. The products and services of most organizations tend to be long lived, therefore value streams have the same long-term orientation. SAFe ARTs organize activity around value streams. In practice a value stream in an organization can be large enough to support multiple ARTs. A value stream is a requirement for an ART whether the ART develops a new value stream, enhances or supports an existing value stream, without access to business value it hard to generate strategic alignment within the organization. When ARTs (or any significant part of an organization) are out of strategic alignment, support in terms of budget, people and resources will be difficult to acquire. This will lead to disillusionment with the ART. Using our train metaphor, the engines, train cars and crew will be dispersed to other trains. Without strategic alignment an organization will not be able to support the structure of an ART and stable teams that are needed.

Value streams present the whole path an organization takes to deliver value. The phrase “concept to cash” is often used describe the breadth of vision that a value stream must have. Value stream taking the big picture takes a on a whole business context rather than purely a software development project or programs. To adjust to the breadth of vision ARTs need to incorporate the needs of business process, architecture, systems as well as application software. Agile release chains make sense as long as they serve a real value chain.

3466780657_aec63156b8_b (1)

The Scaled Agile Framework Enterprise (SAFe) is one of the frameworks that has emerged for scaling Agile development. The Agile Release Train (ART) is one of the core concepts introduced as part of the SAFe framework. An ART is a group of logically related effort (train cars) traveling in the same direction (destination) at predictable cadence (speed). At its heart, most everyone on a train is focused on achieving a common goal, which is delivering all types of cargo to a destination. The ART in SAFe is a long-lived team of teams organized around a significant value stream to work towards delivering a common goal. The attributes of an ART interlock to keep it on track to delivering value by ensuring it adheres ot Agile and lean principles.  An ART has the following attributes:

  1. Team of Teams within and ART typically encompass 50 to 125 people. The size limits are a reflection that large groups have issues with communication and cohesion which is problematic when pursuing a common goal and smaller groups have issues absorbing the process overheard which makes development expensive.
  2. ART teams identify and use additional roles not typically found in some Agile frameworks, such as the Release Train Engineer, release managers product management, DevOps and share resources, to name a few.
  3. Teams work with the ART on a long-term basis, 18+ months.
  4. The majority of team members are 100% dedicated to the teams they are involved with.
  5. ARTs are driven by business goals based on the organizations strategic vision and themes, portfolio management constraints and enterprise architectural vision.
  6. ARTs are operationalized and synchronized by cadence at two levels. At a macro level, ARTs leverage a longer cycle cadence called a product increment, which is generally 8 -12 weeks and a shorter Scrum team-level cadence (two weeks is typical).

The Agile Release Train is a tool to help scale Agile to the organizational/product. Conceptually the ART is similar to the operating system (OS) release trains I was first exposed to in the 1990’s. The OS manufacturer and every product manufacturer I have observed from automobile to ATM manufacturer plans the introduction of features over some period of time. An ART provides a mechanism to translate that plan into Agile teams so that organizations can communicate a forecast for the delivery of features to stakeholders and customers. Some degree of predictability is critical if other businesses or parts of a business need to use your input so they can plan their business. Real profits and jobs usually ride on those release trains.

Other frameworks can be used to scale Agile, including DAD, DSDM and arguably Scrum itself. The need for frameworks with additional overheard to scale Agile is controversial. Whether you are an adherent of scaled frameworks or not is less important than having understanding the solutions these frameworks deliver. An Agile Release Train is a tool to organize activity to deliver a common business goal while being both predictable and reacting to the dynamic business environment. At its most basic level isn’t that just a definition of Agile?