What is an agile team, how should it be composed, and why? Understanding how to build agile teams is one of the most critical factors in an agile initiative. However, one should really understand what agile is all about before they start to build teams to support the values and principles of agile.
What Is An Agile Team:
Agile is designed to be lean on requirements, but the team still needs just enough requirements and in-time specifications to successfully produce working code. In traditional software development methodologies like waterfall, software specifications are written upfront and then handed off to a development team to implement. This means that the development team could be composed mostly of developers and it was expected that they would have limited or little interaction with the people that actually wrote the specification. This is not the idea with Agile and it doesn’t work with an agile team because the team starts with very limited specifications by design, often just user stories.
The issue with user stories is they are really just placeholders for a promise that a more detailed conversation will be had during the iteration to define the specification more. What does this conversation part really mean? Is it just some vague and brief talk between developers? No, it is a detailed conversation between products owners, developers, testers, and whoever else might be required to really define what the story is all about. These conversations should be happening everyday on many different stories with all of the people that need to be involved. This is very different from writing the specification up front and handing it off to a developer and as such it requires that an agile team has a different structure than a typical development team using upfront specifications.
While some people think that agile is done without requirements, this is far from the truth. Doing agile correctly means that team is constantly defining, revising, and working on specifications. While the format of the specifications might not include detailed use cases or a lot of UML, the requirements are still captured by some means, like acceptance and use cases. This is done as part of the process each day and as such requires a special team composition to get it done.
Who Should Be On An Agile Team:
In short, an agile team should be a cross sectional group that can follow this define/build/test cycle. It is not just a collection for developers, but a group of people that will work together that can define the domain knowledge, implement the technical details, and test to confirm that is was done correctly.
There is typically 5-7 team members on a single agile team that have a few different roles. The core Agile teams or scrums should be kept small. If you start to put too many people on a team, then activities like the daily meetings, sprint planning, and sprint reviews will become too cumbersome and good conversation cannot happen with the allotted time to cover the stories sufficiently.
Core Agile Team Roles:
The product owner is responsible for defining and setting the priorities for requirements. They help to establish what the theme and objectives for an iteration will be.
Scrum Masters are the glue of the agile team. They keep everyone following the process and help to remove any roadblocks or impediments. They are also a kind of agile team leader, always helping the team to achieve their goals.
Developers write code to implement stories. Stories should have both unit and acceptance tests. The developer should be responsible for ensuring the unit tests are good and passing and to also help to make sure the stories will pass the automated acceptance tests. This means they should be working directly with other team members to ensure the requirements are met.
While some agile teams might be without dedicated testers, they have a place and should be on the agile team if at all possible. They help to define and write acceptance tests and test the stories with additional exploratory testing. They should be working directly along with the developer on the stories for an iteration with a goal to bring them to a completed state.
While these are the core roles, there might be some shared resources on the team like UI developers, business analysts, build engineers, architects and other supportive roles that the team requires.
Agile works well when a team can dynamically define, build, and test stories within a given iteration. Because of the lean nature and limited up-front specification, the teams should be composed of a cross section group of product owners, developers, testers and shared resources that can get stories completed within very short iterations. Composing an agile team of just developers cannot accomplish this and careful consideration for who is really needed on an agile team should be a critical part of any agile initiative.
This article was written by Jason Stafford, Director of Development at Software Allies.