Are you in denial about value?

I’d like to talk to you about something, lean closer dear reader as I’m going to have to whisper this. The intricate ways you are accounting for value on your Agile projects is probably wrong.

Maybe you don’t believe me, maybe you’ve always had doubts, but a lot of the time I see teams who can confidently proclaim they are delivering value in their iterations. They can show me burndown charts, burnup charts, velocity and a whole raft of metrics. But the real question is: who did they deliver the value to?

This is in fact the key question when considering value. If you are delivering user stories just to say you’ve delivered them and to notch off another mark on the burn down chart, you are very much in denial. There is no value here because more often than not you’re not actually delivering to anyone (your Product Owner doesn’t count, nor does your client if you’re doing contract development).

Value is only realised when the code or solution is in production. That means it’s thrumming away on a live server somewhere, not sitting in your source code repository waiting for the “big” release at the end. Now it should be argued that you still don’t know that it has value. As more often than not there are no metrics gathered showing actual customers using and finding value in your new feature. However for the purposes of this and as a first step to thinking about value in a more realistic way we’ll imagine an ideal world where any feature developed has some value to your customers (no matter how rare that really is).

If value is not in delivering user stories or tasks, then where is it? Well, as you’ll probably already be thinking after reading the above, the value is in the release. Everything else is just work to get you to the release.

That prototype you built, it has no value, it’s just a step to release. Something to steer you towards a more valuable release. That feature you built that’s waiting in source control for deployment. Again it has no value.

This normally means that your Scrum board, task board or Kanban board is a lie. Take a look at it now. Does it represent the steps to realise value? Does it only have cards on it that are representation of units of value (things that can actually be released when they get to the end of the board)? There’s a good chance that they are not. They’re probably just tasks waiting to get batched into a release. Your board is probably just a fancy to do list. Useful but not really representative of the actual process. Also not terribly useful in tracking if value is being delivered in a timely and consistent fashion.

I’d suggest that you try and visualise your actual unit of value on a board. So in most cases this will be a project or a release. It might not feel as nice as having a lovely busy board but at least it will be truthful about the situation. A situation where huge chunks of work are being shoved through the system and blocking up the whole process (all whilst your previous board was showing a lovely stream of falsehoods). This will also go some way to address the feeling that you are working incrementally when in reality you have a micro-optimised development process that is thrashing through large projects. Finally puncturing the illusion that you are agile/incremental/iterative when really you are just blind to the whole value stream.

Don’t worry you can keep your old board, but now it will be a representation of reality – in that it’s just a way to help you organise the work within the large batch of value that you’re trying to deliver.

Once you can actually see the problem then you can start to address it. Slim down your projects, do smaller releases. Work towards single piece flow. But that process can’t start whilst you’re still in denial about the value that you are delivering.