The 7th principle of the Agile Manifesto is:

Working software is the primary measure of progress.

Let's talk what this principle means in real projects, and then get a bit more general as to why it's good.

How does this principle show up in a real Agile process? There's a concept we call "velocity". We assign velocity points for new functionality -- not tickets completed! The danger of using "tickets completed" as a proxy for project value is that fixing a bug means closing a ticket. But, fixing a bug means the original ticket wasn't done right, a.k.a: the software produced wasn't "working software". So, if someone spends a day setting up user avatar uploads, they've gotten 2 points of velocity. If someone spends a few hours fixing the login system because it was supposed to use emails instead of usernames, they get no velocity points.

Velocity is very useful from a management perspective, and it also enhances productivity. When you give a system of rules for scoring "points" to a group of people, I promise you that their level of performance will go up. Really, there's only one problem with velocity: the illusion that you can compare velocity across projects and teams.

Every group estimates every project differently. When estimating the complexity of a change (in order to give the ticket the point value), some people naturally estimate high and some estimate low. The great thing about velocity is that it doesn't matter if you're high or low, just that you are consistent. If the project and the team are relatively consistent, they'll produce consistent estimates. Consistency is good, because it makes it possible to plan programming endeavors.

So, don't think of velocity as "the bigger the number, the more functionality being added!" It's only valuable for comparing a team and a project against itself, to answer questions like:

• The developers are busting their butts. Are we adding as much functionality as we did a month ago?
• The developers are busting their butts. Are we spending all our time fixing bugs?
• Did adding a developer improve our productivity? Roughly how much?
• Did removing a developer decrease our productivity? Roughly how much?
• Did a new process or tool affect productivity?

One extra note: if the same team and project's velocity is highly variable, or ever spikes/drops, it's fair to ask why.

Why does this work?

This is a hugely important principle. There's almost nothing more important than producing working software. Beautiful code that doesn't work is like a band filled with technical experts that sound like crap. The problem tends to be people who absolutely love and are insanely great at doing the thing, are so focused on being in love and insanely great that they don't focus on business value. Technical purists mixed with business makes for rocky waters, but you can sail between them.

On the flip side, the average person's definition of "working software" usually just means "when I sat down for the demo and clicked the button, I saw the expected result". That's not working software. Other things that contribute to "working software" are:

• handling unusual but likely situations well (not rare and arcane situations -- that's premature optimization)
• maintainability for the developers (present and future)
• usability for the end user
• free of bugs

On the subject of working software: there are many times when someone is fully capable of producing working code, but doesn't want to when the solution doesn't feel beautiful. Every scientific and artistic field has certain definitions of beauty or purity -- the times when it all comes together. No-hitters in baseball, hat tricks in hockey, drifting cars, and math equations that are simple but convey a fundamental law of the universe. Writing software is no different -- there's certain things that can make an algorithm or architecture simple and powerful. But idealism can kill. These things are best when they come about naturally. Sometimes it takes some extra work to make them, but don't go too far out of your way. Nothing trumps working code. I used to be guilty of this, and I've gotten more done since getting past it than I ever did before. I know it's a problem in our industry, and I want others to benefit from it.