Is the Value Fetish Killing Agile Teams?

Last weekend I was at CITCON Europe, a great opportunity to meet some of the leading minds in the agile software movement. One intriguing new term I heard a few times was “value fetish”. Let me try to explain what I think it means, and discuss the implications for agile teams.

Back in the pre-agile days when our projects were planned around component pieces of the architecture, “value” was a meaningless concept. The whole project had a value, but day-to-day that didn’t help us prioritise our work – from inside the plan it was impossible to judge whether my database stored procedure was contributing more value than your pricing component – without one, the other would simply not function.

As we started to plan around small deliverables like user stories, the concept of value came to the fore. Suddenly it was obvious that the “file saving” feature was much more valuable than the “conditional formatting” feature. This helped us immensely – we could prioritise our work around this value, and as a result actually felt the glow from knowing that the work we were doing was worthwhile, valuable even.

Now that value has become a first-class concept to software development teams, what happens when it becomes an obsession? When managers who can now measure value and velocity start to compare teams, or offer them incentives to deliver more, faster? When we as developers get so driven and focussed on the delivery of value that we forget to design, refactor, consolidate, reflect, and sharpen our tools? When we forget to go home on time?

We get burned out.

As ever, it’s the responsibility of the developers (and their leaders) to stand firm and hold on to the space and time that they need to do their work at a sustainable pace. Not all the hours you spend in a day – tidying up the build scripts, writing a code generator, cleaning up a library so you can release it as open source – can or should be directly attributed to the value they will immediately offer to the business. That’s not to say we should spend our days idling, but that we should maintain a level of self-respect in everything that we do.

Published by Matt

I write software, and love learning how to do it even better.

Join the Conversation


  1. I am looking for some idea and stumble upon your posting 🙂 decide to wish you Thanks. Eugene

  2. Hi Matt

    Very interesting indeed 🙂

    but I’m afraid I must take issue with your claim that value-driven projects are an Agile innovation. Use cases, for example, capture the user’s goals for interacting with a system. Use cases (or “usage cases”, as they were originally concieved) and scenario-driven development in general are now several decades old.

    Pre-Agile, there have also been many attempts at aligning software features with business goals (the main aim of Enterprise Architecture).

    These approaches probably suffered fro being too BDUF and too heavily applied in the past, but they were most definitely out there and in use.

    We must be careful to remember that the agile movement has mainly reframed existing practices, applying them with a new set of values. But there’s nothing new under the Agile sun!

  3. Thanks for the reality check, old-timer! 😉

    You’re quite right about use cases, and when used properly I don’t think they’re really any different from user stories, are they?

    I have however seen use cases abused such that the high-value and low-value features are so muddled together it’s almost impossible to tease them apart.

  4. Actually, I think I coined that term.

    I meant it to apply to teams where any time spent not writing production code /right now/ is considered wasted. It’s a valid reaction to others that never deliver anything, but a team has to keep up its technical and social maintenance.

    I also think that for some people, there’s an element of programmer’s addiction about it.:

  5. Actually, I coined that term.

    I meant it to refer to teams where anything other than writing production code /right now/ is regarded as a waste of time. This is a valid response to those (many) others who never seem to ship anything, but teams need to keep up their technical and organisational maintenance as well — otherwise someone, often someone else, will hit the wall.

    I also think there’s an element of programmer’s addiction about this phenomenon:

Leave a comment

Your email address will not be published. Required fields are marked *