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: http://www.m3p.co.uk/blog/2008/08/12/another-reason-for-licensing-programmers/

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.: http://www.m3p.co.uk/blog/2008/08/12/another-reason-for-licensing-programmers/

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.

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!