Optimising control constraints

Here are some notes I wrote for a client on how to optimise the constraints created by controls on the Require to Deploy to Run value stream.

IT exists both to protect and to serve. Controls are essential to protect one of the organisation's greatest assets: information and the technology to manage that information. But achieving velocity through quality requires that all "necessary non-value work" get out of the way of value work.

So here is a checklist of tactics to minimise the impact of necessary controls on the flow of work, in ascending order of difficulty. Work your way down it until one gets the result:

  1. Bring the control to the flow. Make work visible and have the governor observe the flow, instead of value workers having to go to the governor, often with some additional control artefact. A governor should observe the flow of work and express interest in units of work (and stay out of it the rest of the time).
  2. Preapprove the work, e.g. Standard Change
  3. Get an exemption, e.g. anything under 10 days or $10k
  4. Substitute your own control, which delivers the same outcome as the existing control. E.g. we don't write release notes any more because there is a report in JIRA that generates them on demand
  5. Get delegated authority in the team, e.g. a team member is authorised to do architectural review and escalate to architecture review board only when necessary
  6. Aggregate the control, e.g. one change ticket for a group of tasks. Or a pool of budgeted money for a standing team to draw on instead of having to ask for each task.
  7. Simplify the control, e.g. Challenge the level of ceremony: do we really need all these forms? Or remove redundancy: record nothing which is already recorded in the automation and management tools.
  8. Make the control parallel to the flow of work, e.g. a standing performance test capability which allows developers to test at will
  9. Make the control incremental, e.g. the solution architecture document starts as a photo of a whiteboard, grows to a powerpoint, to a skeleton document, and finally to the as-built doc. Or security approval starts as a provisional light certification with growing levels of assurance to final approval on release, ensuring no surprises near the end of the flow.
  10. Shift left, e.g. risk and impact assessment is done by the developers, who self certify. Or business approval happens when the Product Owner prioritises the work for the sprint, with no need to re-approve in a business CAB at the end of the week.
  11. Automate the control, e.g. change/release collision detection. Or security scanning.
  12. Remove the control. Show how the control is unnecessary or irrelevant to your work. Convince governors to have the control removed.
  13. Ignore the rules. Seek forgiveness not permission.

Any more? Thoughts?

Syndicate content