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

247 Townhall is a community forum that allows visitors to post videos, stories, audio, and more. A custom Drupal site powered by a combination of contributed and custom modules.

Key Features:

Story:

247 Townhall is a community forum dedicated to change. Users sign in to share videos, stories, events, trends, and audio. We love this site because it's functional and nice to look at, and, really, how can you not love a site that boasts Mos Def as a contributor?

Users can interact with the site on several levels, from observers to participating members. Members track their favorite content and comment on shared items. We also like that the process begins with new members submitting their personal stories.

We developed 247 Townhall with Drupal, which allows users and site administrators to easily upload video, text and audio. The difficult work happens below the surface so most people don't even have to think about what's happening: upload an image and VOILA! It's cropped into form and displayed exactly where and how you imagined. And by incorporating social networking, content organizing, and user-friendly site editing tools, 247 Townhall is able to maintain a vibrant site that boasts fresh content daily.

Development Process:

The key to the successful deployment of this site was the Agile software development approach that OpenSourcery took with One Economy (the corporation behind 247 Townhall). This was a complex development project with tight internal deadlines, numerous stakeholders, and significant functional requirements. OpenSourcery has partnered with One Economy on a number of projects (including One-Economy.com) and both organizations approached this project with a strong commitment to consistent communication and a tight, organized feedback loop. Solid project management tools and processes, as well as short development iterations and frequent, automated code pushes and database migration scripts, allowed us to manage the complex scope and timeline for this launch.

Pronetos founders Chris Blanchard and Wyatt Werner came to OpenSourcery with the idea of giving academics a network that went beyond mere socializing. They wanted the ability for members to share and review academic papers. Pronetos makes it easy for scholars to stay connected with their colleagues, wherever they may be. Pronetos is a place for scholars to network, and build and share ideas with the greatest minds in their field.

Pronetos is also a content repository that allows readers and authors to interact and build new ideas. Scholars connect as they would at a conference, except this conference is attended by scholars from across the globe. They make interdisciplinary contacts. Exchange ideas. Collaborate. Gain exposure for their research. Stay current on trends in your field. In short, it is THE professor's network.

OpenSourcery built custom features for Pronetos.com with Ruby on Rails, an open source framework designed for rapid web development.