Agile Governance

As you read more, and become more familiar with the ‘why’ of Agile, you begin to realize that Agile Governance isn’t some unnecessary overhead – its actually absolutely fundamental to how it works.  I’ve been saying for a while that Agile isn’t really a Software Development methodology – its a Product Management one….and until that is truly understood I don’t think anyone can really understand what it really means to be ‘Agile’.  Its a product Management discipline because it both controls how and when Product Management makes changes, and it ensures that once those changes are made, they can be executed without waste.  That’s it, Period!  Everything else that you call Agile flows from that premise – the iterations, the cycles, the continuous delivery etc.  All those are just a means to the Product Management end of managing change.

One Agile doctrine that I believe in is that the decision points should be as discrete as possible – “make the decision, then give time for the decision to be executed, then evaluate, then make another decision” (this is a  PDCA cycle, btw – and yes, its Agile!!).  For that purpose, Cadences are good things (and extremely, extremely Agile things).  Cadences work at various levels – and include making sure that big decisions (such as what will go into a Quarterly release) are made in a deliberate, periodic way which is in sync with the development work.  Another, more technically Lean way of expressing this is to say that the Takt time (frequency of customer/business requests) are synced with the delivery time/cycle.  The bigger the decision, the longer the development work needs to be, and therefore the longer the decision period (Takt) should be.  This is the reason why you want to have Annual roadmap planning, Quarterly release planning, and sub-quarter check points approval cycles – which all reflect different sizes of decisions, and therefore different levels of work and hence size of change.  ALL THIS DOESN”T MEAN THAT THE DECISION CAN’T BE CHANGED – in fact we expect change – but we try to reduce waste by setting expectations of when what certain sizes of changes can be made at what points, and plan the work around that.  In an Agile world, when the decision is changed, you have completed enough of what you WERE working on to be able to move on to the new stuff without waste.  Detailed, story level changes are made within the iteration, larger story-priority calls made from iteration to iteration, and feature/market problem changes made from release to release.