The SAO's Quality Assurance Special Interest Group's (QASIG) panel discussion, aptly titled "Life Inside an Iteration," is now available for download from the SAO's social network. (Cramming five acronyms into a single sentence is decidedly clunky. Sorry.)

OpenSourcery's Brian Jamison moderated the panel, which included some of Portland's best Agile thinkers and implementers. Chris Jones from Yesmail, Wayne Allen of Integrated Services, Sumant Vashisth from McAfee, and Todd Whitaker describe their Agile best practices in this informative, example-rich discussion.

Download the audio files here.

So sit back, download the discussion, plug your iPod into the stereo, throw together a nice meal, and be transported to Agile bliss with "Life Inside an Iteration."

This is a story of failed software development I've heard far too many times. Unfortunately, last week I heard the story yet again.

The people I met had everything they needed to succeed. The stakeholders are great people. They have a valuable mission, a solid organization, and a budget. They knew what they wanted. Despite that, their software project completely failed. And while OpenSourcery is now being called in to do it right, we have to start from scratch.

The client told me that before engaging us they hired a small web design shop. Let's call the web design shop “Violet Hammer” in honor of Mark Twain's quote, “to a man with a hammer, everything looks like a nail.”

The folks at Violet Hammer talked a heck of a talk and had a great price to boot; far less than other development firms, including ours. Violet Hammer had plenty of expertise with a particular web application, so they sold the client on it. The problem is, the app they pitched didn't do ten percent of what the client needed, and Violet Hammer didn't figure this out until they were at least halfway through the budget.

In this case Violet Hammer, being a small shop, just didn't have the skills the customer required. Software development has a number of specialties, from application architecture and database design to user interaction, optimization, testing, server configuration, and data migration. A two-person shop can't hope to adequately cover those specialties.

To use a building analogy, Violet Hammer had a couple of talented carpenters, but the client needed an entire house, requiring professionals with many diverse specialties from woodworking, electrical, plumbing and roofing to architecture and interior design.

Predictably, Violet Hammer heard the client's requirements and saw only the woodwork – because they work with hammer and nail all day. Violet Hammer ate half of the project schedule before they realized they'd also have to do the plumbing, electrical, roofing and the interior design. The result? The client wasted half their original budget, has lost several months of time, and has literally nothing to show for it. It upsets me to see good people waste good money on failed projects. It didn't have to turn out that way.

A greatly reduced rate is a red flag, and Violet Hammer's rates reflected only a fraction of the work necessary. They charged the right rate for a carpenter, but omitted all the other jobs and costs from their quote. This frustratingly common practice with small web design shops is made more difficult when buying decisions are made largely on the hourly rates or quoted prices between developers. The solution is to factor in the cost of failure, which is usually more expensive than the difference between the low bidder and high bidder. What did this failure cost the customer in lost time? Were relationships with partners or funders jeopardized?

When hiring professional services firms to build your web applications you can pay for the mistakes already made, or you can pay to make mistakes. Violet Hammer's lower quote represented their willingness to make mistakes on the project. If Violet Hammer could charge a higher rate (and keep their customers), they would. In the end I'm sure Violet Hammer has learned many important lessons. Unfortunately, the customer paid for Violet Hammer's lessons, receiving nothing in return.

When evaluating developers, ask difficult questions. What is your prospective development partner's experience with the technology they are proposing? Does the technology already seem to do what you need? Demand specific work examples that are similar to what you need, and test drive the web applications they've written. Find out exactly what your partners have done for other customers. Is it just the carpentry, or did they build the whole house?

Working with a small shop can make sense and save money if the specialties are an exact fit, but asking a couple of carpenters to build an entire house is a risky proposition at best. In this case a few probing questions and an evaluation of the costs of failure could have avoided the problem and resulted in success.

It seems Agile development, OpenSourcery's chosen software development method, is finally reaching the broad acceptance it deserves. We have a lot to say about Agile (ask us more), so it makes perfect sense that OpenSourcery co-founder and CEO Brian Jamison would moderate the upcoming "Life Inside an Iteration" panel.

The Software Association of Oregon (SAO) will host the event, with the guidance of its Development Special Interest Group (DevSIG) and Quality Assurance SIG (QASIG).

Join us and learn what "Life Inside an Iteration" is really like. Panelists will discuss what activities help QA and Development work in sync, what the hand offs are and how they happen, and how they have managed the inevitable change within the iteration. Panelists include developers, testers, customers and consultants to bring a broad perspective of best practices to these issues.

Learn more about the event here. We hope to see you there.

Is Fixed-Price Software Development Unethical?

This is the question posed by Scott Ambler in his article on software development.

Here's the problem.  Everybody knows:

• Cost estimates are frequently wrong
• Client requirements usually change during development

...and as a result fixed-price projects are often late, over budget and/or don't really do what the clients want when the product is delivered.  How does this happen, Scott lays it down here.

Here at OpenSourcery we strive to use the Agile software development methodology to deliver better service to our clients at less risk of the project going horribly, horribly wrong.  

Watch this space for more information on Agile software development, why we use it and why it makes so many of our customers happy.

- Steve Peters