9
Events for the Train
The ART executes events in the same fashion the Agile team does, only at scale. ART events are slightly different from team events. Let’s look at the various activities and events that occur in each iteration and throughout the PI for an ART, including all the syncs, the ART Board, and the Iteration System Demo.
In this chapter, we’ll look at the following topics:
- The Syncs
- Don’t skip the ART Board
- Iteration System Demo
The Syncs
The equivalent of a Team Sync for the ART is the ART Sync. Depending on the ART, it may take various formats. The outcome is always alignment, impediment removal/escalation, and risk management.
SAFe® outlines three different sync events for the ART:
- The Coach Sync
- The Product Owner (PO) Sync
- The ART Sync
We will provide two additional syncs your ART may want to consider:
- A Technical Sync
- A Troika Sync
Coach Sync
The Coach Sync is a cadence-based event for the Release Train Engineer (RTE), Scrum Masters/Team Coaches, and selected Agile Team members or SMEs to align and continuously work to improve ART and team performance.
The RTE typically facilitates this event. All the Scrum Masters/Team Coaches should be present. Since this is the scaled version of the Team Sync, you will often find the event executed in a round-robin format and that the Scrum Masters/Team Coaches and RTE will answer these (or similar) questions:
- What has your team last accomplished since we last met?
- What will your team be working on until we meet again?
- Are there any impediments in your team’s way?
- Will your team be putting anything in another team’s way?
Pro tip
My favorite question, and one that I sometimes incorporate into the Team Sync, is “Will you be putting anything in someone else’s way?” Often, we are so worried about getting our work done that we don’t think about its impact on anyone else. This question can help teams to understand that they are part of the bigger picture and the impact of the work they are doing.
I don’t typically recommend introducing this question to new teams for their Team Syncs. I do, however, like to ask this question during the Coach Sync to help the Scrum Masters/Team Coaches begin to think about the impact they have and to ensure they are thinking about what information they need to provide to other teams.
In addition to discussing the work that the teams are doing, consider spending some time to share successes and failures in the growth and maturity of the team and as a Scrum Master/Team Coach.
The event is typically 30 to 60 minutes in length, depending on any post-meeting items, other syncs that occur, and the needs of the ART. A successful pattern is to hold this event once per week, which is twice per iteration; however, it can be more frequent if needed.
The RTE is responsible for communicating any major blockers or impediments to the appropriate Stakeholders after the meeting and resolving them, and the Scrum Master/Team Coach is responsible for communicating information to the teams.
We achieve alignment by ensuring that we are all working toward the goals of the ART. We improve the ART and team performance by sharing learning and experiences from working with the teams and the interpersonal dynamics within them.
PO Sync
The PO Sync is similar to the Coach Sync. It’s a cadence-based event for the Product Owners (POs) and Product Management to maintain alignment and to drive the value being delivered by the ART forward.
The RTE or Product Management may facilitate this meeting; however, ARTs are more successful when the PO Sync is owned and facilitated by Product Management. All the POs should be present. There is no prescriptive format for this meeting, and like the Coach Sync, you may find success with a round-robin format with the following questions:
- What Features has the team completed since we last met?
- What Features does the team expect to complete before we meet again?
- Is the team on track to deliver the Features as planned during PI Planning?
- Are there any impediments in the team’s way?
Ultimately, we are trying to determine how the teams are doing in their progress to meet the PI Objectives and commitments. In addition to discussing the work the teams are executing, this is a prime opportunity for the Product Team (Product Management and POs) to do the following:
- Discuss and make any adjustments to Features
- Acknowledge any market rhythm adjustments
- Work on ART Backlog refinement in preparation for the next PI
- Share additional customer feedback
- Clarify and refine the Acceptance Criteria for upcoming stories
This event is typically 30 to 60 minutes in length, depending on the other syncs that are occurring and the needs and maturity of the ART and Product Teams.
Pro tip
It is often a challenge for Product Management to ensure ART Backlog refinement occurs regularly. Consider scheduling the PO Sync every week for 1 hour for Product Managers and POs to work together in refinement.
You may want to consider inviting the System Architect to these sessions for feedback and input into the ART backlog.
ART Sync
The ART Sync may be used in lieu of the Coach Sync and the PO Sync, depending on the needs and maturity of the ART. The ART Sync is a combined Coach Sync and PO Sync. The System Architect also attends this event, in addition to Product Management, the POs, and Scrum Masters/Team Coaches. This cadence-based event is used to ensure the ART is staying on track.
The RTE typically facilitates this event; the PO and Scrum Master/Team Coach pairs will provide updates on the progress of their teams by answering variants of the following questions:
- What progress has your team made since we last met?
- What progress do you expect your team to make before we next meet?
- Are there any impediments in the team’s way?
- Will your team be putting anything in another team’s way?
Depending on your ART and what ART iteration events you use, you may want to clarify the questions to ask specifically about PI Objectives or Features.
As with the PO Sync and the Coach Sync, we are ultimately trying to determine whether the ART is on track to deliver its commitments. This event is a great opportunity to look at the ART Board as well as to review the risks identified during PI Planning.
Pro tip
Pull up the ART Board and review the Team and ART PI Objectives and risks at the ART Sync.
Typically, this event is 30-60 minutes long, depending on post-meeting discussions. If you are only holding the ART Sync, we recommend holding this event weekly; however, if combined with a PO Sync and Coach Sync, once per iteration is usually sufficient for ongoing alignment, depending on the maturity and needs of your ART.
Pro tip
The one aspect to note in an ART Sync that varies from the PO Sync and Coach Sync is that the timebox typically doesn’t allow for continuous learning and improvement. In the Coach Sync, we try to spend some time growing the teams. In the PO Sync, we are afforded the opportunity to prioritize and refine the ART backlog. The ART Sync, due to the number of attendees, typically lacks that opportunity, with general announcements taking precedence.
Figure 9.1 shows how the ART, PO, and Coach Syncs complement one another:
Figure 9.1 – ART, Coach, and PO Syncs (© Scaled Agile, Inc.)
The Technical Sync
The Technical Sync isn’t outlined by SAFe®; however, it can be a very valuable addition to help keep the ART aligned. The Technical Sync is like the Coach Sync or PO Sync, but builds alignment from an architecture, engineering, and development perspective.
The RTE or the System Architect may facilitate this meeting; however, ARTs are more successful when the Technical Sync is owned and facilitated by the System Architect. The attendees can be a bit tricky to identify as SAFe® doesn’t specify a technical lead role in the teams. However, what we typically find within most teams is a senior technical person that often helps guide and informally leads the team’s development. This is the recommended attendee from each team. If there isn’t a lead on the team, you can also rotate the attendees and, eventually, you will find that someone will self-identify as a regular attendee.
At the Technical Sync, the attendees can answer variations of the following questions:
- How is your team progressing with delivering its commitments?
- Are there any impediments in the team’s way?
- Will your teams be putting anything in another team’s way?
During the Technical Sync, the outcome is to learn about challenges and gain alignment within the technical domain of the solution we are building. Many developers are introverts by nature and being at this event among their peers is an opportunity to raise what may seem to be insignificant issues in the grand scheme of things, but that can have a significant impact over time.
At this event, we often learn about challenges with the following:
- Development and testing environments
- The DevOps pipeline
- Test automation issues
- Deployment constraints
- Delays in the system
Story from the real world
I once worked with an ART, and it was during one of the Technical Syncs that the developers mentioned that it was taking a long time for the builds to complete. The others agreed, but it was considered normal.
Fortunately, the System Architect was astute and asked a few follow-up questions:
How long is a long time?
Is this happening for every build?
How frequently, on average, would you say you do a build?
It turned out that every build was taking between 5 and 7 minutes to complete and the average developer would run a build 3 times an hour. This meant that approximately one-third of every hour was lost. That’s significantly wasteful overhead. It was also noted that the developers would like to build more frequently but often avoided it due to how long it would take.
They began investigating why the builds were taking so long, were able to make some adjustments within the environments, and were able to reduce the build time to under 30 seconds. This allowed the developers to build more frequently, and it ultimately improved the velocity of the teams.
The Technical Sync is typically 30-60 minutes in length. Allow the team to determine the frequency of this event; we recommend at least once per iteration.
Pro tip
For new ARTs, I recommend holding all syncs: the PO Sync, Coach Sync, and Technical Sync. I find that this helps communication and helps with role alignment. Eventually, you can reduce or adjust the events as the teams and the ART mature by leveraging the ART Sync.
The Troika Sync
The Troika Sync is also not outlined by SAFe®. This is simply a regular synchronization point and discussion to ensure alignment between the RTE, Product Management, and System Architect. It’s an opportunity to compare notes on what they are hearing in their respective areas and to ensure alignment on messaging.
The agenda for this meeting typically revolves around the current challenges of the ART and a look ahead toward the next PI.
The RTE usually facilitates and schedules this sync, and it typically runs for between 30 and 60 minutes. This should occur as frequently as is needed, even daily. Many issues will come up that need to be addressed, and having a regular daily touchpoint to resolve issues and address challenges will help the overall health of the ART and establish regular communication channels.
Release Management Sync
SAFe® mentions that a Release Management Sync may be necessary to coordinate upcoming releases, communicate about the releases, and ensure governance requirements are met. How this meeting is structured, its frequency, participants, and so on will be unique to each ART depending on what is being built. Use the System Team to drive this sync.
Scheduling the Syncs
The RTE typically schedules the syncs. Product Management and the System Architect usually own and facilitate the PO and Technical Syncs respectively; however, coordinating the schedule of the activities is important.
Here is an example schedule for your consideration. Adjust it to fit your ART needs:
|
Wednesday |
Thursday |
Friday |
Monday |
Tuesday | |
|
Week 1 |
Iteration Planning |
PO Sync Coach Sync Technical Sync |
Troika Sync |
ART Sync |
Troika Sync |
|
Week 2 |
PO Sync Coach Sync Technical Sync |
Troika Sync |
ART Sync |
Troika Sync |
Iteration Review Iteration Retrospectives |
Table 9.1 – Example sync schedule
In the schedule, you will notice that the PO Sync, Coach Sync, and Technical Sync are all held on the same day. You may even want to consider holding them at the same time.
We recommend placing the ART Syncs mid-way and toward the end of the iteration. This allows the teams a few days to dive into the work and then provides a checkpoint toward the end of the iteration to address any areas where work may not get completed and whether the team needs to pull in additional work to be completed in the iteration.
Pro tip
There is no “correct” way to structure and schedule your ART’s various sync meetings. It’s more of an art than a science, no pun intended. Every ART has unique needs and challenges. That’s why SAFe® isn’t a textbook, but a framework. What works best for one ART might not work for another, even in the same company.
As a Coach, be sure to be flexible; however, also ensure that your ART is delivering the outcomes for success by ensuring the syncs are happening and that you are getting the necessary alignment and maturity from them.
Bonus Sync Recommendations
Now that we understand the key syncs for an ART, let’s take a look at a few more items that we want to ensure are covered in the syncs.
Do we need all these Syncs?
The simple answer is no, you don’t need all these syncs. However, each of these syncs does serve a purpose and helps with communication and the alignment of the ART. Use the syncs that your ART needs. You may also find that these meetings are occurring anyway, and these syncs become a way to formalize, operationalize, or even eliminate the extra meetings.
PI Objectives
Remember our goal is to deliver our PI Objectives; ensure that doesn’t get lost in the sync meetings and that there are regular discussions on progress toward meeting the objectives.
Impediment Escalation
One watchpoint is that people will wait until a sync to escalate impediments. Having numerous syncs can help to prevent that from occurring. Our goal is for impediments to be resolved or raised as quickly as possible. As a Coach, you can help ensure that immediate impediment escalation and removal are occurring.
Not a status meeting
One key watchpoint is that these sync meetings don’t become status meetings. If you find that is happening, consider holding a retrospective and reviewing the intended outcome of the event with the group.
Iteration Goals
One item you might want to introduce during syncs early in the iteration is sharing the iteration goals that the team creates. Sharing them can help build alignment and provide a simple way for the teams to know what each other is focused on.
Taking it back to the teams
You will want to remind the sync attendees of their responsibility to take information from the syncs back to the teams. This is often overlooked, and information only flows up and doesn’t always make it back down. The syncs are an intersection, with information needing to flow in multiple directions.
Don’t Skip the ART Board
The ART Board is unique to SAFe®. It has been said that if you aren’t doing PI Planning, of which a key output is the ART Board, then you aren’t doing SAFe®.
Note
Prior to SAFe® 6.0, the ART Board was known as the Program Board.
What is the ART Board?
The ART Board is an outcome of PI Planning and is key to the planning process. The ART Board is a representation of the work the teams are completing and when they expect to complete it.
The importance of the ART Board can’t be understated. As a Coach, making sure the ART leverages the ART Board to its fullest potential can be one of the hardest things to accomplish. Ensuring that the ART Board is created with the necessary level of detail during the PI event and that the ART actually uses it during and after the PI event takes some effort.
Most folks think of the ART Board as only the ART Board with the rows for the teams, the sticky notes, and the string; however, if you think of all the information gathered and collected for the ART, there are several key components:
- The ART Planning Board
- The ROAM Board
- Integrated ART PI Objectives
The ART Planning Board
The ART Planning Board captures the Features, dependencies, milestones, and support needed from others who are not in the ART.
The ART Planning Board is a grid with a column for each iteration in the PI and a column for the next PI. There is a row for milestones, a row for each team, and some extra rows for out-of-ART support. These may include UX support, additional architecture work, callouts to a Shared Services Team, and so on.
On the ART Planning Board, the teams will add sticky notes for each Feature, typically blue, to the iteration in which the team plans to complete the Feature.
Red sticky notes capture dependencies between the teams and should ultimately align with the delivery of a Feature. Red string is attached to the dependency, and sticky notes show the critical path.
Orange sticky notes are typically used to denote milestones or significant events that affect the ART.
Pro tip
Keep the sticky note colors on the ART Planning Board consistent for each PI. We have mentioned the typical colors that SAFe® recommends here. Over time, you might discover that you are running low on one color and have an excess of another. You could choose to invert the colors; just make sure that everyone on the ART is aware and has updated legends so when folks read the boards, they know what they are looking at.
If you are creating a physical board, 1-inch blue painter’s tape works well for creating the rows and columns. You can print out and tape up the team names and iterations with dates to label the rows and columns.
Here, you will find an example of an ART Planning Board with dependencies, Features, and milestones.
Figure 9.2 – Example ART Planning Board
ART Planning Board tools
There are many different tools available for your ART Planning Board. If you are in person, sticky notes and painter’s tape will work on almost any wall. You might want to consider getting vinyl or laminated boards (and team boards) printed so that you can reuse them for every PI and potentially transport them from your PI event space back to the office.
In the virtual world, there are various tools that support the ART Planning Board, including PIPlanning.io, Agile Hive, Mural, Miro, and even Excel.
We encourage you to check out what’s available and works within your budget to provide the best experience and integrations for your ART.
The ROAM Board
The ROAM Board, sometimes called the Risk Board, captures the risks that may affect the ART. ROAM stands for Resolved, Owned, Accepted, and Mitigated. These are the states assigned to the various risks identified during the PI event:
- Resolved: The Resolved state captures risks that were identified during the PI event that have been solved during the PI event and are no longer risks.
- Owned: The Owned state captures risks that an individual has taken ownership of to ensure the risk gets resolved or mitigated.
- Accepted: The Accepted state captures risks that, if they occur, the ART will address at that point in time. These are risks that cannot be resolved in advance.
- Mitigated: Risks in the Mitigated state are ones that are targeted by plans to reduce their impact. A recommended practice is to identify who or what team will mitigate the risk and ensure that it is part of their plans.
Pro tip
Consider getting the teams to write the risks as “if X, then Y.” This format helps understand the impact of the risk being articulated.
For example, if Team Aviators don’t have the widget from Team Blue Falcons by Iteration 2, then Team Aviators won’t deliver the component by the end of Iteration 4.
Story from the real world
I have rarely found risks that have been added to the Accepted state materialize. However, I was at a PI Planning session in February 2020, and one team raised a risk that the scheduled parts may not arrive timely due to the news regarding shipments from China.
As we all know now, less than a month later, the world pretty much came to a standstill with Covid-19 and that risk (plus a few more) had to be addressed at that time.
There is occasional confusion between Mitigated and Owned, particularly when identifying who is executing the mitigation plan. Keep in mind that Owned risks still need additional work to identify the plan, whereas Mitigated risks already have a plan assigned to them; the plan just needs to be executed.
The Integrated ART PI Objectives
The Integrated ART PI Objectives are typically created after the PI event by the RTE, Product Management, and the System Architect and are a combination of the objectives created by the teams. We recommend capturing them and adding them to the area where your ART Board is stored. We will be able to leverage them during the iterations.
Pro tip
Many ARTs don’t take the time after the event to create their integrated ART PI Objectives and, all too often, the ART loses a bit of focus, especially toward the end of the PI. Make sure you take the time to create the objectives.
Consider creating the overarching PI Objectives prior to the PI event. Share them as part of the Product Vision. Then, as the teams create their PI Objectives, they can even share how their objectives compare to the overall objectives for the PI, thus improving alignment.
Using the ART Board during the Iterations
We recommend leveraging the ART Board throughout the PI. The teams have worked diligently during PI Planning to identify dependencies, plan Features, and identify risks. Too often, we see the PI work fall by the wayside once the iterations start. This feels like a waste and not an embodiment of the Lean-Agile principles we want our ARTs to have. When we leverage the ART Board during the PI, we reduce risk, as the teams have already identified and planned for many potential complications.
Recreating the ART Board in your ART’s Space
Prior to Covid-19, we typically held PI Planning Events in person and would have a wall for the ART Board. We would take copious amounts of pictures and recreate the physical board in our ART’s space after the PI event. If you are fortunate enough to have face-to-face PI Planning Events and are regularly working together in the office, our recommendation is that you recreate the ART Board in your space if it is separate from where you hold PI Planning.
If you are virtual, as many organizations now are, we strongly encourage you to invest in tools that support remote PI Planning, including the creation of an ART Board.
Having an ART Board that team members can look at and view regularly helps maintain alignment and allows teams to have conversations when items change or shift or can even just remind them of what they committed to during PI Planning.
Using it at the Sync Events
By reviewing the board at the various syncs, we can realign with the common objective we are driving toward. Depending on the sync, you may want to use the board in various ways and review different aspects of it from different perspectives:
- ART Sync: Review the dependencies to ensure they are on track for resolution and don’t become blockers. Review risks to ensure they are being mitigated appropriately.
- PO Sync: Review Feature delivery plans and have discussions regarding any changes to the plans.
- Coach Sync: Review the dependencies to ensure they are being resolved and capture any additional risks or dependencies that have arisen during the PI.
- Technical Sync: Review the progress toward delivery and identify any technical challenges that could impede delivery.
As a Coach, you will want to work closely with the teams to help them use the ART Board during their team meetings as well. Consider reviewing it as part of Backlog Refinement and Iteration Planning.
Iteration System Demo
The Iteration System Demo is held once per iteration for the entire ART. The intention is to provide an integrated view of all the work that all the teams have completed. Integration of work is one of the hardest things that teams do, and the Iteration System Demo is a forcing function for the integration of the systems and to give Stakeholders an objective measure of progress during the PI. Without the Iteration System Demo, we are unable to determine the actual progress being made to meet the PI Objectives and lose a critical feedback loop to keep the ART on track or to make any adjustments.
How to execute an Iteration System Demo
The Iteration System Demo should be executed after the end of every iteration and show the Features developed during the last iteration.
It is typically scheduled by the RTE and facilitated by Product Management with help from wider teams.
There is some planning and preparation that is required for the Iteration System Demo. You will need to balance the preparation efforts and, if the preparation for the demo is costly, there are likely areas within the ART for improvement.
Attendees typically include the System Team, Business Owners, the System Architect, ART team members, and Stakeholders.
There is typically a set agenda and a fixed timebox, usually 1 hour. The agenda often includes the following:
- Reviewing the PI Objectives
- Describing the Feature prior to demonstrating it
- Demonstrating the Feature with an end-to-end scenario
- Reviewing and identifying any current risks or impediments
- A question-and-answer session
- A closing-out summary with feedback and the action items captured
When holding the Iteration System Demo, you will want to demo from an environment as close to production as possible; typically, this is a staging environment.
Considerations for the Iteration System Demo
Consideration #1
Some systems, particularly those in manufacturing environments, may be too expensive to demo every two weeks. In this instance, you will want to work closely to determine what can be demoed and leverage the use of test doubles, models, and mock-ups.
Consideration #2
The cost of skipping the Iteration System Demo is extremely expensive. When we don’t integrate and use the Iteration System Demo as a forcing function, we are unable to truly see the progress of the working system, which creates a false sense of accomplishment. Late integration is one of the biggest challenges and costs which leads to significant rework. Remove the cost by insisting on regular Iteration System Demos.
It is also important to ensure that the Iteration System Demo is integrated and we can see value flow through the system, not just teams independently highlighting the work they have completed. We strongly urge you to avoid these anti-patterns.
Consideration #3
Use the Iteration System Demo as a way to continuously improve the Continuous Delivery Pipeline (CDP).
As former developers, we can assure you that if we have to do something more than once, we’re going to try and find a way to automate it and avoid having to manually complete steps if possible. The Iteration System Demo being executed as close to production as possible helps build out that automation and ultimately helps us to build in quality, as it will drive the use of test automation as well.
Summary
In this chapter, we learned about the various syncs we need to use to keep the ARTs aligned and why these syncs are important. We have even looked at a couple of extra syncs, including a Technical and Troika Sync. We learned how to continuously leverage the ART Board and why it’s important to not skip the Iteration System Demos due to their value.
There is a lot of continued alignment and execution that occurs during the iterations in the PI. Don’t fall into the trap of letting the teams operate independently during the PI. Use the Syncs, ART Board, and Iteration System Demos to retain alignment and keep the ART on the right track. In the next chapter, we’ll look into the PI event.
Further reading
- Planning Interval: https://www.scaledagileframework.com/planning-interval/
- PI Planning: https://www.scaledagileframework.com/pi-planning/
- System Demo: https://www.scaledagileframework.com/system-demo/