There is no doubt that having a cross functional team will increase your chances for success. When the team is able to resolve their own issues and complete the work needed independent of external dependencies, the fault of delays fall onto that team. Being cross functional empowers the team to better control their fate. But that is where most organizations fall short. Not only do you want to have cross functional teams, but you want to have cross functional team members. Let me explain.
What does a Cross Functional Team look like?
A cross functional team has the necessary skills to deliver product features end-to-end. In the example of a web application, it will involve people who have database, middle tier, and presentation tier skills. If the application is graphic intensive, a graphic designer might be part of the team. If the team as a whole, can cover the skills needed to deliver end-to-end features for 90% of the project, then the team is cross functional.
What about Subject Matter Experts (SMEs)?
The SME is someone who is an expert at a particular field or subject, where that skill is needed for the project, but does not quite need continuous involvement with the team on a daily basis. Typically, these skills are around architecture, legal, marketing, and operations. Depending on the app, you may want to staff your team to have one of these SMEs as part of the team. Something to help you decide this is this question, “How often will the team go to this SME to complete a feature end-to-end?” If you find yourself needing to go to this SME regularly and frequently, then consider making them part of the delivery team.
Okay, but what is the big deal about cross functional team members?
We have described cross functional teams, but cross functional team members is a different concept. A cross functional team may be composed of a DBA, two developers, two testers, and a graphic designer. For most end-to-end situations, the team would be able to implement potentially shippable features. In practice, not all features will require such an even distribution of skills. That is to say not all features will be 17% database work, 33% development, 33% testing, and 17% ui.
A cross functional team composed of cross functional team members may consist of 5 engineers. Each engineer has skills in databases, development, testing, and ui design. The strength of each discipline will vary among team members, but as a collective whole, they have the skills to get things done. More importantly, everyone can contribute to each discipline.
This helps mitigate risk when in one iteration, you have unbalanced work. At the beginning of a project, there may be more database work needed than ui. In the middle of a project, you might need significant database work because a design flaw was discovered and some refactoring needs to be done. If you only have a cross functional team, then your DBA will be overloaded. If you have cross functional team members, those members can help contribute to the database workload. This approach also supports Kanban development methodology.
Divide, Conquer, Swarm
In action, this is how cross functional team members would operate.
Divide. The team would strategically divide up the work that needs to be done for a feature such that it would play off their strengths. Having people do areas of work where they are strong will produce faster results. You also want to make sure you create opportunity for cross training (paired development). Pairing with the strong-skilled team members will help elevate the skill on the team.
Conquer. With the work divided, the team would attack the pieces with full force. But it is not just all about getting your piece of work done. Along the way, talk a lot with others and integrate as much as possible. Get those data access calls hitting the database. Wire up the UI with the presentation and business logic. At a minimum set up the interfaces so the feature is making calls all the way through the call stack, even if the logic in the middle isn’t there yet.
Swarm. As one group (pair) completes their work, they will move on to help their other team members get their work done. If the database work is done, help out the data access group. Maybe they need help with unit tests, or implementation. Perhaps coordinating with the tester on the use cases that need to be supported. The goal is to swarm the other team members with overwhelming support and assistance. This will also foster a strong team motto of “We’re all in this together”. You will have bottle necks, but this swarm technique will help eliminate the bottleneck. This is only possible if you encourage cross functional team members on an already existing cross functional team.
If you staff your teams as 3 developers and 3 testers, where the testers are not allowed to write application code, you’re setting yourself up to have bottlenecks. If developers can’t help write tests…bottleneck. If your DBA goes on vacation…BOTTLENECK.
