In many recent conversations I have found myself discussing the dilemma of what is the correct number of team members for an Agile team. Many books, instructors and pundits have recommendations based on what flavor of Agile works best for different organizations. But with that question ever present lately, I find myself more reticent to offer an immediate answer. Instead, some questions come to mind:
How many people do you currently have on the team(s)?
What experience do they have?
What experience or expertise do you wish they had on the team(s)?
If you could structure your team(s) however you wanted, who would be on that team?
How many people do you think should be on the team(s)?
Is the team missing anything?
Is the team stagnant?
What can help them make the changes they need to be more efficient?
Without fail there are discussions about efficiencies had an inefficiencies that exist in many different areas. Discussion then ensues that someone believes they need to look at adjusting down to a certain number of people because they aren’t progressing or up to a certain number of people because they don’t have the right expertise always present on the team. And then comes the $64,000 question… How would you split the team(s) if you did it?
The key for any successful team is not the number of people on it, but it is how well they can work together. Having 5-9 people on a team doesn’t ensure success. You need to determine what will they be responsible for and what level of ownership they will have with a product line or project during it’s life cycle. Creating a team that just does new features will not teach them the value of doing the job right and making it easier to maintain. Creating a team just to fix bugs of already deployed code will sew resentment and disdain for other team members or teams that have a “more prized” assignment. Ask yourself a few questions:
How would you split up responsibility of the product into features or functionality?
What areas would you group together to provide concept to cash responsibility to a feature based team?
Who would be on the team(s)?
Is right now an advantageous time to make a change with team structure?
After answering these questions, remember that you don’t just change your team structure because Agile says there is a certain ideal team size. Make the change because there are truly benefits that can be achieved by organizing the teams correctly. Harness the power of change for your competitive advantage and that’s how you will see increased success within your teams.