Governance and Agile - How to Ensure Effective Governance in Agile-Enabled Organizations

Mark ArntzMon, 04/09/2018 - 17:24

Governance and Agile - How to Ensure Effective Governance in Agile-Enabled Organizations

When I teach Agile at many historically traditional approach organizations like pharmaceuticals, financial, and health care organizations, a complaint I often hear is that the nature of their business with high regulatory control and expected rigor would make it impossible for the Agile approach to work.  In answer to this I’ve developed a list of five places where this governance can be placed in the Agile processes so that they can indeed pursue an Agile approach to doing software development.

  1. Create a User Story and put it on the Product Backlog
  2. Add administrative overhead to the Iteration
  3. Add to the Definition of Done
  4. Add another Done after Done-Done
  5. Add to the Definition of Ready

Create a User Story and Put it on the Product Backlog

Let’s say, for example, that your company is Intuit.  Intuit created the product TurboTax.  If the IRS comes up with a new tax code, what is Intuit going to do?  They’ll just write a User Story for implementing the new tax code, put it on the Product Backlog and the Product Owner will prioritize it with all other work.

Add Administrative Overhead to the Iteration

I was recently teaching at a large company in the Research Triangle Park in Raleigh/Durham, NC.  I asked them if they have to fill out timesheets.  They said, “No”.  They were rather gleeful in their answer.  I then asked, “What if the company just got a new CFO who insisted that tracking time to project codes was necessary for the capitalization of software development leading to tax savings.  They said that they would grumble and complain.  But would they do as the CFO was requesting?  Of course they would.  This would just become a layer of administrative overhead that would encroach on their velocity.  The Agile premise of maintain a constant pace would preclude adding this to the top of their day.  Instead they would be taking some time that was otherwise used to produce new software and reallocate it to filling out timesheets.  Of course, it would hopefully have a very small impact, but it would have some impact.

Add to the Definition of Done

We all know about all of the hacking reports from places like Equifax, Home Depot, Target, Sony and others.  So the Security Group at your company wants to be more vigilant about protecting client information.  They create a list of things that they want the software group to be aware of and check for in the code as part of the development process.  This checklist would be added to the Definition of Done.  The User Story is not done until you have done a list of things, and at the end of the list is Review the Security Checklist.

 Add another Done after Done-Done

The Definition of Done is frequently referred to Done-Done Criteria.  This is because, for something to be Done, first the work is done by the development team Done One, and then the Product Owner reviews it against the Acceptance Criteria, Done Two.  The User Story is not Done until it’s Done-Done.  Well, what if the Security Group mentioned in the last point doesn’t trust the development team to adequately check the code for vulnerabilities and they want a shot at it before it is shipped.  This becomes a check-it-out that happens outside the Iteration.  We have to be careful with this one.  One of the things we don’t want happening, is we don’t want this separate check-it-out to become a safety net that the dev team is relying on for assurance that they have done it right.  This would increase the waste of rework in our value stream.  So we will track all defects that come from this after-the-iteration-check-it-out process (called escaped defects).  We would consider these as BAD.  We would want route cause analysis done on these and drive them down to zero.

Add to the Definition of Ready

You may not have heard about the Definition of Ready.  But why not have a Definition of Ready that are the pre-requisites for taking a User Story into an Iteration for implementation?  This could contain things like:

  1. The developers agree that there is enough detail to proceed
  2. The Product Owner agrees with the Acceptance Criteria
  3. The User Experience group has approved the wireframes

Of course, you don’t want to do anything here that is not needed, that would represent a form of Goldplating, but if we are the type of organization mentioned at the start of this blog, it should not keep us from pursuing an Agile path.  Over time, we should keep in mind that this all costs and try to reduce these things as is possible.