12

Given a 15x strong software development team working on individal projects, and small, medium, and large projects; what is the best way to structure this team and what is the best software development methodology?

Background:
The department was previously made up of:

  • CTO
    • Support Development Team (1x lead, 2x support devs)
    • 4x Developers

The department grew to 10x developers so a decision was made to separate into 2x dev teams of 5x developers each like so:

  • CTO
    • Team 1 (1x lead/manager, 4x developers)
    • Team 2 (1x lead/manager, 4x developers)

The department uses Scrum, each team having its own sprint cycle (synchronized).

Now that the department is much larger, a new restructuring needs to take place. A few problems have been identified:

  • Fixed teams are problematic due to individual developer's silos of knowledge
  • Promoting developers to lead/admin/line-management roles results in loss of essential developer resource

We also have a PMO consisting of 3x PMs and 2x BA. This team is separated from development (not ranking higher or lower, but aside) and falls under the operations department (COO).

Using Scrum has its problems:

  • No dedicated support team means maintenance has to fall into a Scrum team. This doesn't work so well. (A KanBan team could be more appropriate for support).
  • The company takes on bespoke work from lots of clients, resulting is mixed release dates, mostly not fitting the sprint-release plan.

My thoughts

  • I think a more responsive methodology would work better (but I'm no expert here - I'm a dev/lead), and on per project basis rather than per team.
  • I think the development teams need to be more fluid, build per project rather than a fixed Nx developers per team. Line management becomes a problem here. Technical leadership and line management become a problem here due to lack of appropriate resource/time.
Improve this question
9
  • 2
    flem, What are you trying to accomplish? What are the teams supposed to do? There are many ways to structure teams, with different structures being good for one thing and other structures good for meeting other goals.
    – Mark Phillips
    Commented May 20, 2013 at 1:26
  • 1
    The main goals are: rapid development, high quality, for lots of projects. Some projects require only one developer where others (fewer) require 4 or 5. Average project would require 2-3 developers.
    – Paul Fleming
    Commented May 20, 2013 at 9:07
  • Since you are a dev/lead, do you have influence on your CTO (i.e. is this question of practical value)? Can somebody else take the bulk of administrative chores thrown upon the leads so that they can concentrate on their teams? Lack of dedicated maintenance in your department is a strong disadvantage... You can also try smaller teams (gives flexibility between teams, retains good morale within them).
    – Deer Hunter
    Commented May 20, 2013 at 12:54
  • @DeerHunter Yes, this is a practical question. Admin chores are a big part of the problem. Leads are full time devs, scrum master, and line managers. This ends up with leads working excessively long hours.
    – Paul Fleming
    Commented May 20, 2013 at 14:17
  • Maybe you need a pool of administrative assistants to take away the routine tasks from the leads... Hiring an assistant is much cheaper than overworking a skilled lead into asylum.
    – Deer Hunter
    Commented May 20, 2013 at 14:21

3 Answers 3

Reset to default
9

Have you considered a Squad system? The always-excellent Henrik Kniberg has an article that you may find useful on how this system is used at Spotify.

The basic principle is as follows:

  1. Vertical multi-skilled (product, development, design) teams work on a single product or area of product development (e.g. infrastructure, customer feedback) - these are known as Squads.
  2. Horizontal skill-based groupings (e.g. PHP developers, Front-end developers) cross-cut the squads - these are known as Chapters. Each has a Chapter Lead who (usually) takes line-management responsibility for everyone in their Chapter.
  3. Special interest groups (e.g. Agile project management, Testing) cross-cut both chapters and squads - these groups are known as Guilds and each has a Guild Lead.

There are some similarities with a matrix management system, which you may also want to investigate.

Disclaimer: I haven't used the squad system, I just think it might be a good approach for you!

Improve this answer
1
  • Thanks for the link. This is very interesting. I intend on investigating it further.
    – Paul Fleming
    Commented May 23, 2013 at 15:22
7

TL;DR

TANSTAAFL. If you want to scale, you need to add more teams. However, if you add more teams, you have to manage the additional complexity and communications overhead that comes along with that.

Direct communication channels scale poorly. The formula is generally expressed as N(N-1)/2. If you don't have a project management model that addresses this critical fact of communications complexity, you will have a great deal of trouble scaling.

Teaming Options

Scrum teams are project teams. While good teams often stay together to work on subsequent projects to avoid the overhead of forming and norming with a new group, it's not a framework requirement. However, if you have multiple simultaneous projects you have a capacity problem, regardless of your chosen methodology.

Task Switching

Task switching is always a problem. Even if you choose a different methodology than Scrum, you still have to packetize and prioritize work in such a way that each unit of work minimizes cognitive switching. That means that asking a single developer to work on different tasks for different projects (even if the tasks are sequenced rather than pseudo-parallelized) will be less optimal than allowing the developer to work on one client's project at a time.

Accept Work Based on Capacity

The real underlying issue is that you have prioritize client projects, and scale your processes as you require more capacity for more client projects. Your organization should not accept more work than it has available capacity to accommodate. Prioritizing the project portfolio is going to be senior management's job, not the job of the project teams, so this issue doesn't impact you directly.

As for scaling, a Scrum of Scrums is generally the right tool for the job if you're a Scrum shop. If you use a different methodology, then you need to use the scaling functions of that framework instead. The point, though, is that communication between teams becomes harder and more complex as you add teams; that's almost axiomatic.

The best way I know to solve the knowledge-sharing issue in a complex Scrum-of-Scrums environment is to ensure the Product Owners add inter-team training and education stories to their Product Backlog. This provides opportunities for cross-pollination between teams and reduces the silo effect, without destroying the nature of the close-knit teams themselves.

Improve this answer
6
  • Capacity is currently not a problem, and we can scale up to support more projects. The main problem (I think) is that we don't have enough leadership to manage the higher capacity. Should we have a full time manager "head of development" for all line management/HR duties, allowing team leads to focus on the project(s)?
    – Paul Fleming
    Commented May 20, 2013 at 14:21
  • @flem - team leads should be saved from paperwork, but not from managing their teams.
    – Deer Hunter
    Commented May 20, 2013 at 14:30
  • @DeerHunter Is it a good idea for a team lead to be a line manager? I.e. is Scrum master a line manager?
    – Paul Fleming
    Commented May 20, 2013 at 14:31
  • We generally try to avoid people reporting to someone on their team where I am. Keeps a distinction between line management and leadership and helps keep retrospectives more honest I think.
    – Ben
    Commented May 20, 2013 at 14:46
  • @flem - looks like it (line management for team leads) is subject for yet another question.
    – Deer Hunter
    Commented May 20, 2013 at 14:48
2

Look into how Menlo Innovations in Ann Arbor, Michigan works. I think they are similar to what you are trying to do.

  • About 70 people doing bespoke work for many clients
  • Everyone pairs, and pairs change weekly - lots of knowledge sharing
  • One week sprints
  • eXtreme Programming practices
  • High Tech Anthropology (something they invented)
  • Projects are formed from pairs, so it is easy to scale up and down as needed

See the book Joy, Inc. which was recently released. It was written by Richard Sheridan, a co-founder of Menlo Innovations, and describes the Menlo Way. They also do tours of their shop and offer classes for those interested in learning the techniques. http://www.menloinnovations.com/

I've never worked there, but I do know a number of people associated with the company and I am a fan of how they work.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.