Life is pretty good when CIOs, CTOs, and technical digital trailblazers can perfectly staff agile teams with the leaders and teammates needed for the prioritized objectives. Unfortunately, in my decades of working with agile organizations, it’s actually pretty rare to have a perfectly aligned staffing model.

So leaders must make compromises and tradeoffs in trying to fill gaps, meet stakeholder demands for new capabilities, and address technical risks in the development process. I say CTOs because, in StarCIO Agile, they and the agile delivery leaders reporting to them are responsible for assigning people to teams. In large enterprises, PMO may have this responsibility.

I debate organizations that assign agile team assignment responsibilities to product managers and owners – but that’s for another article one day.

Staffing the leaders of agile teams

Before we get into some of the issues, let me share some principles of assigning people to agile teams. First, let’s start with leadership principles.

• Agile teams should be co-led by a product owner and a technical team lead. Product owners define who, why, and priorities, while the team lead answers how, how well, and how to mitigate risks.
• Allocate a scrum master to newly formed teams, teams with limited Scrum experience, or teams struggling to meet their goals. Many experienced agile teams that collaborate well should be able to meet sprint and release commitments without a scrum master.
• Assign a business analyst to a team when there are complex business and non-functional requirements. BAs can take over story writing responsibilities when product owners are less technical or have too many customer-facing commitments. BAs are also helpful when teams develop more technical products like APIs, AI models, or other data services.

These four responsibilities form the nucleus of a scrum team. They collaborate on writing user stories, setting clear priorities, releasing capabilities, participating in change management, and capturing end-user feedback.

StarCIO Agile requires all teams to have a dedicated product owner and technical team lead. Scrum masters and business analysts are assigned by leadership to the teams requiring them the most.

Which brings us to our first and most important mistake when assigning team leadership.

Don’t assume those with Scrum certifications and agile experience in other organizations are ready to take on agile team leadership roles in your organization.

Every organization should develop its agile ways of working, principles, and standards. Generic certifications and training don’t cover the organization’s approach. Also, previous experiences may not align with the organization’s values, culture, compliance requirements, and transformation objectives.

Agile team structure

Now let’s consider the strategy of how leaders create agile teams.

• Agile teams should be aligned to customer segments, products, or reusable capabilities (like APIs and microservices). Aligning teams this way ensures clear definitions of customer, end-user, stakeholder, and business objectives. It helps multiple stakeholders align to a vision statement, understand release strategies, and agree to a balanced product roadmap. Avoid creating or overstaffing shared service teams for technology platforms, and avoid dedicating full-time teams to perform upgrades and patching.  
• Teams should be staffed with the skills required to complete the targeted work, including QA. In general, and contrary to many DevOps evangelists, I avoid assigning any ops responsibilities to an agile team unless they are working on POCs or early pilots. Agile teams with ops responsibilities can also work in small organizations and early-stage startups, but not in most IT organizations. Why? Agile teams that have ops responsibilities tend to shift more time and effort to ops, impacting priorities around development, innovation, and technical debt. Additionally, it’s really challenging to define and comply with cloud and other operational standards when there are many agile teams. So, in general: Don’t empower agile teams to be operationally self-sufficient.
• Agile teams should include all participants, including business ones, and not just the technologists. Most business programs require business people to take on work, such as marketers, legal, finance, risk management, and others. Why is there work managed outside of agile teams and frameworks? Manage them separately, and now the organization may need separate project managers, or worse, don’t manage this work and expect business participants to get their contributions done when needed. Don’t create a business-IT division by enabling non-tech work owned by business people to be managed separately from the agile program.

Leadership mistakes when assigning people to Scrum teams

Now, let’s consider basic principles in forming agile teams:

• Two-pizza-sized teams, including the team leaders. I generally translate this to teams between 5-10 people and no more than 12. Don’t create larger teams when there aren’t enough team leaders for staffing them, or to try accelerating the team’s velocity, or to manage releases that require many technical skills.
• People are assigned to one agile team. Some organizations try to pull off assigning people to multiple teams when there’s a shortage of skills in a technology. Don’t assign people to multiple teams because it’s challenging for the developer to split their time, and complex for team leadership to plan reliable releases.  
• Delivery leaders (in partnership with team leads, CTOs, and PMOs) assign people to their teams. Organizations perform team reassignments only twice a year, usually once after the yearly budget is approved and then approximately six months afterward. Don’t try to realign people and teams too frequently, as this sets back the team’s collaboration, estimating, and other working practices required for predictive agile delivery.

Don’t make these agile leadership mistakes

Here’s a recap of my top seven leadership mistakes when assigning people to agile teams:

1. Don’t assume those with Scrum certifications and experience in other organizations are ready to take on agile team leadership roles in your organization.
2. Avoid creating or overstaffing shared services for technology platforms.
3. Don’t empower agile teams to be operationally self-sufficient.
4. Don’t create a business-IT division by enabling non-tech work owned by business people to be managed separately from the agile program.
5. Don’t create teams larger than 12 people, including team leadership.
6. Don’t assign people to multiple teams.
7. Don’t try to realign people and teams too frequently.

How to avoid agile leadership antipatterns

A number of real concerns spark these leadership mistakes or antipatterns. Here are five common ones:

1. Budget factors that limit the number of people required to staff leadership roles or teams.
2. Lack of training or time for learning prevents people from developing technical or leadership skills in areas with the greatest business needs.
3. Legacy technologies, applications with significant technical debt, and a lack of regression tests can trap organizations. They create an environment where only a limited number of people are trusted to make changes.
4. When IT faces too many ill-defined priorities, it forces agile leaders to spread resources too thin instead of optimizing teams to focus on the most essential business needs.  
5. Belief systems, especially around DevOps practices, focus on “ideals” rather than aligning teams based on business priorities.

Addressing the leadership mistakes and antipatterns can’t be achieved with a one-size-fits-all approach. So, I can share StarCIO principles, but transforming requires a tailored program.

For some starting points, see three of my other articles:

• What high-performance IT teams look like today
• Three ways you can empower high-performing agile innovation teams
• Drive a transformative culture with diverse leaders and empathetic teams

At StarCIO, we deliver center of excellence programs that focus on developing leaders and transformational best practices tailored to the organization’s goals, culture, and staffing. Our approach includes a mix of leadership, learning, and advisory programs that guide teams on developing standards, cultural principles, AI innovations, and excellence with technology platforms. Reach out to StarCIO to learn more about our programs.