Thursday, December 29, 2011


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...


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, via the Blog, or Twitter.


Joerg Hinrichs said...

Hi Dan,

first of all, great article, i agree with almost anything that you said here.

Just one thing bugs me a little and that is about perfect requirements. Now, i don't think it makes sense to define the whole set of requirements upfront.

But i do think, that the one you are working on next should be examined very thoroughly. I especially found that if you omit certain information for a requirement, chances that you get in trouble (=need to redevelop) are a lot greater.

For example, if i only concentrate on the feature itself and don't ask about the corresponding business process(es). Or if i don't ask what this feature really is meant for.
Asking those two things probably could have saved me and others a ton of time.

What do you think about that? Did you make different experiences?

Greetings from Germany
Joerg Hinrichs

Victoria D. said...

Hey all!
Can say that I agree about all parts of the article. Even about requirements. We often have only initial requirements for the Sprint1 and then plan the new issues as for the new requirements.
Even though it's easier to start when you know everything, it never happens.
P.S. Den, I think I'll be reading your blog regularly now.