Options vs. Constraints
One of the things I enjoy most about conferences is the opportunity to meet new people. At Lean Agile Scotland earlier this year, I met Chris Matts, who has spent a lot of time thinking about options and how they can help us build better software. It was great to be able to hear him talk about…
One of the things I enjoy most about conferences is the opportunity to meet new people. At Lean Agile Scotland earlier this year, I met Chris Matts, who has spent a lot of time thinking about options and how they can help us build better software. It was great to be able to hear him talk about the subject in person; his perspective is really valuable. Since that time, we’ve maintained a dialog about options, constraints, and their interrelationship. I’ve learned a lot from it. This post captures some of the ideas we’ve shared.
Options Have Value
If you’ve heard of “Real Options,” you’re probably familiar with Chris and the associated meme:
Options have value
Never commit early unless you know why.
There’s a graphic novel that explains the value of this approach and how keeping options open can provide more flexibility and agility. Much of this is intuitive but far too often, in the desire to get things done, we cast aside options early and lock ourselves down to a single approach to solving a problem.
This happens even in good Agile teams. The pressure of timeboxes and deadlines tends to push us to early decisions and commitments. It’s easy to justify doing this, because our decisions reflect the best knowledge available at the time. It’s hard to remember that new knowledge will emerge as we learn more about our work. We’re professionals; we’re paid to know things. It’s easy to become biased against our own future knowledge, even if we recognize that learning is essential to our success.
A time crunch makes this worse. Small timeboxes increase focus and limit work in progress, but they can have the unfortunate side effect of pushing us into safe, familiar approaches, limiting our ability to explore and entertain new ideas. Setting aside time for spikes and experimentation is a valuable way to resist these tendencies. Thinking about our work from the perspective of options is another.
Optionality reminds us that we’ll learn more as we go and that learning will help expose new options. Agile approaches are intended to foster that. Each time we deliver working software, we get an opportunity to understand more about our stakeholders and how they expect to benefit from our software. Regular cycles of learning are an essential part of exploring, and then exploiting, options.
This is where constraints and options can work together. I haven’t pinned Chris down yet, but I think that he and I disagree about how constraints and options are related. He defines a constraint as a lack of options. Technically, I believe this is true, but as I’ve written about before, I think constraints are an essential aspect of self-organization. Without constraints, self-organized complexity does not occur. Constraints can work in two ways; they can limit options, but they can also trigger new ones.
That’s what happens in an effective Agile team. The constraint of delivering working software at regular intervals leads the team to self-organize. They deliver what they agree will be most valuable. That delivery triggers learning, exposing the limits of their current knowledge, and revealing new, unanticipated, options. In this way, constraints and options work together to produce effective software. The team leverages constraints to discover options and create new ways to address their challenges.
This approach is most effective when the team and their stakeholders recognize that they cannot know everything up front. They must embrace the idea that new knowledge will emerge and that learning is essential to discover the best solution. To me, that is the real power of optionality. By helping us remember that the ability to make a choice has real value, optionality encourages us to maintain freedom in our decision-making and prevents us from locking down our approach too early.
I think this is a good way to summarize it (derived from this post):
The last responsible moment preserves options and our ability to make a choice.
The first irresponsible moment eliminates options and forces our hand.
I encourage you to try this with your teams. Think about the options you have. Think about how you might preserve them while you learn more. Are you locking down decisions at the right time, or are you making them too early under time pressure? Do you consciously decide to exclude other options? Do you understand the costs of those decisions? The perspective of optionality is a good way to have more effective conversations around those questions.
You Might Also Like
When you think of the term “Agile Coach” your first thought might be someone who...
“Between stimulus and response, there is a space. In that space is our power to...