Scaling software development teams

Question

I've been reading on this subject for a while now, but still can't come up with a workable solution for my situation to scale a development department. May be someone can advise me on where to go from here :)

I am in charge of the whole software development department in my company. We have 35 developers of different skill sets split between 2 offices. Most of them are backend developers, 5-6 do front-end (like JS), 3 do slicing, plus a few team leads. Right now I have 4 teams responsible for particular "products" or areas, with a lead assigned to those. All software that we develop is web based: websites, services, tools, etc.

Challenges that I'm facing right now:

• Workload is not even across all resources of the team. There are teams when someone has not enough work, while others are overloaded
• I need to bring in, say, 10 more developers within the next year to accommodate ever growing needs for development. This poses challenge in splitting of responsibilities even further.
• half of the people are not cross-functional
• about 20% of time is spent on bug fixes
• another 10-30% of time is spent on small improvement and feature requests (say, requiring 2-15 hours of work each to implement)
• projects that are running are iterative in nature, usually not exceeding 3-4 weeks when done right. Sometimes dragging for 2+ months if there is too much back-and-forth on small changes, improvements, or bugs

We don't have external clients, so that removes the contractual pressure and such, but still I need to be able to plan ahead :)

I've been thinking about splitting teams by the areas of expertise (say front-end, slicing, back-end, etc) but pretty much the whole Internet tells me it's a bad idea.

Looking into project-specific teams, but quite short project timelines, and quite large proportion of ongoing small requests poses a challenge here (how do you do bug fixes in this model after release?)

Most of the advice is for smaller (5-15 person) teams. We've grew past that, and I think managed that phase quite well. Now this next step is a whole new ball game.

Answer 1

This is a pretty big question that might create a lot of advice, but I'm sure there are also nuances that we will not get here. There are also multiple questions and challenges embedded into your question so I'm going to answer generally.

You are right that grouping by areas of expertise is considered a bad idea as now no one group of people actually has what they need to be responsible and deliver a full feature. It can create siloing and a lot of throwing over the wall or even overwhelming situations for again groups that end up being the dependencies for every other team. I would agree that in general most software companies scale by creating groups of people that can be responsible for full value delivery or they have everyone and everything they need to be responsible end to end as much as possible. I suspect any other "agile" person will answer much the same way.

Here is also a nice article from Yammer on the subject: http://firstround.com/article/Why-Yammer-believes-the-traditional-engineering-organizational-structure-is-dead

No person can be 100% utilized either. The question is how could they be helping their team instead, even if it is a task that they might be a little slower on. People may have to change the way they work or how they do they work in order to scale well.

All this centers around organizing yourself around OUTCOME vs. OUTPUT. How do you deliver high value, high quality products, not just get a lot done and increase lines of code?

On the challenges, you might consider which ones are business realties and which ones require changes. Which ones are creating the biggest pains? Maybe go after making small incremental changes to address one challenge and see if it works. Repeat.

I've never seen a growing company not have to challenge some set culture and ways that they work in order to create good growth. You can't take what you have and mush it into a new mold. It may challenge some people for awhile and even create some pain, but with your eye on the ball and goals of what challenges you hope to fix, check in and see if it happens.

Be iterative with your change too.

Finally, over communicate about what you are doing and the challenges you are trying to solve and rally people behind the effort. If they don't also see the need or value the change, you'll create bigger challenges. They have to be apart of the change since they are the ones having to do it even if you are deciding it in some way.

For basic change advice, you might check out "Leading Change" by Kotter.

Answer 2

Erin has some great general answers. I'd like to add a couple specific suggestions based on the set of projects I've been running. The situation is similar to yours in many ways(needing to use a set of people to handle ongoing maintenance, small change request, and new development... and needing to bring new members on from time to time). The usefulness of my suggestions might be dependent on what your company's culture is like and how your people are split across the two locations.

To deal with on-boarding and increasing cross-functionality: One of the things I've found that does this best is pair programming. Even if you don't want to use pair programming 100% of the time, it can be useful to do it for a short (couple weeks to a couple months) time period to ramp people up. Pairing lets your new hires get on-hands training with your processes and tools at the same time as they are learning your code bases and coding styles. But one of the keys I've found to this is that unless you have some people that are natural teachers, you will want to pair new people up with people that are only a few steps ahead of them in ability and knowledge. The reason for this is that while your most experienced people likely have more that they could share, they are also likely to be far enough removed from being "new" that they overlook some of the basic building blocks that your new people will need to pick up (learning to use your particular work item tracking system or code repository for example). This also helps reinforce the knowledge in your person doing the training. This works for both completely new people as well as if you are moving people around to increase cross-functionality.

To deal with work items with different levels of service and varying work loads: I'd suggest looking into kanban with daily standups. Kanban is great for providing visual controls across work items with different rules depending on the service level of the item in question. Team members can see at a glance whether there is a high priority bug fix that needs to be addressed or a code review for a different team member that they should take care of before starting on a new feature. Combining with daily standups helps teams naturally talk about where the pain points are in their processes and address them, or deal with any blocking issues. One of the keys to using kanban effectively is that it shouldn't look the same over time, as it should change depending on what pain points the team runs into and addresses.

Answer 3

Lots of facts that need to be brainstormed. I will focus on the bullet points to hopefully give you enough to think about. In some way it feels like I had the same issues a several years ago.

• Workload is not even across all resources of the team: Try to figure out the root cause of it. My problem was that the each individual was the owner of a specific area in the product. If that is the case you have to make sure everybody in the team understands that the "team" is the owner. If someone is idle then she has to step out of her comfort zone and deal with other areas. Start with pair programming initially and have everybody in the team to handle all tasks. If the team is idle then it is ok for the team. It means they don't have work to do. If half of the team is idle then there is no collective ownership or a lack of know-how.
• I need to bring in, say, 10 more developers...: If you have fixed teams it is much easier handle it. Decide min and max size of your teams. When a team is growing then you have to split the team and create a new one. If you have min 5 people then your could create a new team by moving 2 from one team and 1 from other teams and the newcomer. Never put more than one newcomer in a team and have them pair programming. Assign a mentor for a period of time, if possible, until the newcomers finds their way in the organisation.
• Half of the people are not cross-functional: This is a painful situation. You have to get them more cross-functional, if you think that it is an issue. Or maybe you should consider in a different distribution of skill set among the teams.
• 10-30% of time is spent on small improvement: You could create a special team that handles those. Rotate (every month or 2 weeks to start with until you find the proper duration) people in and out of this team from the rest of teams. Have everybody go through it and do frequent retrospectives to make sure it works. Do not rotate the all of the team at once. The transition has to be smooth.

I advice against teams by the areas of expertise or project-specific teams. Create teams that will stick together and grow an identity outside of a project and an expertise. Name your team based on colors or fruits or something else. Have them prove to the rest that they are the best team in the company. Even if you create new teams keep the original ones, to not loose identity, just like in sports having people moving from one team to another.

Answer 4

This is a pretty standard problem. I have seen it in a lot of larger organizations and projects. A classic approach is a matrix organization where people are grouped by functional skills and assigned to projects. It is difficult to get this right as one of the organization structures tends to win out. If you can manage to keep the balance, you may get better flexibility within projects.

The functional organizations should deal with items related to the skill set. This can included things like coding standards, skill development, tool selection, and career progress. You may want to leverage them to provide cross project review. These are the organizations which should be growing staff skills and improving your processes.

Th project organizations deal with delivery and draw resources from the functional organizations. Your maintenance team(s) could fall into this structure. These are the organizations that will deliver or fail to deliver results.

Growing the team will increase management and communication overhead. Bringing in new staff with lesser skills and experience will enable you to develop them to work well in your organization. Bringing in new staff with more skills and experience can be disruptive. Try to use that disruption to improve your delivery processes.

Maintenance tends to grow as your portfolio of completed projects grows. Retiring old projects which are no longer useful can help with this.

Using common tools, libraries, and processes should help with overall productivity and reduce maintenance costs. Having one component routine which delivers a functionality makes it much easier to fix a bug in that functionality when you have dozen such components spread across half a dozen projects.

Implementing tools which review your code can improve quality and eventually reduce maintenance costs. Fixing existing problems may create an initial increase in maintenance costs. You can use tools to:

• Identify duplicate code. (Multiple components doing the same thing.)
• Find common coding errors.
• Identify code which doesn't follow project/organization standards.