What About the Teams Themselves?

You might have noticed that there is no mention of team-level processes such as Scrum. That is intentional. The fact is, it does not matter very much! It is well documented that small IT projects tend to succeed, regardless of methodology. A single team is “table stakes”: it is not the hard part. What is hard is when you have lots of teams.

What matters most for an individual team is the same thing that matters for a group of teams: having the right forms of leadership in play. A team needs “an inside person, an outside person, and a person of action” just as an organization does—as Peter Drucker famously said.

There needs to be organizing leadership to get things set up and keep them moving. There needs to be decision-making that is well informed and timely.

Agile 2 explains this in more tangible terms. There needs to be Socratic leadership that stimulates discussion. There needs to be organizing leadership to get things set up and keep them moving. There needs to be decision-making that is well informed and timely. These are not necessarily roles or job titles, but they need to be present. And people on a team need to feel they have agency about how they do their work, and they need to feel heard when they have something they want others, particularly leaders, to know.

If you have those forms of leadership operating well, the initial process does not matter, because the teams and leaders will gravitate toward the process that they need.

Have a Flow Orientation

A person who is a natural “organizer” will often take the initiative to establish processes. Here are some thoughts on that.

We strongly recommend a flow-oriented process, because it is more event-based instead of calendar based. For example, SpaceX shies away from repeating or scheduled events: everything happens as soon as it can happen. Issues get discussed as soon as they appear. There is no waiting for a retrospective. Planning is done continuously: when something completes, a discussion happens about what else to focus on. Discussions are guided by “the one metric that matters” for the capability that a team is working on: how do we improve that metric?

A flow process can be organized as a Kanban flow, or not. If there is a division of labor, then a Kanban process might make sense. An example is behavioral test development: there might be a team of analysts who write test specs, and test programmers who code test programs as well as developers who implement product features—they are the ones who run the tests. That is a natural workflow so Kanban might be a good tool to organize that. However, there would be “backflow” because a developer might find that there is a problem with a test spec—and that is okay.

Consider a Work Backlog, but Keep the Focus on Capabilities

Having a work backlog is also a good technique. However, it should not trump the focus on capabilities. The capabilities should rule. Work items in a backlog should be viewed with skepticism. Each time you consider starting on one, ask “Do we still need that? Does it still make sense as it is defined?”

Team Roles Can Help or Hurt

Team roles help if you pick the right people, and hurt if you pick the wrong ones.

Ideally we would like for teams to operate as collaboratively as possible without the need for any explicit leadership roles. That does not always work well, however. Setting up a team involves deciding which domains of issues need leadership, and which people—if any—should be designated as leaders of those domains. Generally, the fewer the designated leaders the better, as long as the team is able to collaborate well, everyone is heard, and good decisions are being made in a timely manner.

A team building something using technology often benefits from having a technical lead for the team—as long as that person behaves in an open and inclusive manner. A technical lead not be the smartest or even the most technically knowledgeable person on a team: their job is to make sure that technical issues are discovered as soon as possible, discussed well, and that a timely decision gets made. Their job is also to coach the others on the team in the use of the technology well. Finally, they are a key interface person between other teams when product technical issues arise and need to be collaborated on among the teams. The quality of collaboration they are able to have is a key ingredient in their effectiveness.

Other roles might be useful: team lead, team organizer, team advocate. Depending on leadership skills, these might be one or several people, or no one in particular. The person setting up or overseeing the team needs to ensure that these forms of leadership are operating, regardless who is doing them.

A team lead is ideally a transformational leader and is focused on the people of the team. The team advocate speaks for the team when dealing with outside stakeholders: they are the “outside person”. The team organizer is always thinking of how to get things organized, and is always watching the potential improvements. They also are always watching the calendar: “Are we going to be ready for that demo? That thing is taking a long time—do they need help?” The organizer is the “person of action”.

Remember, these roles are not jobs. The point is that these kinds of leadership need to be happening, somehow, and happening well.

Leadership is not a job role—it is an activity. If you have these roles it is because you decided, based on the individuals on the team, that it would help to identify people who have the required leadership skills, and that empowering them with an actual role title would help: perhaps some of them are soft-spoken, and having an explicit role helps them to be heard. And it is often the case that an individual provides multiple kinds of leadership, and so do others: leadership overlaps among people. Again, the task of whoever sets up or oversees the team is to make sure that they required forms of leadership are in play.

Supporting Teams

Sometimes it is helpful to import someone from outside the team, in an adjunct manner, as an “extended team member”, perhaps participating part time. That person can operate as a subject matter expert or a lead on the domain of issues in which they are an expert. However, if their skills are transferable, it is preferable that they “teach to fish instead of fish”—in other words, train the team members in their skills—so that they are not a bottleneck.