Skip to main content

Agile Value

December 11, 2013

Every year, organizations spend 4-10% of their revenues on their IT organizations. Value is expected in return for these expenditures.

Here, value is defined as the financial benefit that an organization receives for expenditures. When measured, value can encompass an entire organization, or be constrained, such as to a single division or product line. Regardless, it must encompass those areas affected by the expenditure.

Value will be a point in time measurement comprised of:

  • revenues per employee – gross revenues per employee

  • employee satisfaction – how satisfied are the employees? After investing in employees, they become a substantial asset and competitive advantage.

  • customer satisfaction – are the customers more or less satisfied than in the past? Finding a new customer is much more costly than satisfying current customers.


An organization can change value through:

  • products and services that it sells and delivers.

  • systems, both manual and automated, through which it delivers the products and services.

We focus on the latter.


Philips Lighting

Philips Lighting, a multi-billion dollar division of Philips Corporation, recently completed a project to “accelerate” its value creation. The project spanned operations from when a quote was given to a customer until the cash was received. The project had two components:

  • Revised business operation, integrated into a new operations flow created through value stream mapping and relentless waste elimination.

  • New software systems, based on Salesforce products, that supported the new business operation.

Each component required the other to succeed. Improved IT operations would have no impact on organizational value unless the business could effectively utilize it.


Value Metric

We have devised a metric that attempts to capture both aspects of an organization’s current ability to create and deliver value. It consists of:

  • Operational metrics, measuring an organization’s efficiency. These metrics are heavily slanted toward IT, both the development of software and the deployment of it in the organization. They include flow, cycle time, stabilization, quality, utilization rate, and release cycle time. Business operational efficiency is not included in these measurements, but will be addressed in 2014 as part of the Kotter International (John Kotter) Accelerate! program.

  • Organizational metrics, measuring the impact of that efficiency of investment on the marketplace and the value the organization accrues. These metrics are revenue per employee, customer and employee satisfaction, and product/system cost ratio.


Agility Index

The two metrics are combined into a single metric, Agility Index. The Agility Index is a number indicating relative agility, from 1 to 100. It is heavily weighted toward organization value. That is, an organization can be incredibly competent, but if it doesn’t derive marketplace value from the efficiency, the Agility Index is low.

As an organization expends funds on IT, projects, and business improvement, it should expect that this metric would increase.


Traditional project measurement criteria


A traditional project assesses a need and defines a complete set of requirements to satisfy the need. From these requirements, a due date and budget are established. Once these are established, any changes are fit in as possible. All metrics are accumulated against this type of project. Value does not enter the measurement.


Requirements: All requirements stated at the beginning of the project have been satisfied

Budget: Budget allocated at the start of the project was not exceeded

Timeline: Date for completion of the project was not exceeded


Agile/Scrum project measurement criteria

Agile/Scrum projects are different. A goal is established: this is the intended impact and objective. A date and funding may be estimated based on past experience, or may emerge experientially as the work progresses. All effort will be directed to achieve the best possible solution to this goal. This initiative is complete when the solution is either created, or it is determined that it cannot be reasonably created at this time.

In the agile project, each Sprint or iteration is a complete project. It has requirements, budget, and due date. At the end, it has a completed set of software functionality. Based on what is completes, another project may or may not be initiated, adding more functionality to the functionality just completed. Each Sprint is measured on its own.



Confidence of investors in value: Confidence of stakeholders, product owner, and developers that the best possible solution was created for the goal of the initiative for the most reasonable amount of funding.

Satisfaction of investors: Willingness of stakeholders, product owner, and developers to do this type of initiative again.

Confidence in utility of software: Confidence by people using the system or product that it provides a better way of doing work than before.

Satisfaction of customers: The degree to which the users look forward to the next solution to helping them do their work better.

What did you think about this post?