IT governance and compliance is about providing transparency to senior management. If you refer to <a href="/%3Ca%20href%3D"http://www.itgi.org/">http://www.itgi.org/ " title="IT Governance Institute">IT Governance Institute</a>, you can find a great deal of information and pointers, including standards such as COBIT. Areas covered by governance include:
- Business continuity and disaster recovery
- Regulatory compliance
- Information governance and information security
- IT Service Management, including ITIL and Service Level Management
- Knowledge Management, including Intellectual Capital
- Project governance
- Risk management
Governance is actually about good management and is not applicable only to industry sectors with high regulatory compliance requirements. Configuration management supports most of these areas. Many people believe that Agile processes are not appropriate for situations with strong compliance requirements. We think this view is wrong! Indeed, by increasing the transparency of our development process through appropriate use of Agile methods, we can improve governance in all areas. That said, Agile methods are not going to address all of the issues listed above. Rather than repeat other material, we would like to reference some other articles and pull out some linkages and highlights.
Scott Ambler and Per Kroll have written an excellent series of articles, "Best practices for lean development governance":
A key point for us with regard to the difference for Lean or Agile developers is that traditional governance often focuses on command-and-control strategies. These strive to manage and direct development project teams in an explicitmanner. Though this is a valid and effective strategy in some situations, for many organizations this approach is akin to herding cats: you'll put a lot of work into the governance effort, but achieve very little in practice.
Lean governance focuses on collaborative strategies that strive to enable and motivate team members implicitly. For example, the traditional approach to coding guidelines would be to create them and then enforce their usage through formal inspections. The lean approach would be to write the guidelines collaboratively with your programmers, explain why it is important for everyone to adopt the guidelines, then provide tooling and support to make it as easy as possible for developers to follow those guidelines. This lean governance approach is akin to leading cats: if you’re holding a piece of raw fish, cats will follow you wherever you want to go.
In our article Lean-Agile Traceability: Strategies and Solutions we expanded on the trust and confidence mentioned above:
- Trustworthy transparency is more valuable than tiresome traceability
- Agile/lean methods do produce documentation where it is appropriate, but they don't produce it "by the yard" to sit on a shelf.
- Traceability should serve the purpose of transparency, visibility and status-accounting rather than being a goal itself.
Many organizations have found that making business intelligence tools available on people's desktops and allowing them to drill down into data is much more powerful than producing static reports. These reports are often circulated and then people have to wade through to find the information they need. Static tools lack flexibility and any changes must be developed, including all of the lead-time. SCM tools should make this information visible as simply and painlessly as possible. Issues that come up in this area include:
- Licensing costs for access the tool: Can you produce any form of read-only material that is cheaper than full access and also, perhaps, easier to use than the full tool?
- Security and access control: Agile methods lean toward more access rather than less access, yet the appropriate balance needs to be defined according to the needs of the organization.
- Cross tool/vendor integration: What information is stored where,