Does Quality Management, as depicted in Figure 1.0, have a place in agile product (system-software) development and delivery?

Written by Bob Small and Janet Gregory

Janet Gregory has been a long time icon of mine.  When I was asked to write an article for the Agile Journal regarding Agile testing I was honoured.  The first person I thought of was Janet Gregory and Lisa Crispin as their book, Agile Testing, was a huge help to me when I was first learning about this topic.  After contacting Janet about co-authoring the article, we quickly discovered that we had a very strong difference of opinion.  We decided to share that with you in this article.  You may feel strongly one way or another from reading this article, and the comments from the conversation, but please remember we are all trying to do the same thing.  Increase quality, of our software, and help others to do the same.

Most sprint planning meetings I have attended were fun. The ones that weren’t involved a poorly groomed product backlog, whose high-priority items were not workable, not ready to be pulled into the sprint. When the backlog hasn’t been prepared prior to the meeting, the product owner and team often carry out impromptu grooming activities. These consume valuable planning time and usually result in poor requirements and weak commitments. Plus, everyone is fed up and exhausted by the end of the meeting. As a consequence, the product backlog items that are likely to be worked on in the next sprint have to be prepared prior to each sprint planning meeting. Although it is the product owner’s job to make sure that the work gets done, preparing the product backlog should be teamwork involving the product owner, ScrumMaster and team. We begin the preparation work by choosing a sprint goal.

During these challenging economic times there is a dramatic increase in the need of organizations to adapt the software delivery lifecycle processes to the rapid changes often imposed on them. Leadership is making the decision to transition its development organization – not than just small teams but large numbers of engineers, working on a broad portfolio of development projects from many different locations around the world — to a more agile approach as part of an effort to vastly improve performance, be more responsive to customers and improve quality. However, there are many challenges that an established software organization faces when shifting to Agile.

I buy new cars infrequently, typically every 10 to 12 years. So when I bought a new car in 2003 I was surprised at the many advances in technology since I’d purchased my previous car, a 1993 Honda. One advance I was particularly pleased with was a sensor that automatically detects low air pressure in my tires. It is sometimes hard to tell by looking at a tire if its pressure is low, and checking tires manually is a dirty job, so I did it infrequently. A continuous test of tire pressure was, I thought, a tremendous invention.

"If you don't know where you are going, you will wind up somewhere else." Yogi Berra

This article is an excerpt from Ken Pugh’s upcoming book – “Lean-Agile Acceptance Test Driven Development” to be published by Addison-Wesley.  Debbie, the developer, and Tom, the tester, are introducing acceptance test-driven development to Cathy, the customer.

The Triad – Tom, Debbie, and Cathy – are in their second meeting together.  Debbie describes an example of an acceptance test and four ways that an acceptance test can be executed.

Woke up, fell out of bed,
Dragged a comb across my head
Found my way downstairs and drank a cup,
And looking up I noticed I was late.
Found my coat and grabbed my hat
Made the bus in seconds flat.

- The Beatles “A Day in the Life” (Lennon & McCartney)

People are creatures of habit, particularly programmers: we seek consistency, whether it is the tried and true Waterfall/SDLC method or our morning routine of reading the newspaper with a hot cup of coffee.  Companies or projects looking to adopt an Agile process usually begin by asking, "What is the ROI (return on investment)?" and "Will projects be delivered better, faster and cheaper?"  While these are excellent management focused questions, they neglect the fundamental concern of an individual developer: "What will my day-to-day look like working in an Agile environment?"

Concurrent testing is the concept that as software is being developed, it is also being tested. Concurrent testing can be done in several ways; one of the most common is to perform testing at the system level. As a development team completes coding requirements for an application or system, this required code becomes testable, while other team members can execute test cases against the completed code.