I read a blog post by Mike Cohn on the Nine Questions to Assess Team Structure.
Some of the takeaways and questions I found relevant are:
- Organizations often build short-lived project teams that disband at the end of a project. Is there a way to minimize team churn in this environment? Is it is possible to build cross-functional feature teams that can persist over multiple feature deliveries?
- Sometimes the need for a specific skill is not required for the life of a project. Some expertise is required to deliver IPSec for example, but the individual with this knowledge could work with multiple teams. How do you enable the skills transfer to multiple people so that no one individual has to be involved with more than 1 or 2 teams?
- Will your team structure minimize communication paths and enable communication between technical experts who would otherwise not communicate together?
- Does the team structure make accountability clear?
Creating these teams implies the building of redundant skills and overlap. This helps to create teams with no single point of failure–a necessity for business continuity. Doing so may feel inefficient. The value is reduced project risk, smoother flow, better throughput, and happier teams. If you are forced later to move team members between projects, the redundancy you build in gives you added flexibility and agility.
Creating teams is not just about maximizing short-term value for the project. It is about balancing the short-term needs of the business while building in long-term flexibility and resiliency of the teams and their capabilities to support the goals of your business. Don’t think of this as a trade-off. Think of this as an integrative process that gives you the best of both worlds over time.