Why Your Train isn’t Your Department
One of the first mistakes many organizations make when standing up an ART is they align it with their existing organizational structure. After all, our organizations have evolved into a system that works. We have an organizational structure that we continually refine (reorganize) to make sure we are optimally aligned. However, have you stopped to consider the reason we seem to be in a constant state of re-org?
How should we Build our ART?
Let’s start by defining what an ART is. An ART is a virtual organization of 5 to 12 long-lived Agile Teams that consist of 50 to 125 people working to deliver a common solution on cadence. Successful ARTs are aligned with a shared mission or vision.
Now that we know what an ART is, we need to determine whether we need one.
A common mistake that many organizations make is assuming that they “need” an ART, and they stand one up for every project they undertake. The organization identifies the project and then finds the “resources” to work on that project.
With SAFe®, we take a different approach and create our teams and ARTs for our Development Value Streams; see Chapter 12 for additional information. This naturally allows us to align the ART so that it works with a specific domain and take work to the ART rather than standing up and tearing down ARTs as projects start and stop.
Cross-Functional
When creating our ART, the intent is that our ART can support itself. This means we want our ART to be organizationally cross-functional. We will need people from all parts of the organization, including Business, Engineering, Testing, Operations, Security, Compliance, and so on. We often encounter situations where these parts of the organization typically don’t work together daily and have their own hierarchy and even culture.
As we launch our ART, we likely won’t have the ART composition correct on our first attempt and that is OK – it will evolve. The intent is to minimize hand-offs and subsequent delays. Our non-siloed cross-functional teams will drive this in conjunction with a strong Continuous Integration/Continuous Delivery (CI/CD) pipeline with DevOps support. Chapter 7 has additional information on CI/CD and the Continuous Delivery Pipeline (CDP).
Note that even cross-functional ARTs will still need to interface with the rest of the organization and will need a System Team and will likely have dependencies on Shared Services Teams.
Dedicated and Long-Standing
Our ART should have dedicated team members. This means that the individual is allocated to the ART and their team 100%. We want to minimize task switching and keep teams together for as long as is reasonably possible.
Pro tip
If I had to pick one battle to win when setting up an ART, it would be having dedicated team members. Too many times I see organizations allocate a person 25% to the ART. 25% of the time, they attend the events and are left with an hour or two of actual time to work on stories. How much of a story can you realistically get done in 1 or 2 hours?
Communicative
Our ART needs to be able to communicate freely and effectively across organizational boundaries. People from Business need to be able to regularly talk with people from IT and subsequently people in Operations and people in Marketing and throughout the organization. This communication must flow organically without you having to work up and down the organization chart.
Conway’s Law
Conway’s Law [1] states that an organization’s output is directly related to how it communicates internally. What we have discovered is that these communication hierarchies are often significant barriers to flow. Organizations with successful ARTs have figured out the nature of a Dual Operating System and understand that our ARTs should be built around our social structures (how we talk and chat and work with each other informally) as opposed to our organizational hierarchies.
Maturity
ARTs mature and evolve. ARTs, like teams, follow Tuckman’s model of Forming, Storming, Norming, and Performing, as explained for teams in Chapter 2. As a Coach and/or Release Train Engineer (RTE), you want your ART to become high performing. One thing to keep in mind is that the ART will mature more slowly than a team will due to its size.
Pro tip
I liken the maturity of an ART to that of a child; each PI is like a year of child development. When that ART is in its first PI, I liken it to a newborn baby. It needs constant care, feeding, and changing.
The second PI is like a 1-year-old; maybe a little less care, but it still needs to be fed. It’s maybe just starting to crawl.
The third PI is like having a 2-year-old with constant “Why” questions.
By the time we get to the fifth PI, the ART is like a kindergartener. It can get dressed on its own, but its clothes are likely mismatched and its shoes are on the wrong feet.
It’s about 2 years in, around PI 9 or 10, that the ART can largely take care of the daily activities with help and support for the big items.
It takes time for ARTs to grow and mature. The longer you keep the ART stable, the better it will execute and deliver.
When our ARTs aren’t communicative, cross-functional, dedicated, long-standing, and mature, they are inefficient. The ART will be plagued by corporate politics, it will grow and shrink with each budget cycle, and the churn and overhead of standing up and down ARTs in the same fashion as projects are just wasteful.