Agile Zone is brought to you in partnership with:

Mike is a certified PMP project manager and a certified ScrumMaster. Mike was involved with the creation of the DSDM Agile Project Leader certification, holds this certification at the Foundation, Practitioner, and Examiner levels. Mike was named an honorary member of the DSDM consortium and served on the board of APLN and the Lean Software and Systems Consortium. He currently co-leads the PMI Agile Community of Practice. Mike is a DZone MVB and is not an employee of DZone and has posted 117 posts at DZone. You can read more from them at their website. View Full User Profile

Getting Predictable

09.07.2010
| 932 views |
  • submit to reddit
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?
References
Published at DZone with permission of Mike Cottmeyer, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Emma Watson replied on Fri, 2012/03/30 - 5:55am

The PO is a dysfunctional response to traditional poor communication. It creates a bottleneck for information, responsibility, and blame. The role is hard to fill because of its current definition.

Swing

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.