[doctor_eval]

I know that there are definitions of velocity such as "a measure of the rate at which a development team consistently delivers business value". But I find this definition to be pretty useless in practice, so I ended up landing on a different definition, which is that velocity is "the ability for an engineering team to maintain productivity in the face of changing business requirements".

By framing it this way, I find that velocity becomes something that a team can actually experience, at least informally; and it implies the need to put time towards tools, management and architecture, rather than just features.

[calpaterson]

> a measure of the rate at which a development team consistently delivers business value

It isn't even usually this, because typically it's _developers_ - not the wider business - who assign point counts to tasks. At the end of two weeks you've typically done about two weeks of work so all that is actually being measured by velocity are the median numbering preferences of the team. eg People who like "fibonacci numbers" invariably achieve a velocity of about 6 * $DEVELOPER_COUNT per sprint.

In order to get a measure of business value you would have to involve someone who knew the relative value of the tasks. Usually that does not happen and agile has at least partially contributed to that by standardising the idea of a development team as being primarily made up of developers (with one token project manager who is there because they know how to manage people, not because they have special knowledge of business value).

Agile, at least as popularly understood, has moved the whole field backwards by entrenching the separation of developers from non-developers. If you try to work directly with the business on a modern agile team, you tend to get rebuked! You've cut your "project manager" (who typically doubles as your line manager) out of the loop and you're no longer making progress on the agreed team measure of story points. Frustratingly, trying to work on business value is de facto non-compliance on many "agile teams".

[doctor_eval]

Yeah - I was quoting the velocity definition given by an article pointed to by TFA. But I mostly agree with you, especially about the identification of business value. My point was that it’s better to have a value that can be measured by the participants (ie, productivity), than one that can’t (business value).

That said, while I am no fan of “agile as popularly understood”, my experience suggests you have the causality backward. Agile is simply a term forced on traditional project managers to make the business sound cool. Nothing is different from the way it was before agile, except the meetings have cool names.

In an environment that takes the agile manifesto seriously, working hand in glove with the business is kinda the point. But most businesses haven’t even heard of the manifesto, and those that have … don’t care.

[jrs235]

The things on the left are talked about. The things on the right are measured. What gets measured gets managed and becomes the focus. Is anybody measuring the things on the left?

[doctor_eval]

This is so true. I have never made this connection before. Even “working software” is far more subjective than “comprehensive documentation”.

But despite believing they are critical to the success of a project, I have no idea how to measure the things on the left, other than intuitively.

This is probably why I suck at working in big corporates.