11

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!

  • 1
    You don't specify if the different team members take always the same role, e.g. a PM in Proj1 may be a developer in Proj2 reporting to another PM or can a developer or tester be involved in more than one project at a time. This would help to provide a more specific answer. – Picarus Sep 14 '12 at 7:38
  • 1
    Different team members always have same team roles - i.e. if someone is a developer on one project, they won't be a PM on another project. But - people DO participate in more than one project at a time – Ant11 Sep 14 '12 at 13:16
  • Who normally acts as the Product Owner? The CTO? – Andrew Clear Sep 14 '12 at 16:15
  • @aclear16 - right now, yes. However, we're in process of hiring additional Business Analysts to act as Product Owners – Ant11 Sep 17 '12 at 0:45
7

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.

  • Thank you for the answer. The CTO definitely will still participate in projects, even if as observer. The main problem with his time is he's serving as a BA and PM for all the project, and all developers/QA report to him, which leaves him no time to do longer-term CTO tasks. We identified that issue and will hire more PM/BA's ASAP - my question is, though, what's the most efficient structure to split the team once we hire those PM/BA's. – Ant11 Sep 14 '12 at 13:19
  • I think Zsolt answered what would be the most efficient structure, Ant11. Create teams of people who stick together, who have one team lead, and who solve problems. There is no Rails team, in other words. Programmers, smart programmers, should be able to adapt to whatever is thrown at them. – jmort253 Sep 14 '12 at 14:41
7

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.

  • Cross-functional, non-specialized teams are the only way to go. – Andrew Clear Sep 14 '12 at 16:04
5

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"

  • +1 - If I could upvote this 10 times I would! The part about specialization locking people in is so true! – jmort253 Sep 15 '12 at 1:12
1

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.

  • 2
    As a CTO in question, a group of 20 people is DEFINITELY too much for CTO to handle :) We're also talking about 5-6 different projects at a time - this is a custom web development business. When 20 people constantly ask questions related to their projects, it's pretty clear that those questions should be answered by PM/BA/SCM. So we're definitely going to split teams into smaller ones - 5 people per team max. My question is - what's the most efficient way to do this? – Ant11 Sep 14 '12 at 13:37
  • 1
    Got to agree with @Ant11 here. 20 line reports is crazy. The team won't be getting the support they need from the CTO and the CTO won't be getting anything else done. – Willl Sep 14 '12 at 14:51
  • 1
    I understand that if you have PM then you don't have 20 direct reports. I can tell you I have worked in organizations where a manager had 25+ people on their group. I must say that it was an organization that promoted initiative and trust on engineers. In your case, you need help on the business part and allow your PMs to interact with the customer and biz/sales people. You may be also been affected by sudden growth in your organization and hence need to evolve. Consider some help on organization and methodologies temporarily. – Picarus Sep 14 '12 at 19:45
1

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.

  • It would be really helpful to know why this got down-voted. Happy to receive some constructive criticism but I don't think this answer met the suggested reasons for a down-vote on the FAQ – Willl Sep 14 '12 at 16:14
  • I downvoted because I think advice to create specialized teams is 100% the wrong approach. However, you're probably right that it doesn't meet the guidelines for a downvote. Please make an edit to your post and I'll remove it. – Andrew Clear Sep 14 '12 at 16:47
  • @aclear16: I really think you should provide some reasoning as to why you downvoted, i.e. what's your suggestion? Since Will's comments were just a suggestion, I think the only way to contradict him would be to provide some kind of factual information or reference. Can you provide us with something to validate the downvote (instead of asking Will to edit his answer?). My point being is that it's good to disagree, but I'm dead against downvoting if it doesn't meet the recommendations provided in the FAQ (Will has provided the link). – JohnJ Sep 14 '12 at 18:49
  • Oh, the edit request was because my vote is locked unless the post is edited. I should have clarified that. I agreed that it didn't meet the requirements, that is why I asked for the edit. The edit doesn't have to be anything, just add a whitespace or something. – Andrew Clear Sep 14 '12 at 19:34
  • blah...now I feel like an idiot :) – JohnJ Sep 14 '12 at 20:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.