Shared CARGO™ And Successful Agile Teams

Books like Khoi Tu’s “Superteams” and articles in the Harvard Business Review discuss what makes successful, high-performing teams. In the Agileverse¹, we talk a lot about self-organizing teams, transparency, servant leadership, and the power of cross-functional teams. One of the important aspects of these teams is the sharing that occurs and how it leads to their success. Successful Agile teams share. Agile teams recognize that to be successful they have to move away from the traditional ego identification with their work product and toward something collaborative.

Let’s consider the first of the four value statements in A Manifesto for Agile Software Development (“The Agile Manifesto”): Individuals and interactions over processes and tools. That word “interactions” is critical in all of this. As one colleague said to me ages ago, “processes and tools don’t create software, people do.”

I’ve identified several characteristics that I’ve found to be shared by those successful teams. I call it Agile Shared CARGO™. And of course, being a techie, it’s an acronym.

Let’s dig in…

CARGO = Commitment, Accountability, Responsibility, Goals, and Ownership

Shared Commitment

If you’ve read about, been trained about, or heard about Scrum, you’re heard the word commitment used more than once. At the start of a sprint, the team commits. Let’s go beyond that. High performing teams share that commitment. It’s not like “the boss says we need to do this, so we’re going to do it” from the project manager. It’s about the members of the team coming together, agreeing on the desired outcomes and outputs, and then making a team commitment.

That leads naturally to…

Shared Accountability

In a traditional environment, team members are accountable to their project managers, managers, tech leads, and others who have the words “manager” or “lead” in their titles. Agile team members are accountable to each other. To this end, they craft (and modify) a set of working agreements (a.k.a. team norms). They agree on how to behave with each other, how to work together, and then take responsibility to be accountable to each other and self-police. It’s not about enforcement and oversight, it’s about agreement, collaboration, and commitment (yeah, shared commitment).

Shared Responsibility

In our Western culture, particularly in the United States, there has been a bias towards finding fault and assigning blame, as the other side of our idolization of heroes. It is common on traditional projects to find that one person is recognized as “the hero” upon whom the leaders can depend to get things done. I call this – big surprise – a Culture of Heroism, a Culture of Fault and a Culture of Blame. This results in our finishing projects with a post mortem (which translates to “after death”) during which we try to figure out who screwed up, how badly, and what we should do about it.

Successful Agile teams, on the other hand, conduct retrospectives as part of an inspect-and-adapt mindset. Agile teams share the responsibility for success or failure. The answer to the question “Who is responsible for this [failure | fault | problem]?” shifts from finger-pointing to a simple answer: “We are.”

Shared Goals

All too often, we find groups based upon roles (developer, tester/QA, UX, and so on) being referred to as “teams”. The thing is, those groups generally don’t meet a reasonable definition of “team”. They are probably on multiple projects, each responding and reporting to both their department manager and a project manager and an architect and a tech lead.

One definition I use is “come together to achieve a common goal.” That’s key in my mind. When we see a team of developers, they’re really not focused on shared goals. Agile cross-functional teams work toward shared goals. Each Sprint they work together to articulate and commit to a Sprint Goal. Each Release they work together to articulate and commit to a Release Goal. They share a commitment to achieving the team’s goals and to reducing conflicting leadership by achieving clarity of understanding and communication.

Shared Ownership

Last, but very, very far from least, is shared ownership. By ownership, I don’t mean that they literally have a financial/business investment. Rather I’m referring to the emotional attachment to delivering quality and value. I’m referring to the idea that the team members act as if they have some money or something else of value in the game, and want to win the game. Especially when winning equates to delivering quality and value.

Many traditional teams have suffered from the lack of this Agile Shared CARGO. Work is assigned, blame is assigned, goals are assigned, they have no responsibility, and they are accountable because they are accountable. They don’t feel like it’s their project or product, just something that is assigned to them and in which they may or may not have any investment.

Successful Agile teams – high performing teams – succeed because the members of the team are permitted –  no, encouraged – to share in these ways.

Deliver the CARGO to deliver success!

¹ Yeah, I know that’s not a real word. But you knew exactly what I meant, didn’t you?