The Agile Manifesto values “individuals and interactions over processes and tools.” One of the signers’ key principles is, “The best architectures, requirements, and designs emerge from self-organizing teams.” I agree with these principles but am pragmatic about what self-organizing teams should be in practice and how much decision-making authority helps teams achieve their best results.
For example, empowering a team to select their ideal architecture and design may optimize the team’s performance, but 20 teams managing independent architectures is highly problematic for the organization.
I also believe that processes and tools must amplify individuals and interactions. Capturing backlog status, categorizing user stories to standards, and documenting architectures help improve how teams interact and reduce people’s time in meetings.
Agile self-organizing teams need capacity planning
One area that many agile teams are averse to is agile capacity planning. Capacity planning means different things to different people, so asking for a capacity analysis or planning for skill gaps requires context. Also, capacity planning practices were developed from program management and system engineering disciplines that some view as anti-agile practices.
The challenge is that many agile teams’ needs, such as people, technologies, and partnerships, require forward-looking projections because of the necessary lead time to procure, onboard, and integrate. Agile leaders should view capacity planning as an opportunity to improve productivity, avoid frustration, gain support for devops investments, and reduce blocks and barriers to their objectives.
Other times, agile teams must partner with business stakeholders and provide visibility to their upcoming deliverables. Capacity planning is part of this equation because it can impact the teams’ velocities and productivity. While adding developers, increasing system resources, or instrumenting process change may not increase the team’s deliverables in the short term, these things can provide longer-term flexibilities.
Different contexts and analyses are part of capacity planning. Here are some questions agile teams should collaborate on answering.
How much work can the team complete this sprint?
Teams practicing scrum aim to commit to what they can get done during the sprint and strive to maintain consistent or growing velocity. Kanban teams have a more fluid workflow, but their stakeholders still want to understand the team’s forecast on user stories, requests, and tasks.
The first level of capacity planning is done at the team level, and it helps agile teams answer how much work they can finish in a sprint or short time interval. Data-driven agile teams estimate their work and often use story points as an aggregate measure of the work’s complexity and effort. The team’s velocity is the story point total of work completed in a sprint, and this metric helps teams gauge how much work they can reliably commit to at the sprint start. Teams leverage sprint burndown reports to track their progress, and scrum masters help resolve blocks that impede the team’s progress.
How many features can the group schedule?
Estimating and measuring velocity helps teams deliver reliable results every sprint, but product owners and business leaders also want forecasts of what features and capabilities will be developed and deployed in upcoming releases. They want to know the team’s capacity to accomplish all the features and capabilities prioritized on the backlog.
Agile teams need more than just-in-time planning to forecast releases. One approach is to use agile continuous planning to estimate multiple sprints of backlog and use this estimation to debate priorities and scope. Large organizations adopting the Scaled Agile Framework (SAFe) use Program Increment planning to review capacity, plan sprints, and understand team dependencies.
These planning and road mapping forecasts rely on teams estimating and maintaining a consistent velocity. Sprint and short-term planning are important building blocks for agile teams looking to collaborate with business leaders on capacity planning.
How many people are needed?
Sprint and release forecasting are bottom-up, tactical approaches to forecasting, planning, and delivering on business priorities. But many organizations often operate top-down, with strategic goals identified and leaders asking questions like:
- What skills and how many people are required to achieve the strategic business objectives?
- What is the forecasted timeline to complete the targeted scope of work?
- How can additional investments in learning, people, partnerships, or technology accelerate the timeline?
- What are the risks to the timeline, and what steps can the team prioritize to mitigate the high-likelihood, high-impact risks?
- What costs are associated with different planning scenarios?
Many agile teams I’ve worked with over the years cringe at these questions because they are inherently non-agile. Getting people in a room to sort out these issues, develop forecasting spreadsheets, and produce planning scenarios disconnected from the realities of day-to-day development and operational work can seem like a waste of time.
But keep in mind, it’s through this planning that business decisions on investments and priorities get made. It’s better to know ahead of schedule that adding a team, doubling the number of people with specific technical skills, selecting implementation partners, or increasing a program’s scope to address technical debt will be reviewed by decision-makers.
What systems capacity is required?
Strategic planning often focuses on financials, people, skills, and timelines. Systems capacity planning focuses on the infrastructure required to develop, test, stage, and deploy new capabilities. Some systems capacity questions include:
- How can increasing the size of testing environments decrease the time required to run automated tests?
- How many new development environments are needed when the team plans to increase the number of people developing software?
- Should ops scale the infrastructure or review the architecture because of growing app usage or increasing data throughput?
- Will any technology components reach end of life or require major upgrades in the near term?
- Will changes in regulations or compliance require application upgrades or architecture changes?
Answering these questions is usually the responsibility of IT ops or enterprise architecture teams because they are all areas that impact development priorities. Agile teams also have the expertise to weigh in with development estimates, dependencies, and implementation options.
What technologies, process changes, or partnerships can improve productivity?
Strategic planning and systems capacity planning are often conducted top-down by departments like the program management office, IT operations, enterprise architecture, information security, risk management, or others. But proactive agile development teams and devops organizations will turn the tables and become active voices in these dialogues.
Business leaders want to know what will increase team velocity, improve productivity, make it easier to hit deadlines, address quality gaps, or increase deployment frequency. Take advantage of capacity planning to formulate the team’s “ask” of what’s needed to be more successful, and articulate the benefits of investments.
For example, CI/CD (continuous integration and continuous delivery) and IaC (infrastructure as code) automation improve the reliability of deployments and are also key steps to increase deployment frequency. Tying these investments to business goals helps align business leaders on why and when to prioritize devops practices.
The next time IT and business leaders schedule a strategic planning meeting and want to discuss capacity, think through what devops needs to deliver on business priorities, and address capacity gaps. Capacity planning can be a win-win for agile teams that want to mature planning and estimating disciplines, forecast capacity gaps, and prioritize their recommendations.