It was during the middle of a training session I was conducting, when I showed the participants the CHAOS report showing that traditional projects have a meager 30 percent success rate. While most of the participants were taking to the class well, there were a few holdouts—haters as some of my colleagues might say. I pointed them to the AgileImpactreport showing the improved quality and time to market of agile projects. I argued at length about the inherent benefits of empirical feedback loops and adaptive processes in complex domains. I kept crafting intellectual arguments as if I could just strike the right chink in the armor and cause all their resistance and hesitance to collapse upon itself.

I’ve worked with a lot of teams transitioning to agile. In each situation, user stories always seem to be a sticking point, with a common question being, “What are the differences between traditional requirements, use cases, and user stories?” I’d like to answer this question with a description and example of each requirement type. I’ll also use a running example: Imagine that we’re writing software for placement firms, and one of the firms has requested the ability to search for candidates for a specific role by specialty within a geographic location. For example, “I want to find all business analysts who are Sarbanes Oxley (SOX) experts within fifty miles of New York City.”

One of the most challenging situations involving adopting agile is when doing so in a software shop that has several specialized groups already in place forming silos: development, quality assurance (QA), business analysts (BA), software configuration management (SCM), documentation, architecture, database admin (DBA), and user experience (UX). These shops may or may not have fixed (non-negotiable) delivery dates with a very tight schedule, developing either commercial products or turnkey solutions for customers. The goal is to take these silos and form a cohesive team while delivering useful software by the required date.

How many times have you had the conversation at work about how software is so complex and it should be an accepted fact that there are going to be a significant number of defects?

Would you be comfortable if your doctor, surgeon, airline pilot, bridge-builder, car manufacturer, or pharmaceutical company had similiar conversations?

In " The Zero Defect Vision" Part 1, I explored how to develop strategies to eliminate errors and prevent defects in your product or service. In part two of my series, I will examine the common sources of errors in product development activities; by being aware of the things we can change in our environments, we can reach our goal of preventing errors. Then, a number of techniques can be employed in order to help teams work towards a zero defect goal.

People
In order to be able to recognize, and prevent, human error, it is important to understand that developing technology is a people business. Completely eliminating human error is not possible, so we should focus on minimizing the conditions that increase the possibility of error. Some of the factors to pay close attention to are:

“How long’s it gonna take?” My response: “Six weeks, plus or minus two days. No more.” In this article, I’ll give a rebuttal to Daryl Kulak’s article, “Let’s Stop the Wishful Thinking.” I will show why his beliefs about software estimating, while understandable, are questionable because of the advent of the Test Requirements Agile Metric (TRAM).

I've been working with folks making their transition to agile. One of the hardest transitions is for the managers and technical leaders.

Managers are accustomed to working in timeboxes. To them, the iteration is a timebox. But, they also are accustomed to features spanning multiple timeboxes, and that’s not OK in agile.

The global recession has strongly impacted the software development industry, including companies that develop software to support their traditional services. Anyone speaking to a development executive can feel these effects. The outcry is universal: “How can I do more with the same resources?” The need to be innovative, competitive, and cost effective has never been stronger than it is today. If necessity is the mother of invention, then current world economy is the mother of necessity.   Nearly every CIO or VP of R&D that I speak with is struggling to improve their time to market while increase the number of features delivered within stagnant or shrinking budgets. Two common objectives of software development teams address this need: