Team Predictability in Agile Environments
Agile is increasingly seen as a must-have for tech companies. With advantages including flexibility, faster delivery, and more room for creativity and innovation, Agile allows organizations to develop new products and features without massive upfront investments or risk. But, while Agile is immensely valuable for development, developing in short iterations with no planned work and only a backlog of desired features makes team predictability difficult.
Unfortunately, these predictions are often necessary for stakeholders, investors, and even customers who might need to know where you’re headed and why. While you’ll never be able to make Agile teams as predictable as Waterfall teams, you shouldn’t have to. Instead, you should be able to design operations around team predictability.
Working from a Backlog
Agile teams should always work from a backlog of desired features or changes. Doing so in a predictable fashion means establishing those backlogs, assigning technical debt, and actively working to link those items to business objectives. This may require tying in both long-term business objectives from the business plan and short-term feedback and goals from customers through customer-service and sales.
Developers need to know what they are working on and why, and you must be able to track that work to business objectives. This also means establishing standardized measures or KPIs to track how and what developers are creating.
Establishing Predictability Metrics
Team predictability depends a lot on what you want to measure. Depending on your organization and its goals, you might want to predict turnaround time, quality of work, or rate of innovation. In most cases, the actual value of each of these statistics will heavily depend on your organization and its structure.
Cycle Time – Cycle time can show predictability but this will heavily depend on the size, difficulty, and quality of work items.
Sprint Value – Measuring value produced per sprint might allow you to predict average turnaround, but again, this heavily depends on organization, structure, and how work is organized and distributed.
Quality – Measuring the quality of work (hopefully from a customer perspective) will give you an idea of what teams are doing.
Maintenance vs Innovation – Measuring whether teams are performing routine maintenance or creating new things and new value for customers is important for predicting what and how teams are delivering.
Clear Communication During Kickoff
It might be surprising to hear that many team delays aren’t related to bad code or poor solutions. Rather, they’re related to teams having a poor understanding of what they were solving when they started. Any team needs a clear understanding of what they are building and why before they begin. Once you’ve established a clear backlog, sharing that information with your teams is crucial.
Stakeholders must have channels in place to communicate what they want or need to developers. Using standardized communication channels and investing in longer and more intensive kickoff sessions with stakeholders are two strategies to ensure teams understand what they are working on.
Sharing Estimations with Stakeholders
Agile teams are not designed to share precise deadlines and output expectations. Instead, you should always communicate in terms of backlog and team objectives. Stakeholders can make decisions based on backlog, while understanding that work and therefore output can and will change based on technology, what happens while the team is working, and the market.
Improving Team Predictability with Operational Framework
Vision to Value shares an operational framework designed to help tech organizations structure the organization, teams, and development to create consistent, quality, and predictable delivery. Structuring teams around desired output, creating measures for continuous delivery, and implementing measures such as quality gating and automation are all crucial to long-term predictability in Agile development environments.