Reorganising a development teams as it grows

Question

How do you grow from 6 to 20+ developers and maintain the same productivity? When I started at my company there were only 6 of us doing development. There were no communications issues. Each developer knew the system from top to bottom and was capable of implementing any feature. At the start of each release cycle each feature was estimated and assigned to a developer or several developers based on who was interested in doing that feature. Things were going great and productivity was very high.

3 years down the line things have changed somewhat. The system is now bigger, and more complex, making the 'all rounder' role we all assumed before more challenging. We now have developers whose experience, technical ability and interests vary. As the number of developers grew the communication and cross working became unmanageable. So we were split into 5 teams of 4. Features are now handed to teams to implement, top to bottom. The teams are not specialists in any given area of the product. We've been having a few issues with this setup up so far, which really boil down to ownership:

• Code ownership: As no team has ownership over any given module the design of the system is being compromised. The kind of refactoring that you would expect from someone really knowing the code in a given area are not happening because often a developer/team is in this area for the first time.
• Bug ownership: When bugs are filled against the system they are assigned to a given component. As no teams own modules or areas of the code, allocating bugs is not a straight forward task.

The 20+ number is all developers. We have hired other support staff during this growth phase as well such as QA, Tech Authors, Product support Specialists etc - So I'm asking purely about the development effort. The product we work on is 'shink wrapped' - we're not a consultancy, so time invested in keeping things clean will help us in the long run.

Answer 1

G'day,

I think you've pretty much nailed the main issues already namely code and bug ownership.

I really can't see anyway out of allocating an area of primary focus for each of the teams. Each of the teams would have an area of primary focus. They would still cover all the code as they do now, but they should each have an area for which they are held responsible.

This is the only way I can see that you'll get the team members to take ownership, and responsibility, for the code again and any associated bugs. It'll have to be done in a positive way though so as to minimise any finger pointing battles!

HTH

cheers,

Answer 2

To me it sounds like you are on the right track already as you have split the department into smaller and independent teams. It also seems like you have realized that the good ol days where everybody knew the code by heart is gone and you have to deal with that.

In my humble opinion (individual) code ownership should be avoided if possible. see How to revoke individual code ownership

Since your overall design is in jeopardy perhaps you could assign a member from each team to a design board in change of preventing system rot/ technical dept. Then these guys at least knows what it should look like :-)

Let pretend that you picked Scrum as the way to organize your work. In that case the team members pick they own assigments so all you to do is to assign the bugs to a specific team, and let them handle the issue.

P.S. If you pick an agile methodology you should consider to embed the QA folks in the teams.

Answer 3

I think you need to focus on building the team to have ownership over the processes. That is, the teams have stake in the game. It sound like you are in a good position because you have a solid core group who are the founders. You need them to act as Sensei's or drill instructors to enforce the positive values that the original team had when they built the product.

Not to be to ad esotreica on you, but there is wisdom to the Wolf Credo:

Respect the elders Teach the young. Cooperate with the pack. Play when you can. Hunt when you must. Rest in between. Share you affections. Voice your feelings. Leave your mark.

From Del Getz and Associates

Essentially you need to build a team that not only works on the product, but works on perpetuating the team. I have a blog post if you are interested.

Answer 4

When teams start growing and code responsibility changes the issue with code ownership and architecture deterioration starts. I am all for keeping responsibilities separate so that specialized skill grows. But that creates a problem when a high skilled developer leaves the company. So you always will have to have skill interoperability.

As for you situation with 20+ developers I's suggest the following

1. Create smaller teams with more experienced developers leading them
2. Make the more experienced devs do code review for the areas for inexperienced ones
3. Create a training program, eg.1 or 2 presentations for the newbie to catch up the philosophy
4. Each week spend 1 hr as a team on describing what the highlight of the week technologically for each dev where they say what new things they learned, or how they improved code or speed efficiency in some area
5. Take the Core Architect for 30 minute session a week to say that during code review what are the common mistakes he saw and how they can be fixed, how to proceed with the application architecture, how to do some implementations better

I know many of these are management overheads, but you have to do these as the team grows.

Answer 5

I would start by looking at the architecture of the software product you are developing.

From the fact that there is no code ownership at all I assume that your product is built from a monolithic code base.

1. Create the role of a (Chief) Software Architect
2. Split the software into components or modules, define APIs for their usage. Usually components related to UI, business logic or database/network access can be identified
3. Each dev team has ownership for one or more components
4. Each component is owned by exactly one dev team
5. Each dev team is lead by a senior developer
6. Team lead owns the API of the team's component
7. Each dev team owns the code of their component(s)
8. Each dev team is responsible for the quality of the component (Unit tests on API level)
9. Dev teams communicate which each other through their team leads

Answer 6

If the system has gotten quite complex, then consider dividing things up along one of two lines:

1. Component decomposition. This assumes you could clearly split the application into various pieces that what each team owns is small enough for them to do their part and not worry about things outside in a sense. This is what some others have suggested and makes a lot of sense to me.

2. Function decomposition. Here, while the system stays as a whole, each team becomes a different part on the overall path that software development takes, e.g. one team does requitements gathering, another design & analysis, another implementation, another testing and lastly some maintenance/debugging for the last team. I'm not sure how well this would work, but it is just an idea to consider.