Here is the image for your enjoyment:
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 a 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.
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 management has 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 a 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.
My definition might be a bit of a higher bar:
A team is a multi-person shared headspace where all the participants are actively pursuing at least one common goal they intend to achieve together as a unit.
Developers who don't share work assignments are not a team; they are polite tenants in a shared building.
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, very turbulent workflow 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.
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.
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, very turbulent workflow 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.
Agile methods require us to start and complete work together in small increments and keep the code in a running state.
Without teaming, necessary code hygiene will be abandoned as individuals rush to finish the maximum number of stories.
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. The shallow hurry to complete tickets is usually too much of a force for individuals to combat on their own. People cut corners, skimp on testing, and try to move on to the next ticket as soon as possible.
New feature work becomes increasingly difficult to complete without the careful maintenance we see teams routinely employ, This is observed by upper management and frequently misdiagnosed as "team members not trying as hard as they used to."
Without teaming, is your "agile" team a team at all?
What about that Agile stuff?
In the tweet, I am not saying you cannot have a team unless you are agile.
I say that a group of people can only be truly agile by working as a true team.
I say that a group of people can only be truly agile by working as a true team.
Agile methods require us to start and complete work together in small increments and keep the code in a running state.
Consider two different situations at the end of a project:
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, to bring each to completion soonest. This focus ("watch the baton, not the runners" in Lean parlance) makes it possible for us to deliver working code sooner and more often.
Delivering high-quality, high-value code as soon as possible is the agile way.
- 100% of the work is 80% done
- 80% 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, to bring each to completion soonest. This focus ("watch the baton, not the runners" in Lean parlance) makes it possible for us to deliver working code sooner and more often.
Delivering high-quality, high-value code as soon as possible is the agile way.
This is not something you can do well with a dozen people who each have their own work, and who are loathe to interrupt their teammates. You might seem to pull it off for a while, but it will eventually collapse.
Without teaming, necessary code hygiene will be abandoned as individuals rush to finish the maximum number of stories.
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. The shallow hurry to complete tickets is usually too much of a force for individuals to combat on their own. People cut corners, skimp on testing, and try to move on to the next ticket as soon as possible.
New feature work becomes increasingly difficult to complete without the careful maintenance we see teams routinely employ, This is observed by upper management and frequently misdiagnosed as "team members not trying as hard as they used to."
The primary value of teams in agile organizations may be to slow the rush and ensure work is done well.
Teaming speeds the delivery of working software by producing better software to begin with. More issues are spotted during the coding process, better designs are built by teams, and disciplines are not shirked due to personal pressures.
Teaming includes continuous review and inspection. People aren't constantly interrupted to inspect code or to repair defective code. Team members don't queue up "finished" code for hours, days, or weeks to be inspected and possibly returned for rework.
Teaming includes continuous review and inspection. People aren't constantly interrupted to inspect code or to repair defective code. Team members don't queue up "finished" code for hours, days, or weeks to be inspected and possibly returned for rework.
Without teaming, I'm not sure that any agile method can be successful.
Without teaming, is your "agile" team a team at all?
No comments:
Post a Comment