It is a common mistake to think of agile as a set of practices for software development teams. But it’s not - at least not in the commonly interpreted manner - as indicated by the first principle:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

The majority of development teams practicing agile are - in fact - not agile teams. It’s a harsh statement, I know. 

This is for the simple reason that, most so-called agile development teams are locally-optimized to create software. Some of them create working software.
And fewer than those are creating software that customers can actually use, in a true continuously delivered software.

The flaw is in what customers get, not in the fact that they get working software.

This post is the 3rd in a series on Agile Manifesto tl;dr. Click here to go to the first post including an index to the others.

Let’s break this principle to smaller pieces:

Add a comment

Tony was a Scrum Master. He started measuring the development trends of his team. However, whenever he selected a metric, he got the impression that developers were manipulating the results to meet the targets he set. For example, whenever he measured the closing bugs count, he noticed that from one iteration to another the rate grew from 5 to 15. The funny thing was that the bug opening count grew as well from 10 to 24. When trying to measure velocity, it doubled over 3 iterations.

Is this story familiar to you? Let’s see why we should measure. Then we can look at metrics that encourage desired behaviors rather than no-desired ones.

Add a comment

Site search


Register to get notified about new blog posts

Join our long list of happy customers...

  • Panoramic POWER.JPG
  • aternity.png
  • Palram.jpg
  • ezbob.png
  • 3M.jpg
  • redbend.jpg
  • syqe-logo.png
  • D+H.PNG
  • tradency-mirror-trader.jpg