Published in


Agile: Different Team Structures

When it comes to writing software, there are many different ways in which you can structure your teams. Within agile and scrum, these teams should be cross-functional and made up of the different skills sets needed to deliver new products and features. For example, the developer, tester and designer should sit within the same team. In essence, a team should be entirely self-reliant and self-managing, so that they can regularly ship software without being impeded by external teams.

This is different from what you might encounter in some enterprise companies, which tend to group teams up by their disciplines and then move around ‘resource’ to different projects when needed. In this scenario, there would be a test manager, who looked after a team of testers and a development manager, who looked after all the developers. Besides the impersonal approach of thinking of people as a ‘resource’, there are some major downsides to this method, which we will touch on in this article.

Forming, Storming, Norming, Performing

This is an old concept, which comes from an article written in 1965 by Psychologist Bruce Tuckman (Developmental sequence in small groups). The phrase describes the typical lifecycle of a team and the different phases it goes through. It goes without saying, that the objective is for teams to be performing. The problem is, however, every time we form a new team (usually by breaking apart other ones), we start this whole process again.

Anyone who has tried starting off a company/product from scratch will understand just how much extra work it takes to get things off the ground. You can’t lean on the maturity of an existing organisation/team and some time must be spent ‘forming’.

Depending on the personalities and working styles, the storming phase can last for long periods too. If you are not careful and don’t manage things properly, it might not even end! This can often happen if teams are too big, there is a high level of chaos or team members conflict with one another.

As a team goes through the cycle of continuous improvement with the retrospective, lots of learnings will be gained along the way. A body of wisdom will start to form within the team; not just around the code, but also about how people work together. The team will transition into norming, followed by performing, increasing their effectiveness.

In summary, we need to make sure our teams last for long periods of time and therefore we should build them around areas that are long-lasting. Breaking them apart and forming new teams with every project will cause this cycle to start all over again and throw away all our hard work. Even by moving a single team member, this will no doubt have an effect on the ‘Forming, Storming, Norming, Performing’ process.

Team Size

Many of you might already be familiar with Amazon’s two-pizza team concept. This states that no team should be bigger than what two pizzas could feed. One thing that is sometimes forgotten and what Martin Fowler (agile manifesto signatory) points out in one of his excellent talks is that we are not just talking about the scrum team, but everyone needed to go all the way to the customer. Therefore this size should include people like a product owner or account manager.

Another rule of thumb that tends to work nicely is that a scrum team should be 6 +/- 2 people. If teams are too large, then it becomes hard to maintain focus and you will more than likely work on completely different areas or goals. This makes it almost impossible for team members to understand what is going on and therefore you can’t really expect any kind of serious commitment from them to deliver. Early on in my career, I worked on a scrum development team of 13 people, which when I look back at it now was just ridiculous.

On the flip side, if a team is too small, then you waste time with the ceremonies and overheads of any development process you might be using. People going on holiday becomes more of an issue and there probably isn’t enough knowledge across the company in what this small team are doing. Only you can decide the right balance.


One of the key motivators of any team or individual is having ownership over what they do. I have written about the importance of this already in my article, The Unspoken Hazards of the Retrospective. Without ownership, it is unlikely the teams will perform well, let alone improve over time. In general, though, people tend to be more happy, especially in the software world when they can feel like they have created something (and even better if they can show it off).

If you have ever worked in a team which creates lots of spikes for every new feature, then you have probably come across the consequence of teams not having proper ownership. This approach of raising lots of spikes just isn’t needed by teams that have ownership over certain areas. You don’t waste nearly as much time, and you can be more certain about your estimates. This, in turn, reduces uncertainty and provides more accurate expectations of release dates.

You can, of course, get the same problem with long-lasting teams, if you constantly switch them between different areas, products or features. No one becomes the expert of anything and lots of time is wasted with constant unnecessary learning.

In our team structures then, we should really take ownership into account.


So onto the different structures…

Product-Based Teams

In this approach, we base the team around the product within the company. This happens to be one of the most common, as it is easy to understand from a business point of view. A product tends to be a desktop, web or mobile application. You can see it and understand it, but it probably has dependencies to services or databases managed by other teams (especially in larger organisations).


  • Easier to group technical skill sets together.
  • Full ownership over the entire product means that there is less need for coordination between teams in regards to the technology stack.


  • May require more coordination between different teams to deliver a ‘feature’.

Component-Based Teams

This is very similar to product based teams (and has the same pros/cons) but deals with changes in modern software architectures. Gone are the days of monolithic architectures where a product was entirely encapsulated. A large or distributed product might, therefore, be made up of lots of different components. These might include:

  • Desktop/Web/Mobile Applications
  • APIs / Microservices
  • Batch/Stream Processors

Feature-Based Teams

Split by different features, that might span across multiple products/components. This tends to align better with the objectives of the business or a user story created by the Product Owner. A common scenario to implement a new feature would involve updating a web front end, an API service and a database. It might also be, that on larger products, different teams are responsible for different feature sets.


  • Works well with agile methodologies who want to implement incremental features, from end to end.


  • If resources (such as data stores or caches) are shared between features, then there is ambiguity on who owns it.
  • No ownership over the chosen technology stack for a product, as multiple teams can be working on a single product for different features.

Domain-Based Teams

Splitting by domain contexts is similar to features but is data-driven. A product or even a feature may be made up of very different contexts.


  • Best suited when moving towards a domain driven, service orientated or microservice architecture.


  • May require more coordination between different teams to deliver a ‘feature’. This will also require more technical knowledge to divide out the work.
  • There are parts of the solution which will not nicely fit into contexts, such as stream processors, batch processors and queues.

Legacy Organisational Structures

One of the challenges in your organisation might be that your business/product team structures do not align themselves to the desired technical structures. For example, traditional projects managers will want to think of things in terms of projects, but as I have pointed out, this really is not the best way for teams to work.

This can cause friction and it is often the case that we descend back to the method of creating/destroying teams so that project managers can work in a way they understand; that is, we end up with project-based teams again. As explained in the lean startup, it is often the case that working the most efficient way for you is not the most productive way for the company. So we really want to avoid this at all costs. Remember, the continuous improvement cycle isn’t just for the development team, but the whole team from development to customer.

This is an excellent place for product owners or business analysts to facilitate the transition from one way of thinking to the other. For example, in the above scenario, a project which spans multiple products, could have the work funnelled into the backlogs of multiple product-based teams by the POs or BAs. ThoughtWorks have published an excellent article on their transition from Project to Product for one of their customers.

The last thing any busy person wants is yet more red tape to go through. If you can avoid the need for translation in the first place, then this is fantastic. But this is not always possible.


How you structure your teams and divide out the work is entirely based upon how your organisation operates. From a technical point of view, your engineers are going to enjoy having full ownership over what they make. You will see returns in not only their productivity and enthusiasm but also the quality of the solution.

You might want to ask yourselves, what drives changes within the business? Does it tend to come from a product perspective? Or is it mainly driven by a feature perspective, which needs to be implemented over multiple products. An example of this might be a new consistent UX design between products. Your answers to these questions will help you decide on the best way to form your teams. But you will also need to take into account your technical architecture and skill sets available too.

Coming Soon: Part 2

In the second part of this article, we will discuss how you can funnel work for the different team structures in more detail. We will also address the imbalance of work, which can sometimes present itself.

Please share with all your friends on social media and hit that clap button below to spread the word. Leave a response of your pros/cons for different team structures. 👏

If you liked this post, then please follow me and check out some of my other articles.


Matthew Bill is a passionate technical leader and agile enthusiast from the UK. He enjoys disrupting the status quo to bring about transformational change and technical excellence. With a strong technical background in Polyglot Software Engineering, he solves complex problems by using innovative solutions and excels in implementing strong DevOps cultures.

He is an active member of the tech community, writing articles, presenting talks, contributing to open source and co-founding the Norwich Node User Group. If you would like him to speak at one of your conferences or write a piece for your publication, then please get in touch.

Find out more about Matthew and his projects at

Thanks for reading!



The fastest way to build your next app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Matthew Bill

Technical Leader | Agile Coach | Polyglot Software Engineer | Solution Architect | DevOps Enthusiast | Speaker & Writer |