Five types of teams and how to plan for them
Software development is a team sport. While there are plenty of indie developers and solopreneurs out there, most software gets written by a bunch of people collaborating closely.
In the days of Gantt charts and work items, the emphasis was on individual coders. The ticket contained all the info needed to translate the idea from Jira to Java. With the rise of feedback-driven software development, engineers are no longer mere translators. They shape the solution. That requires a lot of communication with other devs.
Rather than thinking in individual coders, we think in teams.
But what is a team?
There is the "sentimental definition" of team. As in: "We're one team. We all build this product together. Look at us go!"
That's a useless definition because we can't really structure our teams if everyone is part of it. A company consists of multiple teams and multiple types of teams. Each type requires a different style of planning. What works for one is counterproductive for the other.
Here are five common types of software teams and how to plan for them.
Product teams
Product teams seem to be the holy grail of software development these days. They own (a part of) a product and are responsible for maintaining, improving, and expanding it. These teams are self-organized and cross-functional. They have a clear, laser-focused mission and all the tools to get there. These teams are typically long-lived and need to build their internal knowledge base.
Product teams really benefit from agile software development and Iterative Buffer Planning.
Project teams
Project teams are a bespoke tool to deliver a well-defined outcome. In the right circumstances, nothing beats a project team. Well-scoped projects with a reasonable iron triangle are the condition for their success.
Project teams are typically short-lived and assembled of the right people for the project's duration. There is little room for building the knowledge base and growing the team's skills. These people are typically more experienced as they must hit the ground running.
Projects require a project management approach with a clear Iron Triangle and well-defined specifications. Project teams don't capture feedback; they deliver predefined outcomes. That means a project manager with a classic Gantt chart is preferable over iterative agile software development.
Agency teams
Agency teams aren't tailor-made for a single project but manage multiple at the same time. They are typically long-lived and require a project manager to keep track of each member's contribution and progress. An example is a team that builds Drupal websites for customers. Agency teams have some advantages regarding knowledge sharing as their projects tend to be similar.
The complexity of managing an agency team lies in satisfying multiple stakeholders. Putting out a fire in one project often starts a fire in another one. An excellent tool for providing enough buffer is to plan the team at 80% capacity. In practice, that means every Friday, developers can explore and sharpen their axes. When a fire needs to be put out, that goes at the expense of innovation rather than other projects.
Maintenance teams
Everybody seems to love greenfield, but most developers maintain existing software rather than building new stuff. Maintenance teams are somewhere between a product team and an agency team. They own a set of live products, but their work is limited to minor improvements and keeping the ship afloat. They need to dedicate a lot of time to building their internal knowledge base as some of those products and technologies are pretty old and scarcely documented.
Maintenance teams work on stable software and rarely fight fires. But they usually support brittle legacy systems that are actively used. They have no room for error. Breaking a stable component will have a ripple effect throughout the company!
Maintenance teams can apply contemporary software development techniques but benefit from old-school quality gated releases. That means test specifications, QA phases, and even slow user testing. They rarely need to deliver fast and should benefit from that by planning ample time for testing.
Task forces
Finally, there's the task force. A rag-tag group of people assembled to solve a problem. While that sounds very similar to a project team, there's a crucial difference: task forces aren't dedicated.
The project team walks in on Monday and knows it'll work on their project all week. The task force starts their week and hopes to find some time for action between all their other work.
Task forces are generally an anti-pattern. It might feel like we really address a problem by dedicating a team to it, but if we don't plan time for that team, we’re not tackling anything. Work for the task force often gets thrown in a backlog that we hope gets picked up spontaneously. We know that's rarely the case.
Instead of assembling a task force, try planning a Focus Block to address the problem. If multiple teams need to collaborate, these blocks can synced.
These are five common types of teams, and each requires a different style of planning. An agile software development approach works wonders for a product team but will be counterproductive for projects.
Picking the right style for the team is vital for creating reliable plans.