Create & Manage the Project’s Bounds, Part 3 (Constraints and Floats for Infrequent Delivery)

I wrote about how to pick a driver in Part 1. In Part 2, I wrote about how you might finesse some of the constraints and floats if you can release frequently.

What if you're like this organization, Acme?

Acme has been working towards agility for the last couple of years. However, they still have these problems:

  1. Their stories are too large to ship something every day or even every other day. They can barely complete a feature each week. (Their cycle time tends to be closer to 10 days.)
  2. They're still organized in component teams. (Their teams work across the architecture, not through it. That means they have a delay before they know if they created a feature.)
  3. They have a separate deployment team. That means even when the teams manage to create features, the teams have to wait to see the release of the features.

Acme sees more progress than they did before. They still release infrequently and at a relatively high cost. They can't use frequent releasing to finesse their constraints and floats.

They have to define their constraints and floats. That means they need to know the “whys” behind this project.

Define the Project's “Why” to see Constraints and Floats

What is the reason behind this project? I wrote about defining the project purpose in both Manage It! and in Create Your Successful Agile Project.

Ask yourself these questions:

  • Who is the main recipient of the project's outcome?
  • What can the main recipient do with that outcome?
  • What is the value to the main recipient?

You might use impact mapping to show yourself the reason(s) for this project.

These questions and/or impact mapping help you see how little you can do for this project, so you can finish and release.

If you don't know why you're doing this project, you don't know enough to start. Without the why, you can't answer the questions above or the context-free questions below.

  1. What does success look like?
  2. Why are these results desirable?
  3. What is the solution worth to you?
  4. What problems does this system solve?
  5. What problems could this system create?

Let's walk through Acme's thinking for Release 6 of their flagship product.

Explain Constraints and Floats Through the Customer's Perspective

Acme's product is firmly in the mainstream. Release 6 adds significant additional features to the product.

Acme has a small program of six teams. Each team has a project manager and a product owner. The project managers facilitate the team's work. They don't create Gantt charts or anything else like that. They spend most of their time identifying and removing impediments.

They don't have a program manager (as in Agile and Lean Program Management). The project managers work together as a self-organizing team to discuss and manage the various impediments they see. They've been sort-of successful up until now. (Each project has delivered, but their cycle time is a systemic problem and the PMs can't seem to solve that yet. I suspect that the various managers dismiss each PM's worries.)

The product owners still tend to create large PRDs in advance of the work. They're working on that tendency, but their manager rewards them for the PRD, not the finished features.

(If you're wondering, yes, this is a real client.)

Discussions Took Time

The managers wanted the work to start right away. They wanted the teams to be totally consumed with this work and deliver it all. And, because there was a specific marketing event, the managers wanted the teams to complete the work in about six months.

When the project managers looked at their cycle time, they explained that the roadmaps had more features than they could finish in a year. The PMs got together with the product owners for release 6 and asked the three questions about the main recipient and the project outcome as above.

The product owners realized they each thought of different customers. Once they agreed on the main customer, they discussed the outcomes. They discussed the value for the customer and Acme.

And, the PMs got together and had a straight conversation with the managers. (Yes, I facilitated that conversation because the managers still wanted all of it in six months. The PMs and I knew that was not going to happen.)

When the managers realized the PMs were not going to start impossible projects, they relented. It took several days of frequent meetings. Those meetings weren't pleasant to start. However, as we discussed their options, the managers made these decisions:

  1. Time to release was king (the driver). They had to release something in 6 months.
  2. That something had better work and they needed to not break anything else. (Constraint: low defects)
  3. Everyone agreed that they would float: features, cost, people, and environment. As long as they had “enough” features, they would be okay. The number of features was actually low—maybe a total of 6 features per team. That was good, because the cycle time was so high.

That last item about features took us a lot of decision time. The managers were concerned the customers wouldn't find enough value in this release. We reviewed the main recipient questions (above) and explained the customers probably couldn't take more than the features we thought we could deliver.

Now the PMs could manage the risks.

I'll do a summary post and leave lifecycle discussions for a different series.

All the posts in this series:

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.