How can we measure the working software?

Releases passing QA requirements, increments being succesfully deployed into production, number of production incidents etc etc etc

Why do you think working software is more important than for example an evolving Definition of Done or the level of self-organization of a Scrum Team when you look at the progression of a team?

Why do you think working software is more important than for example an evolving Definition of Done or the level of self-organization of a Scrum Team when you look at the progression of a team?

It is one of the 12 principles behind the Agile manifesto. It does not state a revision of DoD is less important, it states that software is only delivering value and is only measurable when it is done and deliverd to the end user. Partly finished software or software unreleased / unshipped does not deliver value to the enduser and is therefore not seen as progress.

So, this principle is not exluding or diminishing other ways of progress, it states that any increment is only counting towards progress when it is done and delivered / shipped, and it is focussed on the end user and not the team internals

@Xander, Yes I agree. I was mentioning the statement of VBMVVN, saying that working software is the primary measure of the progress of a Scrum Team.

Do you agree with that statement and if yes, can you convince me why working software is a more important measure of the progress of a scrum team than for example an evolving DoD and the level of self-organization?

@Eric,

Does team maturity and an improved DoD translate into customer value?   If I owned a factory and made assembly-line improvements, I'm not sure the customer would care much about it until they received an actual product created by the new assembly-line.

In my opinion, that is why Working Software is a more important measure of progress than any process improvement or growth in team maturity.

In my own opinion, the truest goal is delivering value to the customer, as fast and often as possible.

That is also where the only true inspect & adapt cycles can take place or where the feedback comes from.

Any improvement at any point in the process to get there is great, but all in service of this greater goal. So in the end, I think, that anything contributing to this goal is secondary to the primary goal, the primary measure of progress

To add onto the thoughts already mentioned, I think it's worth saying that "working" software was meant to emphasis the importance of getting feedback on finished work and not work living in a dev branch.

The measure of progress must be made on finished work rather than work that's not integrated into the product yet. We wouldn't want to show how far we've progressed using work that's not production quality, or "working".

@timothy / Xander, I see your points, thanks!