IT Governance in the Agile Age, Part 1

‍Case 1: A fast-growing e-commerce organization decides to use only PHP in all of their applications and services. Not everyone is a fan of PHP, and it's not the best tool for every use case. But the organization chose cross-team alignment over individual freedom of choice, mainly to gain flexibility in resource allocation: by making all teams use the same tools, developers can switch teams with minimal friction.

Case 2: A small security team is given the task to make the whole product organization meet challenging security standards. They write policies, but it's an uphill fight for them to convince developers and operations teams to implement the strict processes required: those teams are not measured by their security posture, and there would be massive implications on cost and development pace when when following the policies to the letter.

What do the cases have in common? They are about governance, about balancing the needs of the governing bodies (such as IT management) with the needs of those who are governed (such as software developers).

Over the past decade, management theory on how to organize a successful enterprise has been turned on its head. In rapidly changing markets, quick decision-making in small autonomous units trumps centralized control, and the classic functional organization of an enterprise has fallen out of fashion - separating corporate functions was a prerequsite for increasing efficiency, but the ability to react and innovate is a greater concern than efficiency as digital transformation takes hold in more and more industries.

An organization that consists of loosely coupled product teams can recognize opportunities faster. Teams can be moved closer to their customers (thus getting quick market feedback), and can be restructured and reassembled more quickly when market needs change. That organizational structure comes at the cost of duplicating functions across teams, and giving up some degree of central control. In essence, it's a trade-off between cross-team alignment and flexibility.

How does that change the decision-making process and the role of management? Agile calls for "servant leadership", with semi-autonomous teams and self-motivated individuals making most decisions, and management's role reduced to providing resources and support. To a certain degree, centralized control is replaced by trust in the bottom-up decision making process: the ones making decisions need to make the right decisions, taking into account their own best interests and the company's interests. Companies end up as loosely coupled federations of autonomous actors.

That view of the decision-making process clashes with regulatory demands, though. Legal and regulatory compliance demands that strong management controls exist within companies, ensuring (not only hoping) that the right decisions will be made consistently - decisions that are in the company's interests, but also compliant with applicable laws, regulations, and ethical standards. Invariably, upper management is held accountable for establishing the boundaries and constraints for those making front-line decisions. Rule books, codes of conduct, processes and internal audits are the traditional methods for making sure that rules are being followed. Unsurprisingly, using that approach in a agile organizations, specifically IT organizations, isn't particularly effective; in any case, it creates negative sentiment.

"Alignment" and "governance" is called for in many areas of IT management, such as:

• Strategy/resource alignment - ensuring that resources are allocated according to corporate strategy
• Regulatory and legal compliance - meeting regulatory requirements and abiding by (regional) laws
• Contractual compliance - making sure that existing contracts (such as customer contracts, and software license agreements, including open-source licenses) are followed
• IT security - managing IT security risks and building security into the software delivery process
• Data governance and data protection - implementing governance frameworks to meet legal standards such as GDPR
• Business continuity - making sure critical services can be delivered even under adverse circumstances
• Project/program governance - reducing project risks by establishing and following standards on how to manage them, including agile project management
• IT service management - reducing friction in managing IT services, by following established standards such as ITIL
• SDLC governance - establishing standard processes on how software is designed, created, delivered and operated
• Architecture governance - influencing IT performance and cost by aligning applications and services, their dependencies, as well as the tools and patterns used in their development
• Product innovation management - establishing a standard lifecycle for innovative products that allows rapid experimentation, but also makes requirements for those products to meet on the way to maturity
• Risk management - creating transparency on risks from all of those areas, and prioritizing activities to address them when downsides outweight upsides.

The challenge in an agile enterprise is to establish an IT governance model that meets regulatory demands, but takes a supportive stance in helping (semi-) autonomous units achieve their goals without stifling innovation - a strong support system instead of a regulatory straightjacket. The benefit of an agile governance system is to make decisions easier for everyone, in addition to reducing regulatory and business risk. Studies have found that individuals can decide faster and are happier with their decisions when there are fewer options. Constraining the freedom of choice in critical areas can therefore be a win-win situation for the individual as well as the collective.

There are various aspects of agile governance that I will explore in future articles in this series, such as:

• Stage-gate models: Innovation, governance and product lifecycle
• Incumbents and start-ups: Certification as a competitive moat
• What differentiates bureaucracies from support centers
• Individuals and collectives - making and enforcing rules
• Governance in scaled agile frameworks
• Measurements and feedback loops

‍