A team must be small to remain agile. The smaller your team, the fewer instances of miscommunication you’ll have. Plus, it’ll be easier for you to resolve issues that come up on a daily basis. That’s because in smaller teams, people typically wear multiple hats; you usually won’t need to gather five team members eight times a day just to make a decision.
Based on my experience, I think the optimal size of an agile team is seven people, made up of the following roles:
Project Manager
Project managers are responsible for…
Creating and updating a long-term roadmap and weekly sprints. They also coordinate work between team members so that everyone spends their time efficiently and on useful activities only.
Why they’re important:
Scrum adepts tend to rely on developers and designers to communicate and plan, but I think that approach just doesn’t work. Experts need to spend time on what they excel at. It’s a project manager’s job to tell the experts when they’re too deep into the rabbit hole and need some help. Good project managers will tell you in advance that your project is behind schedule and that you need to cut features and adjust your roadmap, saving everybody neurons and gray hair.
Business Analyst
Business analysts are responsible for…
Analyzing and describing the requirements of the system they’re working with. To team members, they’re a source of honesty revolving questions about how something should be done. Sometimes, they also do data analysis to better understand data and requirements.
Why they’re important:
Business analysts are rare in agile teams because they’re considered an unnecessary luxury in the enterprise world. That’s probably why most agile projects lack documentation and most teams lack a common understanding of what they’re doing. (Lacking that understanding, by the way, is completely normal. It’s the job of an analyst and project manager to make sure that everyone is on the same page.) If you have a diverse team and need to communicate requirements between more than two people — which, most of the time, you do — you need someone to write those requirements down and think them through. A good business analyst will save you a pile of money by asking the right questions and adjusting the requirements in the analysis stage, when changes are nearly free.
Team Lead
Team leads are responsible for…
Making high-level technical decisions about the system and its various parts, as well as establishing the patterns of how individual pieces will be built. In other words, the overall architecture of the system. As senior developers, they also work on features, review code that others write, and act as someone you can trust to make technical decisions on your behalf.
Why they’re important:
A good team lead will make your developers want to work with you forever. They’re also technical enough to be able to tell other developers what to do, but have the soft skills to explain to you and other less technical team members what tech problems you have and ways to solve them. A team lead can be your CTO, or you can hire a team lead as a contractor. Just make sure your hire isn’t fresh out of college and has no experience leading a team.
QA Engineer
QA engineers are responsible for…
Testing your product for bugs. They clean up the messes that developers create (or at least spot where the messes are) by testing an app thoroughly and periodically — either manually or by automating the process.
Why they’re important:
Like business analysts, QA engineers are rare in agile teams. That’s probably why most agile teams have to deal with tons of bugs. Even if you have rock star developers who have been working for Google since, like, forever, they’ll still have bugs in the code they write. Especially if they’re rock stars; those are the kinds of developers who focus on creating clever solutions for complex problems. Rarely do they test code to make sure that it’s error-proof. The best part about having a good QA engineer is that they’ll save you long hours responding to a user’s bug reports after a Friday night release. (Tip: Don’t deploy on Friday night.)
UI/UX Designer
UI/UX designers are responsible for…
Creating and refining the design of your product interfaces, animations, and microinteractions.
Why they’re important:
You need a UI/UX designer because developers can’t just make up an interface while they’re coding features in an email. Well, they can — but the interface will be far from the sleek design you’re hoping for. Ever seen a DIY car? They’re built by engineers who know what they’re doing, and while the cars are fast, they’re rarely good looking. That’s because you need to have a trained eye for design to make a good-looking car. Some developers have that eye, but I wouldn’t count on it. A good designer will be able to make development efficient by not creating unnecessary work for developers. And they’ll make users want to use your app again and again because of how pleasing and rewarding the experience is.
Developers
Developers are responsible for….
Building a product. I recommend having at least two developers: one backend and one frontend or mobile dev. You can hire someone who is full-stack, but I personally prefer to work with people who specialize in certain technologies and are also familiar with others. (This is called a T-shaped professional, as far as I can remember.)
Why they’re important:
Because a team lead is usually also a developer who’s busy working on features in addition to going to the meetings, thinking about long-term goals and reviewing code, you need the support of two developers to help you build your product. It might seem strange that in a team of two developers, there are five people doing other things; but from my experience, it works. It allows developers to focus on what they do best — developing features. When they get clear and well-thought-out requirements, detailed mockups and a clear plan for the week, and can rest easy knowing they don’t need to care about testing, they spend 100% of their time on what’s important: building the features you want them to build.
That’s my dream size and composition of an agile team. Would this work for your team? What changes would you make, if any?
Originally published on Medium
