It’s not a secret that the success of your project significantly depends on the team working on it with you. While expertise and experience are integral to a project’s success or failure that’s not what I’m talking about today.
I’m talking about the organizational structure of the team you will be working with. Asides expertise and experience, this is the most important part of creating a developmental team that works.
We can split the organization of your software development team into two important aspects;
The size of your team.
The roles and positions inside your team.
You probably have a million questions. What is the optimal size of the team? How to assign roles correctly? Are there some variations in software development team structure? Not to worry, I’ll get to all these.
Structuring your development team may be a challenging task but I assure you once you’ve gone through the tips provided in this article you’ll be well on your way to structuring your developmental team with as little stress as possible.
Where Do You Start?
The answer depends on your business specialization and the project you’re working on. For software development teams, create a blend of specialists and generalists with a 3 to 1 or 75% to 25% ratio.
Like any other huge task that’s important to your business, structuring a successful software development team may seem daunting at first. How do you know who you need – Python developer or not? QA or something else entirely? And where to look for them?
Before deciding on all these, write down what business task the team is supposed to solve. Frontend or backend development? What is the team’s role? What’s the best way to achieve the team’s goals? As soon as you have that clear, start shaping the team.
To give you a clear idea of how this all unfolds, we’ll give you a walkthrough of how we do it on our end.
If our task is to finish or fix a project started by someone else, we ensure that we first examine the existing code and understand the complexity of any potential changes. What changes would be made and how would it affect the existing code or the entire project, from efficiency to launch time. For cases like these, all we need at the start is to involve a back-end and front-end developer.
If we need to make test cases, then we call for a QA to backup the project. Meanwhile, if we’re working with a project from scratch, usually two back-ends and one front-end developer, one QA, and one project manager should be enough.
Decide On The Size Of The Team
While it may seem like the bigger your team is, the better and faster it will be for development. This can be true and false at the same time. Yes, it will take less time to deliver a product if you have 6 developers instead of 2. But at the same time, it’s much easier to manage work processes in a team that consists of 5-10 members rather than 15-20.
According to the study by QSM, small teams are usually more effective than larger ones. The reasons for small teams being better are as follows;
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 many people should you include in your team?
To make team meetings as productive as possible, Amazon CEO Jeff Bezos uses the “two pizza rule”. The idea is simple: 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.
Team Lead with relevant experience.
Back-end – Team Lead
Back-end – Middle
Front-end – Middle
Project Manager/Scrum Master
Designer (depending on the project’s tasks)
Choose the Team Type
While building your own software development team, one of the challenges that appears is whether to build a team of generalists, specialists or a hybrid team.
A generalist (also known as a full-stack developer) is someone who possesses a wide range of knowledge and skills and is able to apply their competence across a vast range of areas within their expertise. Generalists can utilize a variety of different resources, perform different tasks and often have stronger communication skills and the ability to quickly acquire new knowledge. You should hire generalists if the product you are developing requires a variety of different skills to be completed successfully.
In comparison, a specialist has a specific set of skills and techniques or a preferred single methodology. A specialist possesses a high level of expertise and the ability to use this methodology while solving complicated business problems in areas where greater attention is demanded. Specialists are better suited for a basic software development team, this way you’re hiring people who are focused on a particular part of development. For instance, database specialist for database, Automation QA Engineer for the automation test suite, Manual QA for manual testing etc.
This is a mix of both the generalists and specialists. This kind of team will focus specifically on areas where your project needs the most work while handling additional tasks if the need arises. They are called a T shaped team and are the best structure for a development team.
Development Team Roles: Who Does What?
So, what’s the plan? What specialist do you need? In what quantities? To organize work processes and assign project roles, we usually use the Scrum methodology. Fun fact: contrary to popular belief, it’s not an acronym. The name Scrum was borrowed from rugby to stress the importance of teamwork. The Scrum Guide describes three important roles:
Product Owner – usually, a project’s key stakeholder;
Scrum Master – a facilitator, a process owner who coordinates the team’s work;
Development Team – a group of in-house or dedicated developers that work on the project together.
Done putting together the team? The next few tips will help you get your team rolling effectively and set them up for success.
Appreciate the power of teamwork: Be smart about identifying your employee’s skills and assigning tasks that match their abilities. But also make sure the team members appreciate each other’s functions in the team and are aware of how their personalities complement each other. The teams’ interrelation will help them achieve more in less time and with less effort.
Find the right people: Recruit individuals who bring varied experience and perspective to your project. The more angles you cover, the better your product will be at the launch and the fewer updates and improvements you’ll have to work on later on.
Learn to delegate: Your job is to make sure all your team members can do their job. Once you’ve set goals and guidelines, let the team members do their thing. Delegate authority and provide access to tools to your development team. Encouraging a bit of autonomy improves trust and confidence in team members.
Track progress: With autonomy comes a love for what you do. And when people like what they do, they tend to get carried away. Your task is to monitor progress and make sure the project stays on track. Provide a means to share concerns, and discuss the project’s status regularly. This way, you’ll see if the team is working well or if you have to re-assign roles.
Avoid micromanaging: Let the team overcome some of the obstacles on their own – under your guidance. Dealing with troubles in a group brings any team closer together and builds confidence among members.
Celebrate little victories: When your team reaches or exceeds a goal don’t forget to give snaps to the team members. This will encourage them to work better and boost team spirit.
Other important rules to remember:
No two leaders;
No people without experience in the domain;
Involve architects or leaders who analyze project at the initial stage.
While the first two pieces of advice are pretty simple, involving architects right away is important so they pave a path for the project to follow starting on day zero. If the architect shows up at some point in the middle, the team may have to re-do some parts of the software.
While the setup and structuring of a development team might be nerve-racking to some, it doesn't always have to be. The steps are simple enough, you need to have a full view of your project or projects for which the team would be working on, then assign roles, map out deliverables or set a roadmap. Work on a means by which issues are recognised and addressed. All these put in place will lead to a structure that gets your dev team up and running in a short amount of time. Plus increase efficiency and meet targets.