How to split developers/QA into smaller teams?

Question

Our web development company has grown from five to twenty people over a year. We do 2-4 month projects, and usually team size is 2 devs, 1 QA, 1 BA/PM/Scrum master. Our development methodology is Scrum/Agile.

Currently everyone reports to CTO, which is NOT a good way to go for CTO to keep his sanity. Question is - what's the most efficient way to split people into teams? Two approaches emerged:

1. Split people into mini-teams: project manager (who usually is also business analyst) is in charge of 2 devs and 1 QA. The same team does project after project. Everyone reports to PM.

2. Split by technology: have a team of ~ 5 developers who all do Ruby on Rails (for example), managed by senior developer team lead. Then when we get a new project, team lead gets to decide who to put on the project, and it's up to him how to best utilize talent in his team.

Which one is the better approach? Or maybe there's another one that I've missed? All help would be much appreciated!

Answer 1

If you would like to do your business as effective as possible you should keep the teams together even if they may need time for adapting to the new technical challenges of the next projects going to have. Following this, I would go for your first option and have small teams with one leader.

Let's say that a new rails project is about to start, but the rails team is still working on something. Now, you have to have the same discussion again and reorganise the whole organization in order to be able to answer to that demand. Have a team which can solve problems (I'm not talking about people who are experts in everything, I'm talking about a team) and let them figure out with the help of the PM and CTO how to proceed.

If I understand correctly, the CTO was kind of busy but he has been having up-to-date first handed information about the projects. If you introduce a new layer - layer of PMs/SCMs/TLs - this will change and has some pitfalls (misunderstandings, slowing down, longer response time etc.), so in order to avoid it, I recommend to have the CTO as an observer around the teams, participate in the meetings and discussions. Of course, he or she shouldn't go to all the meetings, but at least three visits per week is a must.

Answer 2

You should definitely choose cross-functional teams instead of pools. There are lots of articles and studies about the cross-functional-teams-vs-silos dilemma. For example, you might want to have a little look at Create Your Own Flavor to Become Agile within Your Constraints:

The Team is a Team

In larger companies, a project team may be constructed of team members from a shared resource pool. For example, the QA (Quality Assurance) lead for a project may be from the QA shared resources pool. If such team members view themselves as resources on loan, and not as team members dedicated to the project, the result can be functional silos.

When silos exist, team members are more concerned about the welfare of their team or area than they are with the livelihood of the project. This mentality doesn’t bode well for Agile development and leads to customer neglect. The team needs to bond as a unified group toward the goals of the project. Roles are assigned, but one of the objectives of Agile is for the team to working collectively.

Working collectively can also be applied to team member roles. A tester can point out a possible code improvement. A developer can suggest a feature enhancement. In general, team members speak out—they don’t limit their roles to their titles.

Management should ensure that individual goals include how well employees support the common good of the project.

The (Agile) team must act as one single entity. Team members should be looking in the same direction. That's why you should avoid silos and break existing ones down if possible.

Answer 3

Split your teams into cross-functional non-specialized units. In a good Scrum implementation, a PM should be able to handle 4-5 projects (given that your projects are relatively short in length) at a time. Just make sure your PM is staying out of the day to day workings of your teams.

I don't believe in dev leads. Let your teams self-organize. If they absolutely fail in this you can appoint a dev lead, but if you can avoid it, don't. The best scrum implementations have 1 job title for developers (and yes, that includes all the "QA" people as well).

You say that people participate in more than 1 project at a time. I would really, really encourage you to stop doing this. Assign a project to a team, and let them finish it. Assigning more than 1 project to the same team will generally result in both projects taking longer (due, mostly, too context switching). Unless there is a substantial blocking problem, try to keep it at 1 project per team at a time.

In summation: Create small multi-dimensional self-organizing stable teams with 1 project.

Edit: Why specialized teams are a bad idea

1) Specialized teams are specialized. This greatly limits the agility of your organization. If your dedicated UI team is backed up, but you've got the backend of three projects finished, what do you do?

2) Specialized teams are bad for team members. The more you pigeon hole your team members into specific, specialized roles, the more likely they are to never be able to leave that role. Low levels of specialization within a diverse team is different, as they are constantly exposed to areas outside of their specialization. But when they are locked into a team that only does one thing, they only see one thing.

3) Specialized teams are bad at design. The more focused your teams are on one aspect of your projects, the less likely they will be able to see and understand the overarching design of your project.

4) Specialized teams have to hand work off before the software is working. If you have a backend team, a UI team, and a QA team each team needs to hand off the work to another team, before the software is actually fully functional. Bugs found by the QA team need to be handed back to a different team, which then goes to another team, which then goes.... etc. This breaks the idea of delivering working software at the end of each sprint, and greatly increases project time with all the context switching required.

But don't take my word for it: google "Why multdisciplined Scrum teams"

Answer 4

A group of 20 developers is not too big for a CTO to handle. It should be analyzed where the overwhelming tasks come from, maybe it's not the team management but negotiation of new projects or administrative tasks. It can be interesting to analyze that and introduce improvements to alliviate the work required (new tools and process that for example change the way information is collected e.g. the CTO doesn't enter the information but instead approves and reviews the information entered by others). You should also consider adding a Sales or Biz.Development, if you are a Services-like organization, to help your CTO workload. If your projects are internal the CTO should be able to handle it with the support of the different PMs, this may require that the PMs get involved earlier in the project life cycle.

Said that, you must have a list of the main tasks that are to be taken by the roles that you define. It is important that you differentiate between project related responsibilities and organization related responsibilities. The project related will be temporary will organization related will be more long term. PMs must take the project related responsibilities. About organization, they should go to the CTO. If your projects can be classified in different types (by customer sector, etc) you can have a person responsible for each category if the know-how required is different.

In any case, you should consider creating an intermediate level only if the role is significant enough, other ways it will be dilluted and the person in the position will get lost in other responsibilities that he may take (PM in a project) that give him a better career progression and organization visibility. With the size of the team that you describe I wouldn't create another layer, your company will become too hierarchical and this is one of the worst problems a young organization can bring himself into.

Summarising, optimize the way you work with new tools and processes that make your management requirements lighter and delegate to the PMs as much as possible.

Answer 5

From your original question (and subsequent responses) it sounds like you've got about 10 developers, 4 QAs and 4 PMs plus the CTO. I'm basing this on the 20 headcount, the 5 concurrent projects, and the rough makeup of each project team. My answer outlines what I believe will work from an organisational structure perspective - I think people need a named line manager to respond to issues/concerns. How these roles interact on a project-by-project basis is a slightly different question and is well-covered by other answers here.

I'd suggest you create two or three lead developer roles (if they don't already exist), and get them to line manage 3-4 developers each. Grouping these by technical discipline might be one approach (either by language or type - 'Rails' or 'front-end' for example) but I don't have a strong preference. Then create a head of QA and have that person manage the other 3 QAs. The lead developers and the head of QA can then report in to the CTO, along with each of the PMs. You could create two senior PMs to streamline this further, if needed. That'll reduce the number of direct reports to the CTO, which will free him/her up for more 'strategic' work, and give clear lines of reporting to the rest of the workforce.

For each project I'd allow the PMs to select the team that best fits their project, but these decisions will need to be made in collaboration with other PMs and the CTO to ensure that you have adequate resources to support all of your projects. You might find that the project teams become 'self organizing', in that you will identify particular kinds of projects where a particular group works well together.

Alternatively, the nature of your business might demand that you select 5 project teams in advance and assign them to upcoming projects as soon as they become available. If the former is the case, then from a business perspective, you need to be careful that your client-base is diverse enough that one particular team (e.g. the expert Rails team) isn't overloaded. If the latter is the case you should look at knowledge sharing across your workforce so that each project team is capable of delivering the same standard of work across any type of project - if Agile is already quite embedded then this should be fairly pain-free.