Running an agile team is NOT about keeping people busy

Door Patrick Verheij

I see it all the time: so called agile teams are doing everything to keep each and every one of their team members busy all the time during an iteration, every iteration.

Such teams try to be efficient and, unfortunately, do not realize that they often sacrifice their effectiveness that way. And their agility for that matter,

Of course it would be awesome if everyone in the team would be continuously busy contributing to the team’s goals and outcome. Alas, that is NOT the result of the usual efforts in keeping people busy.

Let’s take a look at what’s actually happening in some agile teams.

Usually teams have some kind of sprint backlog, but lack a clear sprint goal. They simply work on a bunch of stories that seem to have the most priority. But that’s not even the real problem.

The real problem is that the team doesn’t put much effort in properly balancing the team.

What do I mean by that? Let’s look at some of the major symptoms:

  1. Team members are usually specialized along the line of analist, operations engineer and developer. The latter is split further in front-end and back-end developers. These specialists tend to focus on the work that THEY can do best, from their specialist point of view. To such an extent that these specialists even write down their own work as user stories: “as an engineer I want…”. Even if that’s not the case, there is an automatism in the team to constantly check if there’s enough work for everybody’s specialism. If not, then all kinds of bad stuff happen: additional stories are drawn in to the iteration, value-driven stories are split into separate work packages, and team members commit to work outside of their team. The result? Not much value is delivered, stories remain unfinished and the team members lack a common understanding of progress.
  2. Team members have difficulties or even resist putting effort in learning additional skills. That means they remain stuck in their line of work. As a consequence the team itself isn’t very adaptive because there’s always the same optimal distribution of work among team members. E.g. a team that is engineering-heavy may have a hard time going through a period of design thinking whilst a business-heavy team will have difficulties producing software at a decent rate when the time for production arrives.
  3. Whenever the ground becomes hot underneath the team’s already sore ass, it starts shouting for additional team members. Of course of a specific kind. They say “we have too much work, so we need more developers!”. They either don’t get those resources and become frustrated and overworked or they do get them which also makes their team size grow. And their problems.

Besides all this, teams often state that their team composition should be fixed. They appeal to the perceived agile principle of “keeping teams together”. Alas, they cannot appeal to the more common statement of “never change a winning team” because they just aren’t winning.

Agile teams qiuckly lose their game when they don’t work on their balance. If they wish to be a team that can stick together through different missions and the usual corporate turbulence, they’d better make sure they work on building that TEAM instead of being a group of people trying their best.

To be such a team, the team members should collaborate on a few things:

  1. Create a common undersdning of the nature of the customer’s need, the work to be done and the work environment the team operates in.
  2. Find out the right balance of skills typically needed to get things done.
  3. Constantly work to maintain that balance by learning new skills, and become better at reaching the team’s goal together.
  4. Agree on what to do when the balance cannot be maintained for whatever reason.

It’s okay to change the team by allowing a person to leave or by adding an additional member. Such change is inevitable anyway due to personal ambition or any other part of human nature.

Of course there are some teams that do not have the challenge of balancing themselves, or at least to a lesser extent:

  • If the team’s mission is a one-off, then there is nothing wrong with hiring specific skills to get the job done and disbanding the team after the mission is accomplished. This is then called a “project”. There’s nothing wrong with projects and project teams as long as they don’t create a messy IT landscape and unmaintainable software. Because our experience with those is far from satisfying, some people now have completely banned the word “project” in their agile zealocy.
  • Teams that have a single everlasting mission OR teams that have consecutive similar missions are perfectly okay being a one-trick pony team. Their challenge doens’t change much, so neither should their skills. Such teams should merely take heed not to rely too much on single points of failure, That’s all. They work merrily ever after.

On what kind of team are you? Or if you are a coach of some kind, what kind of teams do you aid? What does your balancing act look like?

Patrick Verheij

06 59 443 447

Andere posts

Klik hier