Teams vs. Work Groups

Not all teams should be Agile Teams. There are lots of legitimate groups or organizational structures that are not highly collaborative teams – and really don’t need to be. Case in point: work groups and project teams are different organizations that serve different purposes.

For example, for problems that are very uncertain like R&D projects (i.e. problems that often require extensive discovery and analysis – perhaps even invention), you are probably best served with a dedicated project team that has a loosely managed, tight-knit, highly collaborative organization. You are looking for a lot of creative input and problem solving. Those sorts of teams do well at that.

Contrast that with a project that is challenging, but doesn’t face a lot of complete unknowns. I’m thinking of things that are more operational in nature like system upgrades, hardware upgrades, system migration. The tasks involved are relatively well understood. That’s not to say there is no uncertainty or challenge (I know that’s not true!), but compared to creating a new product, things are relatively clear and straightforward. For these kinds of projects using a workgroup is probably best. You have clear leadership and accountability & you have people who are highly specialized (networking, sys eng, etc.). These people don’t necessarily need really high levels of collaboration. A workgroup is the right way to organize these people.

To me, the point is that you don’t want to get it backwards. Use the best tool for the job. If you have a relatively straightforward problem that doesn’t require high levels of innovation, then for God’s sake, don’t try and build an Agile team out of them! You’ll just irritate and confuse people by sending the message that their specialization isn’t valuable (been there, done that).

On the other hand, if you are looking for a lot of creativity, then using a workgroup is probably not the best way to get the innovative results you are looking for. The creative, collaborative types of people required to do this work will not respond well to a silo’d, top down, organization.

All too often what I see happen is one group pointing at the other and saying, “That’s crazy! How can they work that way? Why don’t they work like us?” The answer is that the groups are trying to solve different problems – each is using the organization that is most appropriate to the problem, and the context that they are working in. We need to understand and respect those differences.