Expressing Pain

One theme on my mind right now is the proper expression and treatment of “Pain” as a core part of Scrum Agile working as intended. Schwaber and Sutherland said they promise one thing only from Scrum, everything else is a nice side benefit. Scrum will show you all of your problems. In order for that to work, the processes, Roles, Artifacts, Ceremonies are the given “rules” for what specific things to hold constant. Then let the pain be expressed where it actually happens. Hold everything constant that you can. Automate, routinize, and forget about everything that can be standardized. Reduce your degrees of freedom as much as possible. This will leave 2 things:

(1) The pain will be expressed in the correct place. The leak will happen in the correct pipe. That’s what we want to happen. We don’t want to allow the leak to spring in the wrong place because we’re trying to prevent the pain from coming out. That will lead to making the wrong changes from learning the wrong lessons (or not learning lessons at all).

(2) You will find out all the places that can’t be routinized. Where you need human creativity, innovation, people skills. This is the “Individuals and Interactions”, the “satisfying customers early and often”, the “working together daily”.

What prompted this was a question from a Product Owner about a story that we know will not be completed due to an upstream input we can’t control. He asked if he should just drop it to the Product Backlog now and pick it up in the next Sprint, or should we keep it and discuss it in Review. Every item for Review is a chance to look at a pain, and look for a solution. If we just pull the story mid-sprint, then we won’t talk about it during Review. We’re avoiding expressing a pain. This specific story may not be the magic key that unlocks all the answers. But some story might be.

If we skip steps in Sprint Planning, Review, Retrospective, or Daily Scrum then we’re skipping a chance for the correct pipe to spring a leak.

It is incredibly tempting to practice management as foreseeing, avoiding, and preventing pains from being expressed. This will lead to crippling a structure bit by bit, from a series of wrong changes to all the wrong parts. In writing code the answers are buried in the problem itself and you discover those answers by expressing the pain.

The first thing the doctor asks you is “where does it hurt”?

This may be the most important concept in the procedural aspects of Scrum.