So you’ve got the green light to build an agile team. Congratulations! Building an agile team is an adventure for everyone involved.
This post is intended to provide steps you can take in order to build a self-organized agile team while also accelerating the value of self-organized, cross-functional teams from the moment they become a team.
Why is this important?
Cross-functional teams deliver working software within one team and one sprint, every sprint. Self-organizing teams increase quality and reduce risk by owning responsibility for maintainable, sustainable and fit for purpose software.
Valuable working software, every sprint, shouts of a self-organized and cross-functional team.
These suggestions assume that you…
- Are early in your agile adoption with no active grassroots teams
- Have buy-in from invested people in your organization to form the team. If your organization has a phased approach to product development, you may need to drive alignment and win sponsors for your Scrum trial before forming the team
- Accept the scrum roles, dedication and responsibilities as described in the Scrum Guide. The scrum roles are structured to “optimize flexibility, creativity, and productivity.” It’s tempting to compromise but think about what you’re giving up!
1. Choose the Product for the Team
Start by defining the product or feature the team will support.
A cross-functional team slices through more than one “layer” of software development to create working software each sprint. A good example is an online event registration tool with front-end UI, and service, database and security layers.
If this kind of slice is daunting for super specialists, choose a simpler product with more than one layer. Regardless, the team must independently produce working software of that product to avoid bottlenecks and provide value every sprint.
If you cannot slice your products vertically, you will need more than one sprint for truly valuable working software.
2. Select the Product Owner
The next step in building the team is selecting the Product Owner, a single dedicated person who is responsible for maximizing the value of the product and the work of the team.
Choose someone who can work closely with stakeholders, is empowered to make product priority decisions and can spend about 75% of their time with customers and stakeholders, and 25% of their time with the team.
The Product Owner’s first duty is to create a product vision and an initial high-level product backlog. The backlog should have enough detail for the team to decide the skills, platforms and tools they need to build it, and be clear enough for stakeholders to understand the most valuable high-priority backlog items.
The Product Owner is the only one who can express requirements and priorities to the team.
3. Build the Development Team
In a Scrum development team there is one title for everyone on the team: developer. Specialties exist, like testing, business analysis, coding and other distinctions, but the whole team is responsible for developing the working software each sprint, hence: developer. A cross-functional team is made of people with one or more deep specialties and a few skills in other areas.
Team size should be determined by the specialties needed and fall somewhere between 4 and 9 plus a Scrum Master. This balance is achieved through the team-forming session that follows.
Harness the Power of Volunteers
In scrum, the organization or the Product Owner may choose the team. Either way, it’s a valuable opportunity to make self-organization and cross-functionality implicit values in the development team. Start by using volunteers. Invite more people than needed from each specialty, like QA, UI, coding and BAs.
Invite, at a minimum, people who….
- Can be fully dedicated to the scrum team
- Can be co-located
- Have managers who are willing to participate
4. The Volunteer Team-Forming Session
In this session, include the Product Owner and qualified volunteers. Others may observe. The session should result in a self-organized Development Team of 3 to 9 people with all the skills necessary to deliver the working product every sprint, and a Scrum Master.
Here is a framework to consider for your session:
- Clarify the product scope: the Product Owner introduces the product vision and initial product backlog for volunteer questions
- Whiteboard time! The volunteers….
- Catalog the necessary skills and concentrations to build the product
- Assess their own skills against that catalog
- Volunteer themselves in or out until the best 3 – 9 person combination emerges
- Note any gaps between skills needed and available on the team
- Plan for acquiring or learning those skills
- Align on what they need from a Scrum Master, and choose accordingly from volunteers present
- The Product Owner welcomes the new Scrum Team and they decide when to begin initial Product Backlog Refinement
This framework is flexible to allow for facilitator creativity.
Self-organization doesn’t always come naturally at first. Expect some fear, intimidation, uncomfortable silences and reluctance to volunteer or self-promote. Take heart. Awkwardness doesn’t last long. The end result is a volunteer Development Team that thoroughly understands the product, the team’s strengths, and supports their Scrum Master.
Organization challenges are real, especially early in Scrum, and this may seem intimidating or unattainable right now. Take stock. Make a list of impediments, then challenge the underlying assumptions. Talk to invested people in the organization. Examine your true potential to empower volunteers. Calculate the value of self-organized, cross-functional agile teams and then go build them. The value is clear and you may inspire the organization about what’s possible.