Done Means Value

From Programmer 97-things

Jump to: navigation, search

The definition of done for a piece or software varies from one development team to another. It can have any one of the following definitions: "implemented," "implemented and tested," "implemented, tested, and approved," "shippable," or even something else. In The Art of Agile Development, James Shore defines Done Done as "A story is only complete when on-site customers can use it as they intended." But don't we forget something in those definitions? Can be used is different from actually used.

Why do we write software in the first place? There are plenty of reasons, varying from one person to another, and ranging from pure pleasure to simply earning money. But ultimately, in the end, isn't our main goal to deliver value to the end user? In addition, delivering value also brings pleasure and earnings.

Every artifact we can set up and use is, therefore, only a means to deliver value to users rather than a goal. Every action we take is, therefore, only a step in our journey to deliver value to users rather than an end. Tests — especially green ones — are a means to gain confidence. Continuous integration — especially when well tuned — is a means to be ready at any time. Regular deliveries — as often as possible — are a means to reduce the time to value for our users. But not one of them is an end in itself. Each is only a means to improve our ability to deliver value to our users.

Looking at software development from a Lean perspective, anything that does not bring value is waste. Even if the code is beautifully written. Even if all the tests pass. Even if the client has accepted the functionality. Even if the code is deployed. Even if the server is up and running. As long as it is not used, as long as it does not bring value to the user, it is waste. Our job is not done. We still have to find out why the software is not used. We must have missed something. Why is the user not satisfied? Perhaps something 'outside' of our process, like the absence of training, prevents our users from gaining value?

There are a lot of Something-Driven Development approaches. Most of the somethings are 'technical' in nature: Domain, Test, Behavior, Model, etc. Why don't we use Satisfaction-Driven Development? The satisfaction of the user. The satisfaction that arises as a consequence of the software delivering value to the user. Everything done is focused on the delivery of this value. Maybe not changing the world, but improving at least by a little the life of the user. Satisfaction-Driven Development is compatible with all of the other Something-Driven Development approaches and can be employed simultaneously.

We should keep in mind that the meaning for writing software is broader than technical. We should always keep in mind that our goal is to deliver value to the user. And then our job will be done, and done well.

By Raphael Marvie

This work is licensed under a Creative Commons Attribution 3

Personal tools