Having a high-performing Agile software development team is like reaching the ultimate state of zen. When you experience it, you just know…
The team works with a subconscious intuition, operating as a unit seemingly knowing what each other is thinking, all guided by a common purpose and product vision.
But how do you get there?
There are core elements you have to get right if you want to create a zen-like, multidisciplinary Agile development team.
What is an Agile development team?
An Agile development team is a multidisciplinary cross-functional group of 3 to 9 individuals who define, design, build, test, and deliver a working software solution in an incremental Agile fashion. At the end of the day, their goal is to deliver value in each sprint ideally in the form of working code allowing for shorter feedback loops to continually optimize and fine-tune the software solution based on end-user feedback.
Great Agile teams blend creativity and technical expertise marrying the needs of the business, the end user, and the technical feasibility of the solution.
Agile team structure
Let’s start with how your Agile development team should be structured.
(Spoiler alert: there is no perfect structure, but there are standard principles you should follow)
As a baseline, you must have the following roles:
Scrum Master
A scrum master is not a project manager. The role is unique to an Agile team.
A scrum master’s main role is to enable the rest of the team to function more smoothly. They facilitate meetings such as the daily scrum, sprint planning, sprint reviews, etc. They coach the team on Agile best practices and help clear impediments. They should be a servant leader to the team and do what is required for them to be successful.
Frequently, this looks like attending meetings that require team representation, writing status reports and providing other project documentation to those that require it, protecting the team from distractions or disruptions, and providing tools, space, or anything else the team needs to be their best selves (dealing with a tough issue, and a dev runs out of coffee? the scrum master should make the coffee run).
Product Owner
The product owner owns the product and is the single point of contact for the development team. If an answer is needed, the product owner provides it; if a requirement needs clarification, the product owner can do that, too. They should handle communication with the end users of the solution, collecting and prioritizing feedback.
In most teams, the product owner should write stories and help the development team refine them, help triage and prioritize bugs, and manage and maintain the long-term product roadmap. If there is a question on how the system should function or what a business need is, the product owner should understand this. They also work closely with business users, team technical leadership, and designers to make certain that work is being planned and prioritized so the team can deliver as seamlessly as possible.
Development Team
The Scrum Guide groups everyone working on delivery under the umbrella of “developer.” This is nice in theory–everyone is on the same footing–but obscures the fact that certain tasks and skill sets are still required. All developers should be primarily focused on, in a software setting, producing working code. This may include writing the code (devs), testing the code (QA), providing leadership and cross-team coordination (sometimes a software architect or tech lead), and owning and supporting one or more areas of domain expertise.
The developers should, as much as possible, be self-organizing and self-sufficient; if there is a skillset or type of knowledge that is needed consistently on a team, the team should aim to have someone on the team with that skill, and if no one currently does, someone should develop it.
This is where the paint by numbers 101 on how to build an Agile team ends. Other factors now come into play influencing what a proper Agile team looks like for YOUR unique situation.
Here are a few scenarios to keep in mind when building your Agile team:
- If your solution has a front-end user interface and requires frequent UI changes or new features, you will need a Designer.
- If your Product Owner needs support writing and refining user stories adding a Business Analyst is a great idea.
- If your solution requires a large number of infrastructure changes, a dedicated DevOps Engineer will keep things in order.
- Some organizations prefer an SDET (Software Development Engineer in Test) rather than a traditional Quality Assurance Engineer. SDETs can code and are capable of providing a deeper assessment of issues, and often times are actually able to fix the issue.
At the end of the day, your Agile team structure is less dependent on your organization size and industry, and more dependent on your type of solution, how fast you are expected to deliver, and where your solution is in its lifecycle.
How big should my Agile team be?
A single Agile team can be small or large. In practice, your team size should be no smaller than 3 and no larger than 9 team members, with 7 being the magic sweet spot. Don’t take our word for it. The Agile Alliance also recommends this range.
The popular rule most go by is the two pizza rule. In other words, two pizzas should be enough to satisfy your team (with normal appetites).
The key is identifying the balance between being able to feed your development team enough work relative to being overworked trying to keep them fed. User stories that is… Not pizza. Finding that balance is essential.
Below is a breakdown from smaller team to larger team providing the minimum, ideal, and maximum Agile team makeup.
| Small | Medium | Large |
|---|---|---|
|
Scrum Master
|
Scrum Master
|
Scrum Master
|
|
Product Owner
|
Product Owner
|
Product Owner
|
|
Developer
|
Business Analyst
|
Business Analyst
|
|
|
Developer
|
Developer
|
|
|
Developer
|
Developer
|
|
|
Developer
|
Developer
|
|
|
QA
|
Developer
|
|
|
|
QA
|
|
|
|
QA
|
One caveat: If you team does require a Designer to create a better user experience, and you have a large team, the 9-team member rule still applies. You should look to reduce one of the developers, QA, or BA with the most likely candidate being a developer.
If you have a need for a larger team, you should look to spawn a new team vs going past the 9 team member upper bound.
Want to know how to approach spawning a new Agile development team? Check this out.
How to get your Agile development team started
So where do you get started?
The first thing to consider is this is a team, and like any high-functioning team, it takes time to gel with the ultimate goal of creating an open environment of trust and understanding of each other’s strengths and weaknesses.
A great framework Agile purists follow is Tuckman’s stages of group development.
1. Forming - Guidance and direction are needed from the manager, purpose and roles are unclear, and efficient processes are not yet established.
2. Storming - Clarity of purpose is established but team relationship dynamics and understanding of how decisions are made are blurry.
3. Norming - As the team organizes around common goals and clear roles and responsibilities, processes begin to optimize.
4. Performing - With a clear vision and purpose, the team delegates and performs well with little oversight.
Once you hit Stage 4: Performing, you are at the Agile state of Zen where every member of the team trusts one another, they understand each other’s strengths and weaknesses, and most importantly they know how to use it to their advantage to build great software that your users will love.
(Don’t be surprised if you start completing each other’s sentences in this stage.)
This leads to one of the most important principles of high-performing Agile development teams.
You should bring work to teams. Not disparate team members to work with.
Once you have a high-functioning team, it is important you keep them intact. Bring them hard problems, and get out of their way.
Otherwise, you are killing one of the greatest bits of equity you have in your organization. The equity realized through a high-performing Agile development team.
6 features of a high performing Agile team
There are a few unique characteristics prototypical high-performing Agile development teams all have. They live by the Agile manifesto, and get the most out of their team.- Multidisciplinary – Each team member brings their own unique skill set and specialized knowledge to the team. Great teams know each other’s strengths and work together toward achieving a common outcome to get the job done.
- Self Organizing – A self-organizing team structures and supports itself. People work together best when they determine their own policies, pick their own team leaders, select their own work, and schedule their own meetings. Why? Because autonomy creates empowerment which in turn creates a high-functioning team.
- Collaborative – Collaboration is a given, but doing it in a high-functioning way is a whole other ball game. True collaboration across an entire team includes open communication, willingness to cross-train and help upskill each other, being open to each other’s perspectives, and most importantly creating an environment built on trust.
- Dedicated – The best Agile scrum teams are dedicated to a single project. Once Agile teams start working across different initiatives and teams, the structure and bond between the team begin to break down as competing priorities and allegiances start to manifest.
- Non-hierarchical – Job titles don’t matter on Agile teams. They work best in a flat structure where people are given the autonomy to work independently and organize as needed. In other words, there is no management or reporting structure in a high-functioning Agile team. They work as a group, helping each other accomplish a shared goal.
- Outcome-Focused – High-performing Agile development teams are focused on achieving an aligned outcome. Not building features because someone said go build these features. They understand the purpose, business goals, desires, pain points, and opportunities of their business and its users. They know their reason for existing in the organization. This gives them the innate ability to solve hard problems with relative ease.
HatchWorks Agile Consulting for Distributed Agile Teams
Building a high-functioning Agile development team is completely worth the effort.
But it is no small feat to improve your team performance. Especially when you have remote teams.
We have seen teams struggle with:
- Frequency, size, and stability of their releases
- Poor visibility into what the team is working on
- Scope the team is delivering doesn’t match user/customer needs
- Software development process
- Experiencing increased team attrition
If you are struggling to realize the value of Agile in today’s remote world – HatchWorks can help you:
- Supercharge your velocity
- Predict with increased accuracy
- Ship the right thing faster
