AGILE IN ACTION

Something common I’ve seen in effective agile teams is that testing has found a new home at the heart of development. I’m not referring to developers doing test-driven development to create code that is simpler in design and has testability engineered into it. I’m referring to testers working among developers doing continuous exploratory testing on vertical slices of stories still in progress.

I suspect lots of decisions are made because they bring short-term benefits despite there being long-term risks. I've seen agile teams pushed for feature after feature with the business owner citing business value prioritization. Certainly there is commercial pressure for features but how many of these features have been validated with users? Is the demand real?

Ron Jeffries speaks out about trading quality for speed. Basically, you're kidding yourself.

I just stumbled on a note I made before Christmas on a tweet from Brian Marick that provided a definition for craft. I tweaked it ever so slightly:

Sooner or later the manager says:

I had to laugh today when a colleague, shaking his head in exasperation following a business priority corridor conversation, distilled the basic forces of software development down into a single statement:

If the customer says he doesn't want "perfect code", he's happy to take low quality code as long it does what he wants it to do, what do you do? We're here to deliver what the customer wants, right. So, do you cut corners on quality? I wouldn't. I'd want to understand the customer's thinking and if it turns out that it's short-term thinking ("I want the cheapest solution so I don't care about quality"), or it's ignorance or plain old stupidity, I'd walk away. My conscience wouldn't permit me to compromise the quality of my work.

Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction, and skillful execution.

Sadly, these days most managers are more interested in the cost of quality than in quality itself. Essentially, they're wondering 'how low can we take our quality before we start losing customers?' They might permit us to improve quality up to a point, beyond which they see further improvements in quality as a poor investment. When a manager warns us that we're in danger of putting too much time and effort into quality, he's wrong! We can't take quality too far. And when scope, time and cost are fixed, as is so often the case these days, we've all been guilty of habitually cutting quality to meet the deadline. It's madness! This is one of the major contributing factors to project failure. Seeking excellence through continuous improvements in quality initiates a chain reaction of positive and beneficial results. Improve quality to increase productivity Originally uploaded by sjb140470 . When you continuously improve quality the defect count is significantly reduced and there are fewer delays. You find yourself with more time to spend on adding new features that are valuable to your customers. Productivity is increased and costs are reduced. People are happy in their jobs. Existing customers see more of the features they've requested materialise in the product with fewer defects, which secures their continuing loyalty. And new customers are attracted to your product because it's feature-rich, has a higher quality and is more reliable than competitor products and comes at a lower price. All this is very good for business.