Throttling the Agile Enterprise

It feels like a year ago I did the post Enterprise Constraints and Feedback. The past few weeks have been filled up with the Lean & Kanban conference and some client work that required my undivided attention. Toward the end of that post, we talked about 6 principles that allow your organization to properly throttle work through your agile enterprise. I wanted to take a moment this afternoon and explore those a bit and see where it takes us:

Make small bets by approving smaller projects

How many of you guys have been on an 18 month project? How many of you have been on an 18 month project that got killed or totally re-scoped after a year or so? The reality is that in today's economy the uncertainty associated with large scale software development projects is just too high. The longer it takes to get product to market, to get real customer feedback, and to start generating revenue... the more risk you accept as an organization. Given our track record of project failure... smaller projects are less risky projects... and therefore better projects to approve.

Prioritize for finishing projects rather than starting projects

This is a complicated one. It gets into this whole discussion around keeping work in progress to a minimum and optimizing for the overall throughput of the organization... rather than for optimal resource utilization of the individual. If you are an agile organization, and have bought into the idea of organizing around teams, you should be pretty good with the idea of 'done done'. 'Done done' means that we don't deliver partially completed work. The only features that count are the ones that are ready to be shipped to the customer.

Interleaving a bunch of partially complete projects just makes the overall system deliver value less effectively. If we have three projects in the portfolio that are all planned to take three months each... and I do them one at a time... when will they be done? The first one will be done in three months, the second in six months, and the third in 9 months. What happens if I try to do all three at once? Best case you might deliver the first in 7 months, the second in 8 months, and the third in 9 months. More likely you'll deliver the first one in 12 months and the other two will get killed.

Don't start projects that you are unable to finish

Building on this idea of prioritizing for finish rather than start... if there is more than one team that has to work together to deliver a project... or even a MMF... and we can't get all the work 'done done' within the time-frame allotted, don't start it. We usually use some form of logic that goes something like... well, we have this person or this team with nothing to do... let's get them working on the next project. Keeping people busy is not a good reason to start project work.

The problem is that starting the next project dilutes the organizational focus from working on the projects that are already in process. Chances are pretty good too that when the other teams free up requirements will have changed or we'll learn something that leads to significant rework. This is tough pill to swallow... but I would rather that idle team go help another constrained team... or even do nothing... rather than start work on a project that is underfunded and low on the priority list.

Work on the highest priority projects first

All of these are pretty closely related, but if we always prioritize the project that is most valuable to the business... and we always focus on getting projects to 'done done'... and we don't waste effort by working on things that don't have the support of the rest of the organization... we know that we will always be delivering the most valuable features to the business with the least amount of waste from building software that might not ever be consumed. This might mean that teams are idle at times... it might mean that teams need to be redeployed... and it might mean that you need to let some folks go.

Make sure to read the next section before you go and start laying folks off from your team... there is hope!

Provide support for those teams that are slowing down your ability to deliver

If you find that a large part of your organization isn't busy because one particular team is slowing everyone else down... cool, you have just found where you need to go help. An enterprise full of teams building software is a continuously shifting set of constraints just waiting to be optimized. Someone at the Lean/Kanban conference said that a perfectly optimized organization has only one constraint optimized at a given time. An organization with every team optimized is actually the least optimized overall system.

Having identified the team that is slowing down your ability to deliver, you have identified where you need to go get better as an organization. By focusing your attention on the team that is preventing the other teams from delivering valuable work to the organization, you are focusing on the area of your development organization that is going to yield the most productivity gains for the overall system. It does not make any sense for a team to get better delivering software if they are not your primary constraint.

Establish an enterprise level velocity

If each team has a velocity sprint over sprint... and we start making smaller bets... and we prioritize for start... and we don't start things we are not able to finish... and we start working on the highest priorities first... and we elevate our constraints... you know what happens? We can start measuring project velocity across the enterprise just like we measure point velocity within the team.

Pretty cool idea... let me know your thoughts on this one.

Subscribe to Leading Agile Subscribe to Leading Agile