Thursday, December 29, 2011

Medication


Dan Mezick

I'm pleased to add this content to Jeff's blog regarding pain medication and the Agile Manifesto.

Delivering software as a team is a highly intentional act. If we say we want working software, the results are by no means assured. Confronting reality, at the level of group, is the name of the game in software development. The alternative is pain medication...


Medication

If you check out the Agile Manifesto, you find that we often medicate with the things listed on the right in the Values section.
Medication is usually in the form of a pain killer of some kind. The whole right side of the Agile Manifesto lists various forms of medication that enterprises, departments and teams use to relieve various forms of pain.
Examples of pain-killing medications:
  • Processes and Tools
  • Comprehensive Documentation
  • Contract Negotiation
  • Following a Plan
Lets look at each in turn:

Process and Tools

We medicate away from facing [Individual and Interactions] by focusing on processes and tools. We focus on these, and away from [Individual and Interactions] because we might have to get real and face the reality of people and interacting with them. We might have to get some new social skills! Ouch, that smarts. Where are my pills?

Comprehensive Documentation
This usually manifests as the need for “perfect” and “comprehensive” requirements. We medicate with these, and avoid dealing in the reality that what we must create is [Working Software]. We focus on perfection in requirements, and away from STARTING. Starting is risky and who knows what might happen? The reality is we cannot learn till we pay attention, and we do not pay attention till we start. Got that? OK, so START NOW with your imperfect non-comprehensive requirements. It’s going to be (perfectly) OK.

Contract Negotiation

OK, OK we need to know what to build. I agree. Let’s also agree that it is unreasonable to expect everyone to know exactly what they want, 100%, at the start of the process. We focus on contracts instead of [Customer Collaboration] because this stuff is hard. So, we medicate with the contract. It gives a sense of control, see? That stops the pain of dealing with what is in fact an uncontrollable, increasing complex, high-change world.

Following a Plan

“Planning” usually shows up as “prediction-in-drag”: in effect, a wild-ass guess masquerading as planning. If prediction is so very easy, why isn’t everyone a stock market winner? See it? Prediction is difficult… and way over-rated. Plans are great and we need a direction … and a general way to move in that direction. But let’s not pretend we can predict very much at all. Instead, let’s [Respond to Change]. Ouch, that hurts because I might have to question my beliefs, to address any really unusual changes. I might have to re-factor my model of reality.
That’s a whole lot of hard work, making painful edits to what I currently believe.
Ouch, that smarts. Where are my pills?

Dan Mezick is the author of The Culture Game , teaches and coaches Agile at New Technology Solutions, and helps create community (and events) via the Agile Boston and Agile Connecticut user groups. Reach him at dan@newtechusa.net, via the Blog, or Twitter.

Thursday, December 22, 2011

Powerful Strategy for Defect Prevention: Improve the Quality of Your Product



A classic paper from IBM shows how they systematically reduced defects by analyzing root cause. The cost of implementing this practice is less than the cost of fixing defects that you will have if you do not implement it so it should always be implemented.

1. First understand your architecture and where the bugs are coming from by type, severity, component, and point of injection during the development life cycle.

2. You will find 80% of the bugs come from 20% of the code. Mapping these defects on a component architecture will show swarms of bugs around specific components.

3. Apply bug spray through a carefully prioritized automated testing strategy. Find the biggest problem that occurs when doing final regression testing prior to deployment. Implement an automated test that makes this problem impossible to happen again using the detailed knowledge developed about bug infestation in your product. Write a single test that can prevent 100 common problems. Then go to the next highest priority problem and repeat. Doing a few automated tests a week will eventually make your build bullet proof with remarkably few tests.

In three months, one of our venture companies cut a 4-6 week deployment cycle to 2 weeks with only 120 tests. It took one person three weeks to write the test and eliminated several weeks of work by an entire team. It reduced defeats, radically reduced support calls, and the customers liked the new release enough to buy more product, raising revenue.

Everyone should implement this. The return on investment is astronomical. I thought this was basic stuff but our investors say almost none of their companies have implemented it until we invested in them. The developers are often junior, right out of university, and the managers are domain experts, not engineering experts. We have to teach them the basics.

by R. G. Mays, C. L. Jones, G. J. Holloway, D. P. Studinski
IBM SYSTEMS JOURNAL. VOL 29, NO 1, 1990

Defect Prevention is the process of improving quality and productivity by preventing the injection of defects into a product. It consists of four elements integrated into the development process(: 1) causal analysis meetings to identify the root cause of defects and suggest preventive actions; (2) an action team to implement the preventive actions; (3) kickoff meetings to increase awareness of quality issues specific to each development stage; and (4) data collection and tracking of associated data. The Defect Prevention Process has been successfully implemented in a variety of organizations within IBM, some for more than six years. This paper discusses the steps needed to implement this process and the results that may be obtained. Data on quality, process costs, benefits, and practical experiences are also presented. Insights into the nature of programming errors and the application of this process to a variety of working environments are discussed.