Transparency improves Governance

IT governance and compliance is about providing transparency to senior management. If you go to the <a href="/%3Ca%20href%3D"http://www.itgi.org/">http://www.itgi.org/ " title="IT Governance Institute">IT Governance Institute</a> you can get lots of information and pointers, including to standards such as COBIT. Areas covered by governance include:</p>

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 really about good management - it is not just applicable to industry sectors with high regulatory compliance requirements. Configuration management supports most of these areas.

There are more than a few people who think 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 an excellent series of articles, "Best practices for lean development governance"

• Part 1: Principles and organization

• Part II: Processes and measures
• Part III: Roles and policies

A key point for us with regards to the difference for Lean or Agile developers is:

Traditional governance often focuses on command-and-control strategies which strive to manage and direct development project teams in an explicit manner. Although 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, and 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 grab a piece of raw fish, cats will follow you wherever you want to go.

In our article Lean-Agile Traceability: Strategies and Solutions we addressed 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 in itself.

Many organizations have found that making business intelligence tools available on people's desktops, allowing them to drill down into data, is much more powerful than producing static reports which are then circulated and that people have to wade through to find the information they need. Static tools lack flexibility and any changes must be developed - with all the lead time that implies. So we need to enable our SCM tools to 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 which is cheaper than full access (and also perhaps easier to use than the full tool)?

• Security and access control - agile methods lean towards more access rather than less access, and