6 Tips on How To Structure a Development Team
It’s not a secret. The success of your project significantly depends on the team that will work with you on it. And now I’m not talking about experience, expertise and talent despite they all play a huge role as well.
Software team organizational structure often affects development almost as much as the factors listed above. But what is it?
Well, basically we can split this concept into 2 main parts:
- The size of your team.
- The roles and positions inside your team.
I bet now you have a million questions. What is the optimal size of the team? How to assign roles correctly? Are there some possible variations of software development team structure?
Keep calm and read on! I promise that everything will become crystal clear after you look through our 6 tips about product development team structure!
👥 # 1: Decide On The Size Of The Team
It may erroneously seem that the bigger your team is, the better it is for the development. Well, it’s true and false at the same time.
Of course, it will take less time to deliver a product if you have 4 developers instead of 2. But at the same time, it’s much easier to manage working processes inside the team that consists of 5-10 members rather than 20-30.
The rule “the more the better” doesn’t work here.
According to the study by QSM, small teams are usually more effective than large ones. Here are their main advantages:
- They don’t face (or face noticeably less) organizational and workflow issues.
- Small teams are quite dynamic: they are easily structured and restructured.
- They are able to work more independently.
- It’s easier to set communication and coordinate the efforts of fewer people.
So how much people should the small team include?
To make the meetings as much productive as they can be, Amazon CEO Jeff Bezos uses the “two pizza rule”. The idea is simple as that: if you can’t feed the whole group with 2 pizzas, the group is too big.
Nowadays the same tip is often being used to define the optimal application development team structure and size. Therefore, the best option is to limit the team to 5-7 people.
But what is to be done if your team has more members? That’s what our next tip is about!
✂️ # 2: Split Big Teams Into Smaller Ones
Of course, the tip above doesn’t mean that you have to fire everyone until there are 7 people left in your company. For example, as of 2017, Uber had about 100 iOS developers and still managed to organize the working processes.
What you can (and should) do is to restructure one big team into a few smaller ones.
Describing their experience with Swift, Tuomas Artman (the tech lead for architecture and frameworks at Uber) said:
Maybe the positive message here is that you will probably not run into problems if your team is small.
However, keep in mind that with the increasing number of teams you will need another manager. This person will coordinate the work not only within groups but also relative to each other. Otherwise, there may occur the situation when separate teams will work on the same feature without even knowing it.
Speaking of coordination...
📝 # 3: Arrange Your Teams Properly
The good software team organizational structure also includes an adjusted workflow. It means that every team member should know his exact duties and scope of work very well. In general, the Scrum Team looks as follows:
However, we're talking now about the structure of your development team. Basically, there are 2 main types of team structure in software engineering that we want to share with you today. Take a look!
One Team For Everything
|For whom?||For a small company (up to 10 people)|
|When?||When working on a small and relatively simple project|
|Strong sides||Easy to supervise. Plain and clear structure. Fast and direct communication between members.|
|Weak sides||Responsibilities may be unclear. The larger the team, the more difficult the management.|
This is the common software development team structure of young small startups that can allow assigning only one team per project. Yet, it doesn’t mean that this model is bad.
The main idea behind this approach is simple as that: you just don’t split your squad into sub-teams. By holding the whole team together and working on one project you can bypass possible communication breakdowns and keep your dev team structure plain.
This model works well with both Agile and Waterfall approaches. It means that you can either plan big releases and wait until everyone does his part of the work or make small frequent releases as you develop.
Here's how such a software team structure may look like:
As your company grows, it will be impossible to manage all the processes within one big team. A new solution will be needed. And goal-focused squads may be the example of an appropriate product development team structure.
|For whom?||For companies with over 10 employees|
|When?||When working on several projects at once or/and when working on a big and complicated project|
|Strong sides||Distributed responsibilities - each group clearly knows its’ own field of responsibility. It’s possible to work on different areas of the product simultaneously.|
|Weak sides||More complicated structure. Possible difficulties in communication. Now you must not only control the process within groups, but also coordinate them.|
This approach requires splitting your team into a few separate but still fully functional and independent groups. Each of them is working on a certain area of the product.
Since every group may have a different scope and working pace, this dev team structure is best suited for Agile approaches. It makes the teams even more goal-oriented and allows to do releases independently from other groups.
Take a look at how this development team structure may be created:
Yet, the team will never be independent and effective if you don’t build it and assign roles correctly. Our next tip is just about that!
👨💻 # 4: Decide On Who Should Be In The Team
We’ve already emphasized the importance of splitting a big team into a few smaller ones. But how do it correctly? It’s not about putting 5-6 random people together and calling them a “team”.
First of all, try to keep your teams balanced. A so-called “whole team” (meaning that it can shepherd nearly any functionality from start to finish) usually includes:
- 1 UI/UX Designer.
- 1-2 Front-End (or Mobile if you craft an App) Developers.
- 1-2 Back-End Developers (if needed).
- 1 QA Expert.
- 1 Project Manager.
Of course, this list isn’t exhaustive and some variations depending on your case are possible.
Secondly, pay attention to roles within the team. Your aim is to create the squad that will work as a single unit. For this purpose, some roles have to be assigned.
For example, you will need someone to be a “team lead”. Do not confuse this role with the manager - it’s not the same thing. The team lead is responsible for making the whole team succeed and often acts as a coach.
It’s better to assign the team lead in each subteam. Yet, if your application development team structure isn’t too branched, it’s ok to have only one person at this position.
Once you have several development squads, you will also need a chief architect. This is the person who coordinates all your teams, builds consensus around architecture and design, and oversees the maintenance of the general concept.
🔀 # 5: Feel Free To Change Up The Teams
Another important thing to understand is that you can freely change your teams when you need. I mean people, not the software development organizational structure itself (yet it may change, too). It can either happen occasionally (for example, if you need to review the code in another sub-team) or on a permanent basis. Some even say that it’s better to move people around teams regularly.
Here are some typical situations when it can be useful to reshuffle developers and change your software development team structure:
- Before starting a new project.
- Because of the reduction or increase of the number of employees.
- When a sub-team faces a task it can’t solve. Yet, this situation can be avoided due to competent project management.
- When the team shows low performance.
- According to the needs of the particular project.
Also, always try to assign people to the projects that match their interests. Strong initiative sometimes is as important as experience.
😄 # 6: Always Take Care Of The Organizational Climate
Last but not least. The psychological conformity of workers in the squad can mean a lot for the project.
Pay attention to how employees get along with each other. Try to solve any conflicts within the team as soon as possible and encourage cooperation and the spirit of partnership.
Developers also should feel free to build upon ideas of their coworkers. This is particularly important for heavily collaborative Agile development.
So, these were our 6 tips on how to create an effective application development team structure. Let’s briefly remember them:
- Decide on the size of your team and don’t be afraid to split it into a few smaller ones.
- Choose the most appropriate structure depending on the project: either one team for everything or several goal-focused squads.
- Correctly assign roles according to the software development team hierarchy.
- Try to co-locate your developers in one office.
- Feel free to move developers between teams.
- Take care of the organizational climate.
Try to follow them during development to achieve the best result. Good luck!