We live in a world filled with constraints. Sometimes, those constraints are on where we can travel or be. Sometimes, those constraints are about our physical capabilities (such as my vertigo or my height). Many constraints we impose on ourselves or allow our organizations to impose on us.
Often, we fight against those constraints inside our organizations, or what we think we impose on ourselves. Sometimes, we don’t need to fight those constraints. Sometimes, constraints offer a frame that help us create better solutions, or use alternatives to generate more options for success.
When I teach my writing workshops, I ask people to write-down, without editing, for 15 minutes at a time. I impose that constraint. My students don’t always appreciate that constraint. We discuss it, in email and in coaching and see why they don’t appreciate that. We work through their problems. (Often, their problems arise from what they were taught in school. Please note that the teachers who taught writing were not writers. Yes, irony intended.)
We often have constraints at work. Too often, we get a project with an end date, a scope, and a specific set of people. Our managers tell us, “We can’t change anything. You must deliver all of that, in this time, with this team.” Ah, total nonsense. (I wrote this first post about estimation and Predicting the Unpredictable to address that problem.)
Here’s the thing I find fascinating. When I ask, “What could we do to live within these constraints?” I often hear amazing possibilities from the project team. Especially when teams consider agile approaches, they generate these ideas:
- If we deliver some features, maybe we don’t have to do it “all.”
- If we show progress (working product), maybe we can ship something “early.”
- If we satisfy some customers, maybe we can stop before we do it “all.”
Too often, especially when project teams use non-agile approaches, they can’t deliver anything early. (The curse of the waterfall.) However, in those cases, the managers often realize that yes, they can extend the end date. Or, they can reduce the number of features. Or, they can add more people (at the risk of Brooks’ Law). Constraints might be more malleable than we think.
Instead of constraints restricting us, here are ways constraints can act more like guideposts:
- If our constraint is that each piece of code and test must have review, we create more options such as code review, pairing, and mobbing to accomplish the review.
- If we have a constraint that we must write without stopping for fifteen minutes, we might prepare differently than if we have all the time we “need.” We might list three ideas or mindmap or outline. We limit our possibilities to fit into the timebox.
- If we have a deadline as a project constraint, what if we made shorter deadlines, as in timeboxes? This is one of my favorite ideas. I use 10- or 15-minute timeboxes to finish some small piece of value. That helps me start and finish because all the work is small.
Constraints might be freeing if you can think about them so that they help you reorganize and finish your work.
That is the question this week: When do constraints help?