This post originated from an RSS feed registered with Agile Buzz
by Simon Baker.
Original Post: Quality, relativism and a fetish
Feed Title: Agile In Action
Feed URL: http://feeds.feedburner.com/AgileInAction
Feed Description: Energized Work's blog.
Sooner or later the manager says: "We've got to ship this thing". And, whether it's a conscious decision or a consequence of the ensuing pressure, corners are cut; defects get introduced and quality drops. The response is habitual and simply makes the situation worse.
Anxious people working alone introduce the most defects. Efficiency leads to breakages. Quality goes down and technical debt increases with every corner cut. When prioritized against the next feature promising to deliver business value, debt never gets repaid. There's no common language for talking about quality. The business-value-fetishists pay little attention to technical debt. They just assume quality is being delivered regardless of the decisions they make. They do, however, understand the cost of goods returned, the cost of rework, and the loss of customers but they choose to remain ignorant of the fact that these are typically the consequences of not valuing quality.
We believe that quality is the result of:
Good behaviors and practices that are mutually reinforcing, where the practices are applied with discipline and rigor, and
having the right attitude towards quality throughout the entire company.
We were going to use the above blurbage as a preamble in our session at London QCon 2009 in the track: Turning on a sixpence: Technical skills for agile development. You've probably heard people say: "It's good enough". Or "investing in more quality will provide diminishing returns". We wanted to talk about why we think the real obstacle to achieving high quality is the prevalence of relativism and to discuss who's really qualified to make these calls on quality.
Unfortunately, this isn't consistent with Steve's plan for the track with us representing the "extreme position" on technical practices. So, instead, we'll do some talking about our way of working, which is full-on Extreme Programming surrounded by a shit-load of lessons learned through compromise (yeah, well, everybody starts somewhere) and experimentation, and the continuous investment we make to keep quality high.
Previous Topic
