If you were to change nothing else on a project except to set up a cross-functional team, you’d likely receive significant benefits on your project. A cross-functional team is a team that is focused on only one product/project/application. The team is usually small – no more than 8-10 people and consists of people across disciplines – for example, application developers, Testers/QA, Operations, DBAs, analysts, etc. The goal is to reduce the typical communication overhead and wait times associated with matrixed teams. The team is focused on delivering something of value to customers and not getting spread too thin across multiple efforts.
Some of the common objections when we recommend this approach to customers are:
- Their projects are too large and complex
- They can’t afford to put one person (e.g. a DBA) on only one project
- It requires too much change in organizational structure
For the projects that claim to be too large and complex, the solution is to break apart the project so that there’s a smaller deployable unit. This doesn’t mean there aren’t large systems. You can still have a very large system, but the large system is composed of many smaller systems that be individually deployed. A Service-Oriented Architecture – or SOA – helps to achieve the objective of creating large systems that are made up of many smaller systems. This isn’t an overnight transformation, but once you determine how much time is lost in communication overhead and broken systems, it can be worth the investment.
For those that claim they can’t afford to put a person who is currently allocated to several projects on only one project, they need to understand the impact of the communication overhead and the lack of ownership when assigned to support multiple projects. In some cases, the skillsets of people may expand as they work on cross-functional teams.
For those that are concerned about the organization being unable to transform their organizational structure, the approach isn’t to change the entire organization all at once. Instead, you run a pilot project – usually on a new project. Based on what you learn on the pilot project, you apply those learnings to subsequent projects across the organization.
Finally, some teams skip the cross-functional team approach altogether altogether and create a small team of “polyskilled” or “full stack” developers. This means that anyone on the team can work on any part of the system. This can work for certain teams with certain skills, but can take a long time to cultivate. In defining these full stack teams, it’s important to assign operational responsibilities as certain times so that you don’t get into a “since everyone is responsible, no one is responsible” situation because each person thinks that someone else is addressing the problem.