Managing to the Constraint

There is a part of me that is a little uncomfortable with my conclusion at the end of the ‘Velocity in the Enterprise’ series. Using a Kanban metaphor at the team, project, and portfolio level makes sense… I also think it is the right way to look at things… but I have a hard time recommending things that I think are really, really hard to actually do… at least without providing some sort of transition state to help you get there. I want to explore another mechanism for accomplishing basically the same effect, but without having to fully re-factor your entire organization.

For the purpose of this post, we are going to make some assumptions about your organization. We’ll assume that in some form or fashion you are organized around small cross functional teams. These could be either feature teams or component teams. As long as we have a team that can establish a velocity, that’s sufficient for our discussion We’ll also assume for the time being that each team is working in a many-to-many fashion across several projects (or some combination of projects and non-project work). In short, we have assumed ourselves into the exact environment where velocity at the enterprise level doesn’t work.

What if… rather than introduce a new planning framework… and a new language around Kanban, constraints, and cycle time… we just handled things a little more implicitly?

Managing Projects

Here’s what I mean… Let’s say that we have a project with a backlog of ‘value features’… items that will actually create value for an end-user… something our customer is willing to pay us for. What would our project goal be? Just like a team wants to establish a stable velocity, to be able to use past performance as an indicator of future performance, the project needs to be able to do this too. Our goal is to be able to reliably and consistently deliver value features. As a project team, we pull the next set of value features into the iteration. Next we break down those value features into user stories that get allocated out to the various team level backlogs.

As a project, we know that we’re only going to start things we can finish. We know we aren’t going to tee up work that isn’t going to get done in the next iteration or so. What we’ll find is that some teams will have too much work and other teams won’t have enough. Those teams with too much work are our constraints… they are our critical path. How do you shorten your critical path? You apply resources or you figure out how to do things in parallel. Shortening the critical path is the only way to actually shorten the project. At the project level, our job will be to groom backlog up to the point we have consumed all the resources on our most constrained team. The availability of capacity at the constraint limits how fast we can deliver value features as a project team.

What we have (in effect) done, is create an abstraction layer between team performance and project performance. At the team level I care about velocity because I can use it as a metric for continuous improvement. I can use my velocity to predict throughout and make commitments. At the project level I am not trying to map team level performance to project performance… I have abstracted them from each other… because at the end of the day, all I REALLY care about is project level velocity… it’s the project level velocity that delivers value. I will also have to pay attention to the velocity at the constraint too… but not because it is directly correlated to project performance… but because that is where I need to focus resources and improvement initiatives to get my project to go faster.

Managing Portfolios

Now here is the deal… projects need to be prioritized just like we prioritize user stories. The number one project in the queue needs to get all of the resources at the constrained team. Okay… maybe the first and second interleave a bit… but in general… the constrained team should always be working on the most important stuff. This is going to force some amount of serialization of the project portfolio… we are only going to have one or two of the most important initiatives going at any one time. We’ll be able to have that conversation because we know what subset of the organization is constraining our ability to build software. Giving them more stuff to do will only slow them down.

But what about those teams that have extra capacity? We learned earlier that some of the teams are gong to be less busy than the constrained team. True… but here you have a few hard decisions to make. You can either redeploy those people to work at the constraint… or… you can give them features to build that can be delivered independent of the constraint. Here is the hard part… if you a team work to do, work that requires resources at the constraint… and the constrained resource isn’t available to do the work… your taking a pretty significant risk that the team is building the wrong product or that teams will get out of sync with each other. You risk that they are creating waste and distracting your organization from it’s highest priority objectives.

So what happens at the portfolio level? Just like the project velocity is abstracted from team velocity… the portfolio will establish a velocity that is independent of the team as well. At some point we’ll be able to measure how many ‘project points’ we are able to get done a quarter. We still care about team velocity… we still care about value feature velocity… it’s just that we don’t count on these metrics to be directly related to portfolio performance. We are in effect applying the same principles of abstraction between individuals and teams to team and projects and ultimately projects and portfolios. Each layer in the management hierarchy has its own velocity but it is not directly related to any of the velocities of the lower order management structures.

Managing your organization by managing to the constraint allows this to work.

Velocity in the Enterprise, redux

You see… we are really applying many of the same TOC (theory of constraints) principles we talked about when we talked about enterprise Kanban, but rather than try force a whole paradigm shift… we are leveraging much of the same language and all of the same principles to actually make velocity work. The difference is that we are leveraging the management team… or the project management team… maybe even the product owner teams… to allocate (or limit) work based on knowledge of the constraint, and to stop assigning work when teams are at capacity. We are dealing with the constraint implicitly using shared understanding of the methods and principles rather than the explicit constraint of a Kanban board.