The value of value

This week Kai Gilb published the first two posts in a series criticizing the current state of agile and Scrum. On principle I would have welcomed this since I think there are a number of serious problems in the way agile and Scrum are being adopted. Agile is in the early majority phase and many organizations are adopting it in a superficial and unproductive way. There is a growing risk of backlash as more and more projects run into problems. In many ways this situation is similar to what I experienced in the nineties as a specialist on object-oriented development.

Instead of inspiring me, Kai´s posts annoyed me. At first, it was the superficial things that stood out. The self-heroics: “We were 20 years ahead of our time (Tom even more)”. The misrepresentation of agile: “It is all centered around what suits the developer.”. Having met both Tom and Kai on a number of occasions I was well aware of their tendency to sound like preachers speaking to the unenlightened masses. These superficial things irritate but they are not really interesting to debate. Some people get on your nerves and that is your problem as much as it is theirs.

But then I started to see something a lot more interesting. The core message of these posts is that you must focus on stakeholder value. This is very true and something I have focused on for the past 20 years (maybe I was 20 years ahead of my time as well…). It is also true that a lot of projects loose sight of what the primary goals of the project are. What is not true is the claim that stakeholder value is the only thing that is important. The core thing that the Gilbs fail to appreciate is that agile methods balance two things. One is the maximizing of value creation. The other thing is the maximizing of the chances of actually delivering something. These two goals are sometimes in conflict! Projects that dogmatically focus on stakeholder value are working on the right things but still risk failing completely. The simple reason agile focuses on “working software” is that this is one of the primary ways of insuring that the system being worked on will actually work.

The pragmatic approach to agile development emphasizes stakeholder value but does this in a context of many other forces. Developers that are learning new tools, languages and paradigms. A constantly changing environment for both the business and the developers. Partial and inconsistent knowledge. And much much more…

The chaos surrounding the adoption of object-orientation gradually subsided. Objects became boring. That said, there are still far too many developers that write hopelessly poor code. In the coming decade, agile will probable fare the same fate but that will depend on us not loosing focus on what is important.

Further reading: William Caputo has also written about the Gilb posts.

Posted on 2009.11.03 at 13:51

Comments are off for this post.

2 Responses to The value of value

  1. Pingback: uberVU - social comments

  2. pschwarz says:

    You said: The core thing that the Gilbs fail to appreciate is that agile methods balance two things. One is the maximizing of value creation. The other thing is the maximizing of the chances of actually delivering something. These two goals are sometimes in conflict! Projects that dogmatically focus on stakeholder value are working on the right things but still risk failing completely. The simple reason agile focuses on “working software” is that this is one of the primary ways of insuring that the system being worked on will actually work.

    Good insight, and I would go further: Agile methods also balance a third ‘thing’.

    Craig Larman calls it Supportability: the qualities required to keep the system up to date after its release.

    In ‘Agile Software Development’, Alistair Cockburn calls it the Cooperative Game Principle: Software development is a (resource-limited) cooperative gaame of invention and communication. The primary goal of the game is to deliver useful, working software. The secondary goal, the residue of the game, is to set up for the next game. The next game may be to alter or replace the system or create a neighbouring system.

    In “Agile Software Development – Principles, Patterns, and Practices”, Uncle Bob refers to it as two of the three functions of software:

    Every software module has three functions. First is the function it performs while executing. This function is the reason for the module’s existence. The second function of a module is to afford change. Almost all modules will change in the course of their lives, and it is the responsibility of the developers to make sure that such changes are as simple as possible to make. A module that is difficult to change is broken and needs fixing, even though it works. The third function of a module is to communicate to its readers. Developers who are not familiar with the module should be able to read and understand it without undue mental gymnastics. A module that does not communicate is broken and needs to be fixed.

    Kai kicks off the first of his two posts with the following: Sw development is a creative process where there are seemingly infinite numbers of ways to achieve a defined functionality. But even when a set of functionality is equal in two products, the various Qualities of the functionality vary widely. With Qualities I mean attributes like performance, usability, stability, availability, portability, security, etc.

    Supportability doesn’t get a decent mention, nor does it get one in Kai’s current definition of Product-Value or Quality

……….

About Niklas

Born in Sweden, grew up in New York, lives in Norway. Yes, I have problems with identity, but I do think that my background helps me see things from a different perspective.

Read more