The Baby and the Bath Water

Don’t throw out the Baby with the BathWater — illustration from Die Narrenbeschwörung ((Appeal to Fools Written by Thomas Murner in 1512 — PD-US-expired

There's an old saying that you shouldn't throw out the baby with the bath water. There's scant evidence that this has actually happened, despite the woodcut illustration depicted here, but the saying should be taken to heart when considering which Agile practices to adopt and which to abandon. With the dozens and dozens, if not hundreds, of Agile practices, tools, and techniques, how do you know which ones are right for you, your team, and your organization?  Which practices are the babies and which the dirty water?

Scrum has gained popularity over the years in part because its framework is simple. This simplicity does not mean that Scrum is easy to adopt and practice. On the contrary, I often say, "Scrum is simple.  Doing Scrum is hard."

A basic premise of Scrum is that if what you are doing is working, keep doing it. The flip side of this premise is that if what you are doing isn't working, change it. Scrum doesn't prescribe which Agile practices to fit within its framework, but rather leaves those decisions up to a self-organizing team to figure out.  This "figuring things out" is the hard part of doing Scrum. Those that accept the challenge can see their teams achieve significant increases in value creation.

So what do you keep and what do you throw out?  Let's look at a couple of examples.

For a team just starting out with Scrum, it makes sense to keep the rules of Scrum. For example, be sure you have a single Product Owner. The absence of empowered Product Owners has spelled the demise of a Scrum adoption for more than one organization.

For this same team, it may or may not make sense to have a release plan. The decision on whether or not to adopt release planning as an Agile practice can be tricky. Early writings on Scrum often mention release planning, but the majority of Scrum experts now concur that release planning is not "core" Scrum. In other words, it is not a rule of Scrum that a team must conduct release planning.

How do you know whether or not release planning is for you? Well, release planning does have its good points. It might help establish boundaries, manage expectations, force timely and appropriate decision making, make clear why certain tradeoffs are being made, and so forth. On the downside, release planning can impose senseless rigidity, artificially constrain options, promote magical thinking (i.e., "I will get everything I want, when I want it, and at the contracted price," despite a different reality), and delay urgent adjustments because optimization has been abandoned in favor of "sticking to the plan."

The mechanics of Scrum help the organization move towards self-discovery of what works and what doesn't − as long as the organization is listening and acting on what is learned though practice. I like to think of Scrum as an accelerated learning framework. Each sprint is an experiment, a learning opportunity. The learning occurs in many dimensions. Two of these dimensions are the product and the process. First, the organization learns something about the product through inspection of the product increment produced during the sprint. The results of this learning should be seen in the adjustments that are made to the product backlog. At the same time, the organization learns something about the process that they used to create the product increment. The results of this learning should be seen in the changes made to improve the process going forward. Other dimensions of learning follow a similar pattern.

To decide whether or not a practice like release planning is for you, plan on some experimentation. In the case of release planning, make sure the release plan and release planning activities are serving a product optimization goal.  Prepare for some open and honest conversations about the purpose of the release plan. If your product or service would benefit from release planning, do it. Don't abandon release planning as a practice just because it's hard.  That could be like throwing the baby out with the bath water.

If on the other hand, you look in the bath and it's just dirty water, by all means, throw release planning out.  A practice that has no value for your team or worse, enables ingrained pernicious behaviors, has no place in your process.  Discuss the reasons for why the practice is not working, and find one that does.