Measure what Matters >> Beyond Plans and Promises: Delivered Software is the Only True Measure of Progress
In the complex world of software development, it's easy to get lost in a sea of meetings, documents, and abstract metrics. However, at the end of the day, there's only one tangible measure of progress: delivered, working software. All other efforts, however well-intentioned, are merely steps towards this ultimate goal.
We often fall into the trap of equating activity with progress. We might celebrate completed design documents, detailed project plans, or even impressive burndown charts that show a straight line to completion. But these artifacts, while potentially useful, don't deliver value to the end user. They are, at best, indicators of potential progress.
Tangible Value: Delivered software provides concrete value to users. It solves problems, automates tasks, and enhances experiences.
Real-World Feedback: Only delivered software can generate real-world feedback from users. This feedback is invaluable for identifying bugs, refining features, and ensuring that the software meets user needs.
Validation of Assumptions: Delivering software allows us to validate our assumptions about user needs and market demands. It provides concrete evidence of whether our ideas are viable.
Business Impact: Ultimately, software is built to achieve business goals. Delivered software is the only way to realize those goals and generate a return on investment.
True Transparency: Delivered software provides the truest form of transparency for stakeholders. They can see and interact with the product, providing clear evidence of progress.
Burndown charts and velocity metrics are valuable tools for tracking progress and predicting completion dates. However, they should never be mistaken for the end goal itself.
Burndown Charts: These charts visualize the remaining work in a sprint or project. While a smooth burndown can be encouraging, it doesn't guarantee a successful product. A burndown chart can show a perfect slope, but if the software is full of bugs, or doesn't meet the user's needs, it is still a failure.
Velocity: Velocity measures the amount of work a team completes in a sprint. It's useful for estimating future sprints, but it's not a measure of value. A high velocity doesn't necessarily translate to high-quality or impactful software.
These tools should be used to facilitate the delivery of working software, not as substitutes for it.
To prioritize delivered software, teams should:
Focus on Minimum Viable Products (MVPs): Deliver small, functional increments of software as quickly as possible.
Embrace Continuous Delivery: Automate the build, test, and deployment process to enable frequent releases.
Prioritize User Feedback: Actively seek and incorporate user feedback throughout the development process.
Measure Success by Impact: Focus on metrics that measure the impact of the software on users and the business.
Reduce the scope: When unsure, always reduce the scope of a feature. It is always better to deliver less working code, than more non working code.
In the world of software development, talk is cheap. Delivered software is the only currency that truly matters. By focusing on delivering working software, teams can ensure that their efforts translate into real value for users and the business.