The Agile Balanced Scorecard!

In Management 2.0 fads like ‘Balanced Scorecard‘, Six Sigma, Theory of Constraints, and Total Quality Management, these models assume that organizations are managed from the top, and they help those at the top to better “design” their organizations.  Sometimes it works sometimes it doesn’t.

To quote Management 3.0 by Jurgen Appelo.
The report State of Agile Development Survey 2009 by VersionOne listed “management
opposed to change,” “loss of management control,” “lack of engineering discipline,”
“team opposed to change,” and “quality of engineering talent” as the main concerns
about adoption of Agile, together with many organizations’ “needs” for planning,
predictability, and documentation [VersionOne 2009].
Hold on…. Let’s review those concerns again: We’re talking about various managerial
controls, organizational change management, and engineering talent….

So to have organizations enjoy the benefits of Agile transitions, they have to know the
answer to an important question: What is the future of the manager in an Agile world?

Beware the Hawthorne Effect

  • We affect what we measure

The original Balanced scorecard

Robert Kaplan and David Norton introduced the Balanced Scorecard approach to organizational strategy design and measurement in 1992.

Lagging indicators

What happened in the last financial period. Not always gies a forward view and how to make corrections.

Leading indicators

  • Are we delivering to schedule and budget?
  • Are we practising the appropriate agile methods that will lead to success?
  • Are we effective with resources?

Effectiveness Metrics

  • Measure extent to which we met our business goals?
  • Revenue generated, cost savings, new customers acquired, customer retention, etc.
  • Did we build the right thing at the right time?


  • “Did we build it the right way?”

Effectiveness vs. Efficiency

  • Cost, time, resources – versus – meeting business needs and satisfying customers.
  • Effectiveness trumps efficiency almost every time!

Success factors

  • Financial
  • Customer satisfaction
  • Innovation & Learning – Examples here might be the percentage of revenue from new products, team collaboration and knowledge sharing, training hours delivere, etc
  • Internal processes – such as time-to-market, inventory, throughput, defect rates, etc

The Agile Balanced Scorecard

As suggested by LitheSpeed:

  • Product: Are we building high-value products that are in demand by our customers?
  • Financial: Are we achieving planned-for financial results?
  • Team:Are we working well together as a team and addressing the needs of the various stakeholders?
  • Schedule:Are we on track to deliver within the schedule commitments?

But what about quality, team satisfaction, other dependant stakeholders satisfaction?

There’s also not much wrong with the idea behind balanced scorecards. [Kaplan and Norton, “Using the Balanced Scorecard”] The problem with measurements is that one metric easily leads to sub-optimization (improving one part of the work while diminishing another part), and, therefore, you need multiple perspectives to have a more holistic view of the organization’s performance. Unfortunately… when managers continue to view the organization as a hierarchy, they usually try to impose goals and metrics on every part of the system. But in complex systems, performance is usually found in the relationships between the parts, and proper goals and metrics can only emerge from intelligent local interaction, not as part of a top-down target-setting framework. (Source: #Workout by Jurgen Appelo)

Multiple projects and WIP limits

When Product A development is split between teams 1, 2 & 3 – protect Product A’s delivery without being tempted to start Product B and C when teams 2 & 3 finish earlier, team 1 are still fully utilised working on Product A so teams 2&3 can help team 1 finish Product A rather than starting new products. Its better to have these two teams under utilised and have contingency – getting ahead early on new products can hinder team 1 even more.

Using metrics to guide agile adoption

Agile maturity – An introduction to enterprise agility







Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s