Month: September 2008

Posted on

Measuring Business Value

Measurements is a two edged sword. On one hand you cannot see and compare something that you have not measured. One the other hand there are evidence that it generates dysfunction. Conciuosly or unconciously we tweak our ways to get good numbers. We all know and love the story about the development organisation that was to be measured on the number of comment lines in production code. The tool to insert the correct number of comment lines was available just a few days later.

We need to measure, but most organizations seem to measure the wrong things. I think Systems Thinking and Lean can teach us a bit about how to measure in a meaningful manner. Systems Thinking (and Gödel for that matter) keep pointing “one level up”, i.e. don’t measure inside the system, instead measure the system.

Lean (and Scrum and XP) indicates in various ways that we should prioritize according to business value which seems like a good proposition. So I try to convince managers in my client organizations to measure flow of value through the development organization, and as Lean puts it, measure the whole. (Which in itself can be hard, but at least it is not only the development team!)

However, the notion of business value is a fluffy one. And it is usually very hard to get anyone to assign dollars and cents to a customer request in the general case. (Unless you’re a contract developer, when it’s kind of easy, but probably wrong!)

So what I am trying now is to use business value points. In the same way as Story Points work for effort estimation, Business Value Points can be used to let marketing people, business analysts etc. assign relative values to requirements or features.

One complexity still left to address is the fact that at early stages requirements etc. are fairly large and later broken down and re-prioritized. This means that a complete “requirement” is seldom delivered. So the Business Value Points needs somehow to be split when a requirement is split into Epics and Stories.

But if we could measure the flow of value we can also optimize the whole and avoid sub-optimization and measurement value tweaking.

Posted on

Agile Anti-Pattern: Over-Generalisation

This is the first in a series of posts in which I will try to collect my view of problems in introducing Agile techniques in an organisation, forces that work against Agile and traps that are just waiting to catch the unwary agile practitioner.

Slogan

Generalization makes useless

Applies to

With the obvious risk of falling into the Agile Anti-Pattern: Over-Generalization this Anti-Pattern can apply to many different types of items:

  • Goals
  • Definitions of terms
  • Requirements
  • Plans
  • Stories
  • Definition of Done
  • Tasks
  • Implementation

Examples

Programmers often feel a need to write robust source code. If the exact circumstances in which the code will be executed is not explicitly stated, it is tempting to generalise, second-guessing any future and currently unknown situations.

Exactly the same thing might happen for requirements. A stakeholder might be very broad in his description of the need. But it must be broken down into more and more concrete examples. We know that “The system must react fast to any user input …” is not a requirement usable for development. It might be usable for validation in system test though, because it is a value articulated by the users, and as such can be subjectively validated. But it does not give the concrete information to know when it is actually done.

Over-Generalization in definitions of terms is also common. I have seen it often in planning of business change programs. Particularly in large organizations, where there are many different types of products, situations and projects, definitions of practices easily becomes to generalised to be useful.

For example, in a transition to Agile, the practice “Continuous Integration” might be taken to mean

  • all tests and integrations are automated
  • there are no manual tests
  • system tests are done automatically

… and more. It is not that these goals are bad, in fact they are excellent. But at the core “Continuous Integration” probably means something like “giving programmers concrete feed-back of every change as soon as possible by running builds of as large part of the whole product as possible and as large set of tests as possible as soon as possible after every change to any part of the source code”. As for any change that is to be implemented we need to know exactly what we are trying to implement.

Often people want to include their particular situation, need or interpretation into a definition. The mostly generates bloat. This might also be one of the causes of “requirements creep”.

If a definition is taken to encompass everything related, the definition becomes useless.

Remedy

The best way to handle Generalisation is of course to break down to concrete or less general items. For source code this is already addressed in Agile software development techniques. As the saying goes, don’t implement anything that the current set of tests doesn’t require. This makes us do the simplest thing that could possibly work. This is good advice in any circumstance, and at the core of Agile.

However, sometimes this is not accepted by some of the people involved or affected. A common pattern to this resistance to simply is that it could be perceived as making one persons particular definition or need out of scope. One technique here is to separate that particular part of the definition out into a separate item. It is important not let this come across as removing it, particularly to infer less value in it. This way it is usually possible to get a concensus on a set of tighter, more concrete, items.

Once a set of more concrete items has been agreed upon, a prioritisation process can commence. So it is important to have this prioritization step when handling all types of items. This separates the assignment of importance from the concretisation.