In Part 1, I wrote about the origins of drivers, constraints, and floats. I needed them when we only could release the project once to the customers. You saw the questions that help people choose the project driver.
What about the constraints and floats? I think of constraints as bounding the project inside the driver, and floats as degrees of freedom.
Constraints Bound the Project
Even if you use an agile approach, you still can't create an impossible project. You can't predetermine the entirety of:
- All the features
- All the people you need
- The final date you can deliver
- The total cost of the work
- The quality of the delivered work
- The environment of the work.
If you try to fix all of these at the start, you will fail. Something will happen and you will need to replan. You won't have enough time. Or, as you approach the work, the features are much larger than you thought. Or, you need to experiment some more with smaller feedback loops to understand what to deliver.
You can't have all of it, not for the cost and the people you have. You need to release several constraints.
The idea behind defining the drivers, constraints, and floats is that when we define them, we can have different conversations. That's why defining one or two constraints might help us create guardrails for the work.
The constraints help us make decisions.
Constraints Guide Decision-Making Throughout the Project
One of my clients in the Visionaries part of the early market had typical problems:
- At least four separate types of customers, all clamoring for slightly different customer sets (features and time)
- One set of current customers who wanted a couple of small fixes for previously-released functionality.
- Only two small cross-functional teams available to work on the product.
So, they appear to need to constrain the feature set, the time, and the people on the project.
To me, that's too many constraints. We might use two of those as constraints, but not all three. We need enough degrees of freedom.
They started the conversation with context-free questions.
Start With Context-Free Questions
When I started to work with this organization, the product people thought they needed “all of it.” They were stuck in “how much” thinking, and not considering how little thinking. (See Reframe the “How Much” Conversation to “How Little” and Minimum Outcomes.)
And, because they thought they needed everything, they had the problem of requirement spawning requirements.
These folks had a software-only product, so their agile approach helped them finish work. However, they didn't release as they finished features. They wanted to wait until they had “everything.” As a result, they were in danger of losing these potential customers. (In the early market stages, competitors leapfrog over each other with new features.)
I asked these questions (see What Does Success Look Like for an earlier version of these questions):
- What does success look like for customer set 1?
- Why do you desire those results? What do both you and customer set 1 get from those results?
- What is the value of those results?
- What problems does this feature set solve for customer set 1 and you?
- What problems does this feature set create for customer set 1 and you?
We planned to repeat these questions for all four customer sets.
At first, the product people wanted to answer these questions alone. (I'd also thought that was a good idea until I spoke with the team members.)
Since we had a total of fewer than 20 people, I suggested they get everyone in a room for 90 minutes and we would work through the answers as smaller teams.
We created 4 smaller teams. Each team chose a customer set. They then answered the context-free questions for “their” customer set. We compared the answers (yes, using stickies on the whiteboard so we could move things around).
We discovered that all customers needed some very small set of features. That became our next driver. Not all features, but those features. (This is a case where frequent releasing allowed us to reduce the constraints from the entire feature set to some features.)
And, time was the next driver after that small list of features.
The company thought their project driver was cost. The company had to manage its run rate so it didn't run out of money. They thought their constraints were the small feature set and the desired release date.
I thought their driver was time to release for that small feature set. (I suspected that if they needed more money for a week or two of work, they could have found it. They disagreed with me.) I thought their constraints were the small feature set and cost.
My disagreement with the client didn't matter. What did matter was the conversations about how they would make decisions so they could succeed.
They had the tools to have the necessary ongoing discussions to make this project work.
Frequent Releasing Can Free Some Constraints
The more often your project can create small stories and use flow-based roadmaps, the more constraints you can accommodate. Not all, but more.
That's because small stories and working in flow frees people from “all of it” thinking.
If you have a product with various customers who want different features, you still need to rank each story inside a feature set. If you also use flow-based roadmaps and think about your minimums, you can convert your constraints to floats.
Here's how this client did it:
- They created several feature sets. Think: Payments, Notifications, Search.
- They ranked the stories in each of the feature sets.
- They always had a #1 story next for each of the feature sets.
- The two teams each agreed to take the next ranked story, regardless of the feature set that story belonged to. (Team 1 typically did Payments and Notifications. Team 2 typically did Search. The teams agreed they wouldn't wait for their story—they would take the next story.
- Each team used swarming and mobbing to focus on that story. They mobbed when they had no idea how to attack the story.
- If the story was going to take more than 2 days as a team, they asked for help from the other team.
- Yes, once both teams needed the other team. The POs had to decide which story was more important.
They were able to start releasing something every day or so. They could start to acquire those new customers in small batches, not as a large “capture this market” approach.
Floats Offer You Freedom
The pyramid has six sides. The more you can free each side, the easier it is to manage the project.
In this example, I would say that the work environment made a huge difference. The teams chose to:
- Use an agile approach.
- Keep the team WIP limit to 1 item.
- Always work on the highest-ranking feature regardless of its feature set.
- Release as soon as possible.
Instead of feature set and time to release being constraints, the teams used those initial constraints to create very small features and release them fast.
Most of my clients have trouble with these ideas of small WIP limits and fast releasing.
Back when we had only one release date, I often used different life cycles to manage those floats. (That's why Manage It! talks about replanning and the various life cycles that you can select.)
Notice that an agile approach buys you ways to break the constraints and create more floats. I'll write about other choices and life cycles in the next post because not everyone can create the environment for a successful agile approach.
All the posts in this series: