Working Software
Very important to Agile projects but often overlooked is getting working software done regularly and frequently. The definition of working software may vary slightly between projects, but not much. Working software is fully integrated, tested, and ready to be shipped to customers or deployed into production. That doesn't mean you tried it a couple times and it ran without aborting. It means you created unit tests, QA tests, and actually looked at output to prove it works. It isn't as difficult as you think. In fact some teams deploy new software into production every single day.
When we were managing our projects by activity we needed a way to guard our progress. The people who finished an activity like analysis might not participate in design or coding. So we safe guarded all progress by creating extensive documentation of what was decided and what was done. We had people with authority sign the front page to verify our efforts were going in the right direction.
An Agile project has all activities going on all the time as needed. We can't use documents with signatures to guard our progress. Instead Agile teams rely on automated tests and working software to safe guard progress. We show working software to our customer/product owner often and accept changes to ensure our efforts continue in the right direction. You can't empower your team to find its own solution using documents with signatures, you need the intense feedback that working software provides.
Working software is an Agile theme that affects everything you do. You will set a project heartbeat, but unless you produce working software each and every iteration your heart beat won't be meaningful. Honest plans are only possible if you have honest estimates based on done meaning finished and working. Iterative planning adapts to changes, but good changes only come from customers looking at, and trying out a working incremental version of the system. A big part of your project heartbeat is delivering working software into production regularly and frequently.
 Take your iteration end seriously. If you are using one week iterations it can be tempting to just push unfinished work into the next iteration. If you find yourself approaching iteration end with several unfinished stories the right thing to do is get your team together and decide which stories could be finished if you work together on them. Your project's velocity is a measure of how much software you got working, not how much you promise to have working next week.
 When we produce working software in small increments we are no longer locked into a minimum cost to get return on investment (ROI). We don't need to spend the entire budget (usually with overruns) to get something back from our project. We can stop when ever we think we have done enough or a higher priority projects comes along.
 Measure your progress honestly. If software is what you intend to deliver than count
One dozen Agile words: Iterative planning, honest plans, project heartbeat, working software, team empowerment, and daily communication.

how much is working right now. You can't consider the project half done if all you have is a design document. This means you will need to iteratively deliver working software and demonstrate that it is fit for it's purpose. Anything else isn't considered measurable, predictable progress.
 Working software ready for production release is easy when you have automated unit tests, automated acceptance/QA tests, and a one button build that runs them in a reasonable time. Your customers don't always know the best way how to solve their problem, help them by demonstrating working software frequently.A Project Heartbeat home | The Paradox of Process | About the Author

Copyright 2009 Don Wells all rights reserved.

Most Important FirstIterative PlanningA Project HeartbeatHonest PlansTeam EmpowermentDaily CommunicationWorking Software