Agile is all about teams. We can all relate to this in terms of Scrum, with teams swarming to deliver on their user stories. But how does it work in Scaled Agile (SAFe)? Who are the teams besides the Scrum teams? To answer this question, it’s important to start out with some definitions.
What’s a Team?
To elaborate, I think it’s important to define the word “team”. Actually, let’s start with what a team is not. A team is not:
- A manager’s direct reports – this is a group of people bound by HR reporting responsibilities. They probably have varied interests, obligations and projects. And the manager himself is not really part of this team – he can literally hire/fire them. Clearly not “all for one, one for all” here.
- A large group of matrixed resources – Often in a matrix organization you’ll see project managers sending off emails addressed to “Team” (with 30-40 people on the cc: list), followed by an inspirational message to push hard for an objective. It’s not likely they all have the same vested interest, nor skin in the game, to accomplish the project manager’s mission. In fact it’s not even likely all the recipients even read the email!
So what is a team then? A team is a small group of individuals aligned to a common goal. Moreover, the members of this team trust each other. They rely on each other to deliver, and to help out when need arises. Finally, they have each other’s “backs”. When pressure comes, whether it’s a project milestone or even political pressure, they will support each other and stand up for the team. This is the “all for one and one for all” aspect.
The Troika
Now that we’ve defined “team” let’s get back to the question: what’s an example of a team in SAFe? I believe the best answer to that is “The Troika”. The troika represents the combined roles of Product, Process and Technology. At the program-level this includes Product Management, the RTE, and System Architecture/Engineering.
What does the ART troika do? They communicate regularly on program-level activities, such as technology discoveries, roadmap elaboration, supplier deliverables or intra-team dependencies. They give updates on risks identified during PI planning. How is this different than an SoS meeting? It’s different because these are the people who can resolve issues raised by the Scrum teams. And it’s more strategic and proactive (as opposed to reactive): the ART should be thinking ahead of the teams, ensuring future sprints are lined up for success.
Why Is the Troika a Team?
Again, these folks are the voices of Product, Process and Technology. Some of the biggest challenges stem from ARTs not having product clarity, or architecture not providing an extensive runway, which leads to churn during sprints. Or if an RTE’s metrics aren’t clearly laid out it causes all the teams to wonder “what’s being measured.”
Without the team mentality, it would be easy for any member of the troika to say “well, that’s architecture’s fault”, or “I sure hope Product gets its act together.” If anything, it’s more important than ever for the troika to act in one accord – the impact to all the scrum teams is too great of a risk otherwise.
But there’s another critical aspect to this as well. When the ART troika acts as a team, it has a huge impact on all the scrum teams on the program. This means the teams start picking up on this “all for one, one for all” attitude as well. And they begin to self-organize and come together on their deliverables. So the troika is modeling behavior for the rest of the ART to follow.
The Troika Meeting
This is why I initiated a new ceremony in our ART called The Troika Meeting. It’s a once-a-week, 1-hr gathering of the troika that covers the topics mentioned earlier. Everyone has a voice at the table, and people who are able to remove blockers sign up for their action items. The RTE conducts this meeting.
We’ve found this Troika meeting to be critical to the success of our ART. It instills purpose in the Troika and reinforces its power to effect change in the program. I hope that you are able to take this learning and apply it to your agile transformation.