With basic team model MSF team scales up well up to 15-18 persons. If you try to keep MSF routines, number of your developers is about one third of the headcount (in a mature project). 6 developers – that doesn’t sound very impressive. Common sense suggests that there has to be a way to scale it up. And common sense is right here. For example team working on Visual Studio 6.0 was using MSF. I bet there were more than 6 developers.
There are two ways to scale up the team:
• You can build small sub-teams based on slightly changed basic team model and give them a feature or a module to work on. It’s called a feature team.
• Basing on basic team model you replace single role with bigger team with every member working on just one or a couple of tasks the role covers. It’s called a function team.
With feature teams you don’t need every role from team model. Product management works on higher level, not on the particular feature. You don’t release single feature so you don’t need release management. You need program management, development, testing, in most cases someone fulfilling the user experience role and sometimes architecture. Basing on a feature team you can build small, agile (what a trendy word) sub-teams with a leader who is program manager, architect (if needed) and user experience guy and a bunch of developers and testers.
It’s very effective model inside the team. However, nothing is perfect you need more effort to integrate software prepared by feature teams. Interaction between sub-teams is also a bit more difficult. Remember, it this case there’s our module and their modules. There’re potential conflicts between leaders of feature teams, so it requires a very knowledgeable and experienced program manager on the top. She’ll be resolving misunderstandings and disagreements between the sub-teams. Generally, the better program managers you have, the better this model will work.
Function teams replace MSF roles with teams, which are more structured than roles in basic model. Typical example takes user experience team and gives different persons following tasks: usability testing, UI design, training, internationalization, support etc. Of course a team lead is also here. It’s like team of specialists. Problem with this model is that it’s hard to build function teams for some roles. Good examples here are development and test. List of tasks is rather short here, so building function team would look a bit artificial.
Nothing stands in the way to mix those models. Some time ago I worked in a team developing ERP system. After some time we outgrown basic model (we didn’t really suited to it anyway), so some reorganizations were implemented. The team ended up with feature teams grouping program management, development and architecture and with a function team covering user experience and testing roles (I know I’ve just said that’s not good idea). Feature teams was built around program managers who were strong on the merits – when building ERP solution you need to know legislative and has a lot of business background. Two MSF roles (user experience and testing) were grouped into the function team. There were standard tasks everyone was responsible for, but in emergency situations team was able to regroup and resolve most problems fast. Switching tasks between people within one big function team were much, much easier than between two feature teams. It worked quite well that way.
I learnt one very important thing than – the key is to have good leaders. It wouldn’t work if there weren’t right people leading all those sub-teams. What more, every team required different set of skills from its head. Our big boss thought about predispositions of his people and set the team in a way that exploited their strengths – that’s why we had rather untypical function team with testers. I strongly believe that it’s the right way to build and scale MSF (and every other) team up. People first, than organization.
Whole MSF Basics series