One way to achieve better-performing teams and better business results is by adopting an Agile Program Management approach, which coordinates and scales work across Agile software development teams. Many companies incorporate Agile practices, but to see transformative, bottom line results you need to apply Agile at scale. For enterprise companies it takes a ‘team of teams’ working together to deliver your largest, most complex, and highest-value initiatives, on-time and with the value your customers want.

But scaling agile across teams isn’t easy. It can’t be accomplished overnight — it takes time and investment to transform how you work. However, if you put metrics in place to measure your work and progress, you’ll be well on your way to building a fast, agile software delivery engine. 

Inspect and adapt

Once you’ve made the commitment to scaling Agile and have launched an Agile program, you’re likely to find that the performance of your teams is inconsistent. As a result, you aren’t getting value out the door in a reliable, predictable way.

> See also: Busting the myths of agile development

Agile development is inherently a process of continuous improvement. Agile teams use retrospectives to inspect and adapt their work, incorporating qualitative insight to improve how they go about their work. However, at scale, qualitative insight alone is insufficient. To build a program consisting of multiple high performance teams, you also need appropriate quantitative insight. A good way to think about it is this: If you have more than one team, how do you know which ones to focus on?  And, how do you know what they need help improving? 

Appropriate measurements that let you benchmark each development team’s work can provide key insights that improve performance, both within and across teams. Following are some guidelines for how to successfully introduce measurement into an Agile development environment.

Decide what to measure

The best metrics feedback is balanced. Rather than focusing on just one area of performance, your feedback should come from all four key outcome areas of a project:

• Do it Fast (productivity, responsiveness)
• Do it Right (quality, customer/stakeholder satisfaction)
• Do it On Time (predictability)
• Keep Doing It (employee satisfaction/engagement)
• Gather the right data

Many organisations put a tremendous amount of effort into gathering data without first making sure that the model they’re using to analyze that data for actionable insight is a fair representation of reality — not to mention appropriate for the context. To avoid this mistake, it’s critical to invest in the right skills and expertise that will allow you to carry out context-appropriate analysis.

> See also: Future shock: the race to embrace agile development

The process of gathering metrics must also be practical. If gathering the data is costly, time-consuming, or onerous for your developers to record, you’re asking too much. Developers are a valuable asset: you want to keep them focused on the job at-hand. The value of your metrics should always exceed the perceived (and actual) burden.

Know your business drivers

When laying out your measurement strategy, you need to understand your economic model: meaning, what’s most important for you to achieve. For example, in the healthcare industry, quality may be the most important dimension: companies with quality as their driver may be willing to sacrifice performance gains in favour of high and predictable quality. However, if you’re a startup developing a game for mobile, performance may be your most important dimension.

Considering business outcomes first can also help you clearly define what’s important to you. Measures are only useful if they lead to better insights, decisions, and ultimately the outcomes you are looking to achieve.

Be careful how you use metrics

Be careful not to use feedback as a lever, however. The key to effective Agile metrics is to think of measurement in terms of feedback, not as the traditional lever to motivate behavior. Using measurement as a lever often devolves into keeping score, which is where the dark side of measurement starts.

There is a subtle, but important, distinction between ‘feedback’ and ‘lever.’ Feedback is something you seek to improve your own performance. Levers are used to influence others. The difference is in how you use the measure more than the measure itself.

See the benefits of agile measurement at scale

Adding quantitative measurement into your organisation’s inspect and adapt process can maximize value delivery throughout your development organization. Ultimately, when all teams on a program are high-performing, fast, and predictable, you’ll see faster delivery of working software with higher value. Your Agile coaches will be better equipped to help team and leaders by knowing why and where to apply training and coaching focus.

> See also: Digital business demands a leap to new excellence in IT

Teams will be empowered to drive their own continuous improvement by incorporating objective data into their retrospectives. Finally, at the Program Level, the performance of your agile software delivery engine can be steered to drive greater value delivery faster and more predictably – the largest payoff of all.

Sourced from Steve Wolfe, solutions manager, and Sean Heuer, product owner, Rally Software Development