An ART, such a buzz word!

If you are implementing SAFe (Scaled Agile Framework) within a large multi-national company, there are good chances that the maturity of some parts of the business will vary, some will be top edge, while others will still be maturing. This lead to a lot of discrepency within the business overall.

When launching an Scaled Agile transformation, often led by IT, and once you start to scale after the initial trial, every working group, every managers or directors want to join the party. Everybody wants their ARTs along with their PMTs and RTE as this is the new way of working. That's what we hoped for, right??

But wait a minute, reminde me what's an ART? An ART, or Agile Release Train, is long-lived team of Agile teams that incrementally develops, delivers, and often operates one or more solutions in a value stream. In the ART, solutions (i.e., products) are being developed, and agile teams are involved and directly produce part of the solution(s).?

I am told a lot: "I am launching my ART!" - Launching an ART is a long and complex topic that requires a lot of attention and work with proper skillset. Then, I ask one question: "Why do you want to start an ART?" Unfortunately, I often realize that most of the time the basic ART requirements are not met. There is often no reason to start an ART: there is not a single (or set of) solution(s) or product(s) that a large group of people can jointly contribute.?

What about agile teams?

So, if we have a group of solutions that are somewhat consistent in a product suite serving a line of business, do we need an ART? Should every software team be an ART or embedded in an ART? This means a group of agile teams working together doing PI planning event, retrospectives and having a 3PI roadmap and a single backlog... Of course not! Remember the first rule of scaling: Don't.?

In other words, if an ART is composed of agile teams delivering independent products without dependencies between the teams, the ART has no reason to exist. Autonomous agile teams delivering independent products will be more efficient if they don't scale.?

SAFe?is a very powerful framework to implement agile at scale. But SAFe costs a lot of administrative overhead that must be justified by the size of the teams working collaboratively (i.e Dunbar number: 50-125 team members). Having an ART, preparing and running a PI Planning event, doing system demos... all these amazingly helpful and fun activities are very beneficial to align teams together when they work collaboratively to deliver a product, but they would probably be an admin overhead if the agile teams are autonomous.

What is the value of a PI planning event and its outcome (the amazing program board) if there is no dependency between the teams? What's the value of teams planning together if they don't interact during the 10-week execution cycle? And if they don't release together? Limited, most likely.?

The first rule of scaling: Don't.?

What about visibility and commitment?

As part of the PI planning event, the Agile Release Train will reveal the team's 10-week commitments, as well as the upcoming plan for the next 10 weeks, and a 3 PI view. If you don't have a PI planning event but a bunch of autonomous agile teams working independently on 2-week?iterations, how do I get my commitment and visibility on what the teams will deliver? It is a very good question and there is no easy answer to it.

The PO

The Product Owner's role is indeed quite significant in this context. They will feed the team's backlog. Using team velocity and estimated high level sizing, the PO will forecast future iteration backlogs, but without commitment. The power of agile is about adapting the team backlog based on context, demos and results, and you want to keep this dynamic and do not want to commit too early.?

However, once a director responded, "You are right, however my teams and I keep getting challenged on the commitments and future milestones and we can’t have only 2 weeks’ visibility". When moving to agile, we must all shift our mindset: a milestone must be there for a reason: a fair trade, a peak period or the end of a fiscal year; not because someone higher up in the organization took the decision. That being said, a team may have a milestones to meet (i.e Brexit). How do we achieve the visibility and planning commitment to ensure we reach the milestone with a stand-alone agile team if we only plan 2 weeks ahead???

Being value oriented & iterate

The short answer is focusing on value rather than scope. By ensuring the agile teams are close to the real customer, by fostering the relationship between them and by ensuring the real customer joins the demos and provides feedback, the agile team will understand the "why" behind the date and concentrate on achieving the value required by the business context; not focusing on the scope agreed and committed too long ago.

I have SAFe large solutions or SAFe Portfolio, how do I integrate my agile stand-alone teams in this context?

If your organisation has SAFe large solutions or SAFe Portfolio, groups of Agile Release Trains are likely to be working together to deliver a set of solutions, integrating and releasing. Stand-alone agile teams can be integrated in this complex mechanims: The scrum master of the Agile team will align with the RTEs, the PO with the Product managers, architects with architects, and the team will be part of the pre and post-PI planning.

Shall I launch an ART or focus on stand-alone highly efficient agile teams?

Before you launch your ART, I recommend asking yourself: "why do we need an ART and how do I structure my teams to achieve better results?" Why do we need to group these teams together and what are the benefits of planning, executing, demoing, and releasing together?

If you do not have an accurate answer to this, probably the business requires efficient stand-alone agile teams using scrum with experienced POs!?

However, if you do have a good answer to this question, then ScaledAgile and launching an Agile Release Train will give a lot of benefits! But I would recommend to start with value stream identification to truly undestand how the teams, systems and solutions support the business and the customer(s), ensuring you launch the right ARTs and agile teams... and iterate on this to continue improvement of the value stream.

Baptiste Galea?

Who am I? I work for a large multi-national company in the logistic industry, and I am leading a LACE team toward SAFe implementation in Europe.

Further readings:

• https://medium.com/agileinsider/the-five-orders-of-scaling-agile-teams-55f799ae5416
• https://www.dhirubhai.net/pulse/first-rule-scaling-agile-dont-andreas-rowell/
• https://awkwardagile.com/the-first-rule-of-scaling-agile-dont/