Rob Caron recently referred to a very good article Team Doctors, Report to ER. This article describes some basic problems I often see when I deal with software development groups and their management.
The article alludes to teams being a group of people with complimentary skills that work together, make decisions, are given responsibilities, and are mutually accountable. It also alludes to leaders as being a person who is a member of the team, delegates decisions to the most capable member of the team, ensures decisions are made, ensures problems don't pile up, keeps members focus on goals, and manages goals/priorities/processes.
Management of software development groups often sub-group people together and anoint someone to manage that sub-group. They then refer to that sub-group as a team and the person, or persons, managing it as a "leader" or leaders. The problem I often see is that the sub-group and its management is either not given the mandate or not given the responsibility for that sub-group to actually be a "team" or the manager of that sub-group to be a "leader". The "leader" is usually just the most senior person and they're anointed as "leader" for political reasons.
Groups of people forced to follow leadership of a person who is not a leader and are not given the mandate and resources to operate as a team are described as a "nonteam" and is doomed to failure.
The article goes on to name some of the symptoms of "nonteams":
- "Collective Amnesia" – the nonteam wonders why the team exists.
- "Group Myopia" – the nonteam wonders what they are trying to do; they don't know what the goals are or how to reach them.
- "Chronic Cantankerousness" – nonteam members often quarrel about insignificant team issues or details.
- "Losing Life Support" – the nonteam does not have the resources (money, space, equipment, information) to operate as a team.
Some other things I've read recently that would lead me to believe a software development sub-group is not really a "team":
- Mushroom Management1 – the software development team is isolated from customers/clients and the real world and are only given incomplete, filtered second-hand information about requirements and goals.
- Shallow Process – Things like ISO 900x only truly mandate that an organization has a process. If a group says they "have a process"; but that process doesn't really contain any detail for the process' artifacts or guidance on how to complete a task with known quality, they really don't have a process.
1 Willian J. Brown et al. Anti-Patterns: Refactoring Software, Architecture and Projects in Crisis. Wiley. 1998.