In both large and small organizations alike, silos and segregations tend to keep productive individuals away from working with each other. Despite the promotion of collaboration and togetherness rife within agile principles, it’s surprising how even the best-structured companies can keep talented, well-meaning folks away from each other — even within their own departmental or functional silos.
Keeping individuals whose talents complement each other goes against well-known SAFe principles around organizing cross-functional teams around value streams. Specifically, the principles around being able to form a team that can work together to deliver value to the organization.
When teams are not empowered to deliver value — specifically due to an inability to work cross-functionally with others who have complementary skills — the tenants of collaboration, innovation, and ideation that drive value delivery quickly dry up. This can ultimately lead to bankruptcy or ruin.
This is where the agile release train (ART) comes in. As a product manager, it is your responsibility to not only understand the role that you play in an ART team but also how you can best help other members of your ART team achieve their best.
In a nutshell, the agile release train (ART) is a feature of a formal agile framework called the scaled agile framework (SAFe). It’s a central tenet of SAFe and implements a few values that are key to proper SAFe practice and structure in organizations.
In particular, ART applies principles #2 (apply systems thinking) and #10 (organize around value) of proper SAFe practice. Ultimately, applying systems thinking and creating value for delivery are key components in ensuring that ART, and ART teams in particular, can succeed in delivering real change for the company.
ART breaks individuals out of their functional development silos — such as QA testers only working for the QA function or security developers only working for the security department — and brings them together in a cross-functional team. They assist with a clear flow of work from one function to the next and bring together a variety of different yet valuable opinions. These voices come from different spectrums and areas of expertise to smoothly ship well-thought-out and discussed ideas as simply, quickly, and efficiently as possible.
Teams built on the principles of ART work collaboratively on defining the problem they want to tackle and the solution to be delivered. They believe in agile best practices, such as breaking down projects into smaller chunks, satisfying customers by delivering value quickly, speed, collaboration, etc., as well as working on a fixed schedule (which could be defined by sprints).
As mentioned previously, these teams should be self-sufficient in that they can define, build, validate, release, and operate solutions without any further dependencies on any other functional silos within the organization.
In comparison to typical agile teams, ART teams are larger, often consisting of 50 to 125 individuals. These teams typically include not just developers and testers, but also representatives from other functions such as operations, infrastructure, and even business stakeholders. Agile release trains, as a result, have a more diverse range of roles and perspectives. Their holistic understanding of the organization’s larger strategic goals help equip them to align their work as needed.
Moreover, the cadence of ART teams is synchronized across all teams on the train. This makes it easy to execute larger initiatives that smaller agile teams would likely have a hard time coordinating. This system enables teams to break larger objectives down into smaller, manageable pieces and to integrate the work of multiple teams. This is where ART teams are much different than regular agile teams — they can tackle complex, multifaceted projects with quicker.
The following are the advantages of running an ART team:
Due to having both a product owner and scrum master fully invested in the delivery process as well as the use of time-boxed sprints on a form of project planning software, initiative progress is clear, communicated, and transparent with all stakeholders involved — whether they are in the team or outside of the team but in the company.
As the name suggests, running an ART team means that agile standards, especially the scrum framework, will be continually adhered to throughout the deliverable.
Despite popular opinion, teams that “commit” to following agile tend to, at times, either amalgamate agile with other types of frameworks or internally created methods that may not be as efficient as agile.
Amalgamating different methods down the line dilutes the proven efficiency and effectiveness that a properly agile-run team can bring to a company. Running ART teams and having key individuals responsible for ensuring agile continues to run through the teams help keep everyone on track to deliver their initiatives in the best way possible.
Finally, as mentioned previously, ART teams tend to combine different domain experts from segregated silos across an organization to work as one efficient and self-sufficient team. To ensure that all members work effectively, individuals such as a scrum master, product owner, and product manager act as the glue between the different disciplines. They help ensure that everyone’s voices are heard throughout the delivery of the initiative.
Usually, ART teams will consist of the following roles:
These are the core of ART teams and are typically the working members of the team that assists with the discovery, design, and delivery of the initiative to its conclusion.
They can be engineers, designers, testers, security compliance analysts, associate product managers, or data analysts. Ultimately, without the team members, an ART cannot function to its full potential
This is an individual or a small group of individuals within the ART team that defines the overall architecture and infrastructure of the system you are planning to release your feature on.
This is one of the most technical roles in an ART team and they are responsible for defining non-functional requirements, major system elements, subsystems, and interfaces of your product.
Having an individual as an RTE is one of the key responsibilities of any member of an ART team. Although the team is meant to be autonomous and self-organizing, it takes a responsible individual to continue ensuring that the ART team stays on track and continues to practice agile practices and processes as part of the team.
Other than serving as a coach and guide for best ART practices for team members, they are also important in guiding leaders within the team to implement the correct practices and processes for their very own ART team.
They are also secondary advisers to scrum masters and assist with risk management and value delivery. RTEs ensure that not only is the team identifying any issues in implementing ART practices early on, but that those risks are completely heard and addressed by leadership.
As the name suggests, a scrum master is an expert in scrum methodologies. Scrum is an agile framework with a heavy focus on delivering value to the customer via time-boxed iterations called sprints.
A scrum master is responsible for leading the team in delivering outcomes through the use of sprints as the delivery method of choice. They also facilitate communication, collaboration, and camaraderie between leadership and the team to ensure that there is a well-built, defined deliverable at the end of the sprint.
Well-run agile teams need a point of reference in the business to ensure that the changes they are making deliver outcomes for the business. A business owner helps the ART team collaborate and coordinate with other departments to complete their initiatives on time.
A business owner guides ARTs to ensure that the teams are working to positively influence the organization’s growth.
Although both terms are sometimes conflated in agile teams, here, a product owner is responsible for something different when compared to a product manager. Where a product manager is responsible for the overarching strategy, purpose, and reason for the type of work that the ART team is thinking about delivering, the product owner works with the scrum master to ensure that there is value in the deliverable that the team produces at the end of sprints.
This might take the form of writing epics and user stories with the team, collaborating with the scrum master to move tickets into the sprint, or ensuring an optimal level of velocity by the team. Being a product owner means being focused on the deliverable initiative at the end of the sprint and ensuring that there was a cross-collaborative work environment to achieve this.
Finally, as mentioned previously, a product manager is largely concerned with two overarching questions: what gets built and what gets prioritized?
Being a product manager means being the glue that keeps all other stakeholders in the team working together to provide value to the customers at the end of a sprint.
Artifacts that are usually produced by a product manager to enable the delivery of value in ART teams include:
| Summary of ART team roles | |
| Role | Description |
| Agile team members | The core workforce of ART teams, involved in the discovery, design, and delivery of the initiative. They can have various roles like engineers, designers, testers, etc., and are vital for the ART to function effectively |
| System architects/engineers | Define the overall system architecture and infrastructure for the planned release. Being one of the most technical roles in the team, they are responsible for defining non-functional requirements, major system elements, subsystems, and interfaces |
| Release train engineers (RTEs) | Ensure the ART team stays on track and practices agile processes effectively. They serve as coaches for best ART practices, guide leaders in implementing correct practices, advise scrum masters, and assist with risk management and value delivery |
| Scrum master | Experts in scrum methodologies and lead the team in delivering outcomes via sprints. They also facilitate communication, collaboration, and camaraderie between leadership and the team to ensure well-defined deliverables |
| Business owner | They serve as a business point of reference for the ART team, aiding in collaboration and coordination with other departments. They guide the team toward positively influencing the organization’s growth |
| Product owner | They ensure value in the deliverables produced at the end of sprints, often by writing epics and user stories, and collaborating with the scrum master to move tickets into the sprint. They focus on the cross-collaborative environment to achieve deliverables |
| Product manager | They answer the overarching questions of what gets built and prioritized. They unite all stakeholders and work towards providing customer value. Typical artifacts they produce include defining product vision, roadmap, feature requirements, and prioritizing new features |
To effectively run an ART and have an efficient ART team team, the following are the key principles to remember:
Members of an ART team will try to complete all of the intended work within a time-boxed period, known as a sprint. A sprint will typically last two weeks at a time.
Running an ART team (it’s in the name!) means that members are adhering and committed to running initiatives in an agile manner, particularly using the scrum framework as a guide.
Velocity is the amount of work that gets completed during a time-boxed sprint. This is a numerical value that is usually calculated using user story points. The higher the velocity amount, the more work gets done.
Product managers, product owners, and scrum masters must be careful in calibrating the amount of velocity completed by a team in every sprint. They need to balance the maximum amount of work being completed and the risk of burnout by team members.
A bi-weekly system increment is basically a fancy way of saying that the ART team will deliver value, whether as an MVP or as a fully-fledged feature, to the product at the end of every sprint (every two weeks).
On the same theme of fancy terms, a program increment (PI) is another way of denoting the regular two-week sprint that ART teams commit to, by which they deliver a system increment by the end of the PI period.
In today’s remote working world, this might seem to be a little traditional. Usually, a sprint or PI is planned by key individuals, such as the product manager, product owner, scrum master, and engineering manager in a way that ensures the sprint velocity.
After each sprint (or PI) is over, the whole ART team — led by key leadership individuals in the team — should meet up to hold an IP session. This is a dedicated time for the team to plan the next sprint or PI, as well as spend time talking about change management and infrastructure maintenance as well.
Finally, an inspect and adapt (I&A) event is another way of indicating having regular in-team demos of work in progress to ensure that the quality of the work is maintained and that the deliverable will meet the company’s high standards.
As a key member of an ART team, the role of a product manager is an important one in keeping the team focused on its objectives. This is all while the team is working well together with other experts in their domain. The PM helps the team deliver their objectives during each sprint.
The following are the key responsibilities of a product manager within an ART team:
As a product manager, it is your responsibility to not only to set the long-term strategy and vision for the team, but to also correlate that to the work the team is going to be undertaking as part of the ART team. In essence, it’s to prioritize and ensure that the team is working on the most valuable thing during the two-week sprint cycle that brings a valuable outcome for your customers and the company as a whole.
Determining what needs to be built next is an exercise of balancing competing needs and ensuring that the velocity of the team is sufficient, all whilst also prioritizing the next big thing that can satisfy a customer pain point.
Connecting with customers of the product to understand their pain points, concerns, and issues is only one part of the story when conducting continuous discovery for your product.
A great product manager can take the pain points mentioned by customers and translate them into feature requirements with the help of the team. These pain points can be built and prioritized by the team during the next two-week sprint cycle.
One of the most important admin tasks that a product manager can conduct for the team is to prioritize and prune the ART backlog regularly. This is to ensure that the team remains committed to working on the next best thing that is in the backlog.
It’s also to ensure that tickets don’t continue to pile up uncontrollably. The last thing you want is for the ART backlog process to be an exercise of complete desperation and ineffectiveness.
An uncontrolled backlog threatens to upend the delicate balance of productivity that the team finds itself when committed to the scrum framework. Keeping a backlog fresh, current, and prioritized based on customer needs ensures that the flow of work remains continuous between each sprint cycle conducted by the team.
Follow the tips above and you’ll implement ART principles into your team like a product manager in no time!
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Jyoti Memom shares how trust is not only a value proposition for Bread Financial, but a pillar of what drives the product and decisions.
Agile isn’t broken — it’s just being misused. Learn how to reset your rituals, refocus on outcomes, and bring meaning back to your process.
Product crises happen—bugs, breaches, or PR disasters. Here’s how PMs can plan ahead, stay calm, and lead through the chaos.
John Arquette shares his experience working in the early days of ecommerce and how it’s drastically transitioned over time.
Learn more →
