Monday, April 13, 2015

Individual Work Assignments: Neither Agile Nor Team

I managed to set off a small avalanche of retweets, agreement, and absolute angst in the past few weeks, when something I'd said sometime last year appeared as a quote in a lovely frame (thank you so much Agile Fortune!).

Here is the image for your enjoyment:

It seems that maybe I've touched on something that people are thinking about, and possibly on a point of contention in many organizations. 

Most traditional managements have a focus on resource loading and utilization. What we are learning about people who do knowledge work (for instance, software development) is that utilization of resources is exactly the wrong idea. 

Let's explore what I had in mind when I wrote the tweet:

What is a Team anyway?

For now, let's put the whole "agile" thing aside entirely. It doesn't matter if you're agile or not. I can pick that back up in a few paragraphs. For now concentrate on the concept of team.

To team (the verb) is "come together as a team to achieve a common goal."

A team is "a group of people who work together" (MW).

C.Avery says "the task is the reason for the team" -- a team is a temporary organization created to complete a specified goal, and their alignment is a defining characteristic. They're not an arbitrary assemblage of persons.

In many organizations, what they call a team is "people who report to the same manager, but who never share any work items, who have separate areas of responsibility, and who avoid communicating with each other so that they don't interrupt the other person's task."  You should know that such a structure is no team at all. They don't share a common goal, they don't come together, they don't share a job between them, they avoid conversation.

Developers who don't share work assignments are not a team; they are polite tenants in a shared building.

Tell-Tale Signs

A team is different from a group of individuals in qualitative and quantitative ways. One can sit in a single status meeting and tell the difference.

A group of individuals all have "their own work" and are responsible for clearing "their own plate."

They may have handoffs between experts, but they work alone, and minimize conversation and interaction.

They may be stack-ranked, so they often feel they are in competition and frequently their goals are in competition with those of their "colleagues."

Groups of individuals all maintain separate areas of responsibility and separate sets of skills. As a result, a very turbulent work flow results with less-expert developers waiting on experts to (solo) complete parts of tasks. While they wait, they take on extra tasks (to stay busy) and soon there are many tasks in progress, few finished, and developers become overwhelmed.

The individual style of work is great for defined processes (assembly lines, etc) but for knowledge work, it seems to suffer more drawbacks than group work.

A team works together to accomplish goals.

What is a Team Like?

Watch the first couple of minutes of Agile and The Seven Deadly Sins, and see what Mike Cohn says is a fundamental attribute of agile practices.

A team uses interaction to complete work quickly and well, and to share knowledge and skill to build group competence ("watch the baton, not the runners").

They are in profound cooperation, and do not compete against each other. This is one of the reasons that Deming referred to performance appraisals as one of the Seven Deadly Diseases of Management (referenced also by Esther Derby's excellent article).

The work of an individual in a group cannot be assessed apart from the work of his peers.

In fact, individual assignments are considered an anti-pattern.

Teams are powerful, self-directed, and hard to "rank and yank." Individual awards and punishments don't apply. 

They're not as easy to manage as a set of individual drones who do as they're told, and whose work is solitary and easy to appraise. They're not under managerial control. But they get a load of work done and they learn and improve quickly.

What about that Agile stuff? 

In the tweet I am not saying that you cannot be a team unless you are agile.

I'm saying that you cannot be truly agile unless you become truly a team. 

Agile methods require us to start and complete work in very small increments, and to keep the code in a running state that is open to modification.

Consider two different situations at the end of a project:
  • 100% of the work is 70% done
  • 70% of the work is 100% done.
The former is an unmitigated disaster.
The latter is a workable situation and a qualified success.

Agile teams apply the maximum number of people to work on the smallest number of tasks, in order to bring each to completion soonest. This focus ("watch the baton, not the runners" in Lean parlance) makes it possible for us to have the most work completed and deliver it soonest.

Delivering high-quality, high-value code as soon as possible is the agile way. It's not something you can do well with a dozen people who don't talk to each other and don't sit near each other, and don't converse or participate together.  

Without teaming, necessary code hygiene will be abandoned as individuals rush the maximum number of stories to done. The primary value of teams in agile organizations may be to slow the rush and ensure work is done well. Without this care, work becomes increasingly difficult to complete through the life of the project, which is frequently observed and misdiagnosed as "teams slowing down." 

If you are working incrementally and evolving your code base, then you have to be more strict about the quality of the code, not less. Any unmanageable changes come back to haunt you very quickly, and any untested code can be broken at any time by any number of people.

Without the teaming, I'm not sure that any agile method can be successful. .

Without teaming, is it a team at all?