agile-process.org Home

Working Software

 extremeprogramming.org
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 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 will be weak. Honest plans are only possible if you have honest estimates based on done meaning 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.
One common misconception about testing software is the cost. Most developers only know two data points; no tests, and too many tests. Finding bugs cost you something. If you don't test your software you are essentially moving that cost to your users/customers. If you only pay for fixing bugs but not finding them you save money. On the other hand if you set out determined to test every possible input to your software you will find the cost of testing rises exponentially as you get close to 100% tested. Of these two data points not testing is obviously cheaper.
But there are two assumptions to this analysis that you may not be aware of: You can not effectively increase software quality at the end of the project and designing code to be testable changes the cost of testing it. 
You want to present your customer/product owner with the best estimates you can for planning. How can someone choose between two possibilities without knowing the true full cost. If you have unknown costs to pay you won't be able to plan well. Consider for example integration, if you have not integrated code in a month you could easily spend days integrating and deliver late. However, if you integrated ten minutes ago you know it won't be a problem.
You will be showing your software to your customers at the end of each iteration, getting it working is required. You want to finish each story to production ready. Shipping the software to production is a customer decision, but developers must have the software ready to go.
Requirements cost you something to get and you get what you pay for. Reducing the cost of requirements by designating an intermediary or by being frugal with an experts time leads to software that isn't worth much no matter what you subsequently spend on development. The requirements you get late in a project are usually the most valuable because the customers have learned something about the system or have identified a competitive advantage.
Graciously accepting that the needs of the product owner can and will change even late in the project is being honest about what needs to get done next.
An Agile process may start out with guesses but quickly reaches realistic schedules by measuring progress in small amounts.
Iterative planning in combination with regularly scheduled product demonstrations help the customer discover his problem's solution faster. The changes you get from your customer late in a project are often the most valuable.
 The one essential ingredient that turns repetitive development into iterative development is feedback.
How do you know that integration will take minutes and not days? If you integrate everyday then you know. How do you know how long it will take to package your software and release to production? If you release every week then you know. Creating fully working software versions and releases frequently is all about knowing.
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.
Remember that you are creating software for people without technical backgrounds help them out by demonstrating working software frequently.
I like to tell a story about driving to a tiny city in rural Ohio one year. My wife was visiting relatives. The little town wasn't on any map and the directions we had didn't seem to work. So we stopped at a gas station to ask for directions. Sadly the gas attendant said "you can't get there from here." What do you say to that? My wife, whose profession is communication, knew. She ask the gas attendant a different question: "Can you tell us how to get someplace that we can get there from?" The gas guy cheerfully responded "sure, all you have to do is...then ask again." The moral of the story is to get the information you need you have to ask the right question and you may have to ask it again later.
The worst excuse I have heard is "the project failed because the customer didn't know what he wanted." As if that made perfect sense. It wasn't because the customer didn't know what he wanted. If he is paying you money then he obviously wants a solution to his problem. It is your fault for not asking the right question. Instead say "the project failed because I didn't ask the right questions."
The best way to make sure the right questions get asked and answered is to show the customer working software as often as possible.
Business analysts get paid lots of money to know how to ask the right questions up front. Demonstrate a working system and ask "how do you like it so far?"
Code should always be ready for production at all times. That means integrated and tested. The Lean people will tell you code that is kept private is waste, integrate often, several times a day so that everyone on the team can work in the context of everyone's latest versions.
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.
Agile flow chart

Measure your progress honestly. If software is what you intend to deliver than count 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.
One dozen Agile words: Iterative planning, honest plans, project heartbeat, working software, team empowerment, and daily communication. A Project Heartbeat

Agile-Process.org home | A Project Heartbeat | About the Author

Copyright 2009 Don Wells all rights reserved.