Getting Predictable

Over the past few weeks, I’ve made two assertions about new agile teams. First… teams need to get good at calling their shots. To me, that means that over time, a well-formed, stable team should get good at being able to predict what they will get done over the course of the next iteration. Second… teams need to get good at knowing the size of their bucket. To me, that means that over time, a well-formed, stable team should establish a predictable cadence of delivery… one where their past performance starts to become a predictor of future performance.

These two things are what fundamentally separates an agile project from total chaos. Without the ability to make and meet commitments, without the ability to look ahead and forecast what might be able to get done… we are asking our customers, our businesses, to make an indefinite investment in a project with no general ideal of what they are going to get when time and money runs out. To me… that is total non-starter.

So, granted… there are lots of barriers to a team being able to call their shots and establishing a stable bucket size. First, is that teams have dependencies… things beyond their control, that might prevent them from being able to get stuff done. In addition, many teams are NOT well formed, and DON’T have everything they need to deliver and increment of working software. Some “agile” teams just do the development and pass off their work to a dedicated QA team. All of this is not particularly conducive to establishing any sort of stable delivery patterns.

So… I see these patterns repeated so often, I’m getting to the point where… with every company I work with… we start the conversation with the idea of teams. If you want to do agile, you have to form teams. We can be successful doing something else, Kanban maybe, but the fundamental prerequisite for doing agile, and even having a shot at this level of predictability, is a well formed team that has everything they need to deliver an increment of working software.

That said, I don’t think having a well formed team is enough. Even well formed teams are going to hit things they didn’t anticipate. Teams are going to learn more about the requirements. They are going to learn more about the technology. They are going to learn more about their customers. When you are constantly dealing with unknowns, it’s tough to establish any sort of baseline delivery pattern. The trick is to drive as many of those unknowns into the project as early as possible.

How often are we inclined to get started burning down the backlog by pulling off a few quick wins? Let’s get some of the easy stuff out of the way so we can get started writing code really fast. That kind of thinking is what leads to late discovery in the project lifecycle. It causes late thrashing. You risk building software that is going to change once we are forced to tackle the hard stuff. You leave all the uncertainty until then end when you have the least amount of time left to do something differently.

In order to get good at making and meeting commitments, in order to get good at establishing a steady delivery cadence, you’ve got to deal with your risk and uncertainty… your thrashing… early in the project. That means we are going to build the really high value stuff early so we can get feedback from our customers to make sure we are building the right software. It means that we are going to build the hardest, most technically difficult stuff… the stuff we know the least about… first. That way, if we have to take a different approach, or the project is going to cost more than we thought, we know that as early as possible.

So sure… do I expect a team in this phase of the project lifecycle to be predictable? Of course not. I’m willing to make an investment of several iterations to build some product, reduce key risks, and get the project stable as fast as possible. After I am comfortable that we have sufficiently reduced our risks… I do expect the team to get into a delivery groove as we build out the rest of the product. That means being predictable. Getting the risk out early is an enabler of predictable delivery cadences.

So that’s my take… building well formed teams and early and rapid risk reduction are the keys to becoming predictable. What’s yours?