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:

Once, I was hired at a big company as a team lead with a mission to create an agile team from a group of twelve skilled people. It was hard to transform the group (80 percent of whom were consultants) into a self-organized agile team consisting of 80 percent company employees, some of them offshored. This setup was a major success for me and my agile mentors as we transformed from a bunch of developers to an agile team, but I wasn’t able to celebrate because I had a problem. I was pushing too much self-organization onto the team, and one year of low (but increasing) velocity combined with stepping too hard and often on my boss’s toes, was fatal for me. My boss had to repeatedly explain to the CIO why we did not show the expected results.

Many teams focus on automation at the level that’s easiest to automate given the team makeup and the readily available tools. For some teams, that means lots of automated unit tests. For others, it can mean large suites of GUI-level automation tests. Developers tend to favor automation similar to their regular daily work, and testers tend to favor tools more closely resembling their normal test routines. Or, said another way, when the team looks to implement automation, they identify the closest hammer and start swinging.

Global markets, global talent, and a constant pressure to reduce costs through outsourcing are all major forces that contribute to distributed teams. In VersionOne’s 2008 State of Agile Development survey, 57 percent of respondents stated that their teams were distributed.  While distributing a team could have practical business reasons, distribution can inhibit communication within the team.

“How long’s it gonna take?” We have to be able to answer that question accurately, right? Not necessarily. In this article, we’ll examine the long-held beliefs in software development regarding estimating.

We Are Such Bad Estimators!
Show me a development shop that estimates its work confidently and accurately and I’ll show you a...what? Three-headed lizard that plays gin rummy and has a .350 batting average. We all hang our heads in shame at our poor estimating. Our business executives just want to know how long it will take and how much it will cost.  Why can’t we tell them?