DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Building Scalable Real-Time Apps with AstraDB and Vaadin
Register Now

Trending

  • You’ve Got Mail… and It’s a SPAM!
  • Java String Templates Today
  • Application Architecture Design Principles
  • Is Podman a Drop-in Replacement for Docker?

Trending

  • You’ve Got Mail… and It’s a SPAM!
  • Java String Templates Today
  • Application Architecture Design Principles
  • Is Podman a Drop-in Replacement for Docker?
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Optimize the Whole = Measure at All Levels

Optimize the Whole = Measure at All Levels

Jurgen Appelo user avatar by
Jurgen Appelo
·
Mar. 30, 10 · News
Like (0)
Save
Tweet
Share
3.15K Views

Join the DZone community and get the full member experience.

Join For Free
We know that measuring (and awarding) the wrong things in a system leads to nasty side-effects. And we know that self-organization allows a system to optimize for itself. In systems theory these concepts are known as the Sub-optimization Principle:

If each subsystem, regarded separately, is made to operate with maximum efficiency, the system as a whole will not operate with utmost efficiency. - General Systems Theory (Lars Skyttner)


The answer to this problem, and one of the basic principles of lean software development, is to always optimize the whole. Peter Drucker once said: “what gets measured gets managed,” and an alternative saying is: “what you measure is what you get (WYMIWYG).” Logically it follows that, in order to get an optimized whole, we have to measure the whole. What you measure (and constrain) has to cover everything, from start to finish, from top to bottom, or else the unmeasured and unconstrained parts in the system will self-organize toward sub-optimal results.

Many times I have struggled with the sub-optimization principle. I have measured overrun on projects at the team level, and subsequently got complaints from some team members that they were not responsible for the overrun, because they only got involved later in the project. I have measured individual skills, and subsequently got complaints that those particular skills had nothing to do with getting products delivered to the customer. Sometimes it seemed my only reliable metric was the steady number of complaints from people about the metrics.

Agile experts strongly believe that team members have to self-organize to optimize the output of the whole team, and not of the individual team members. I agree. But then many agilists suggest to measure only teams, not individuals. That’s where I am of a different opinion.

If this were a correct approach, then the same reasoning would apply to teams within a business unit, and business units within an organization. In every case measurement of (only) the subsystem would lead to sub-optimization at the next higher level. Taken to its extreme there would be one and only one proper metric: “continued survival and success of the whole organization,” which doesn’t look like a particularly useful one to me. (Note: even “profitability” is not a good metric at the organizational level, now that the credit crisis has proved that this metric alone also leads to sub-optimization.)

Evidently, optimize the whole cannot mean that we need to move all metrics to higher organizational levels. After a few recursive steps there wouldn’t be a sensible metric left to use. A more logical approach is to ensure that the combination of our metrics leaves no gaps in our measurements and understanding of the entire system. A metric of individual performance is fine if and only if it is augmented with metrics at the team level. And metrics concerning individual teams are OK if and only if supplemented with metrics for entire business units, and the organization as a whole.

One could even turn this into a fifth agile value:

Global metrics over local metrics.


While there is value in the item on the right, we value the item on the left more. But that doesn’t mean that the item on the right is unimportant…

(image by Pink Sherbet)

This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.

Measure (physics) agile Metric (unit)

Published at DZone with permission of Jurgen Appelo. See the original article here.

Opinions expressed by DZone contributors are their own.

Trending

  • You’ve Got Mail… and It’s a SPAM!
  • Java String Templates Today
  • Application Architecture Design Principles
  • Is Podman a Drop-in Replacement for Docker?

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: