Don't Let Governance Threaten Your Agile Transformation

Governance seems to be one of those frightening words that threaten to stop an Agile transformation effort dead in its tracks. I’ve been hearing it whispered, and even screamed once or twice, quite a lot recently. There’s no big surprise here. As big corporations and Government agencies get increasingly fascinated by frameworks like Scrum, they are mandating their IT departments to “go agile” and then, sooner or later…governance sets in!

Types of Governance

There is operational governance represented in defined processes that organisations and teams are expected to follow when software is in production. There is project management governance, perhaps dictated by PRINCE2 or similar, while the product is in development. PRINCE, by the way, is an acronym standing for ‘PRojects In a Controlled Environment’.

Project management governance is often a subset of wider IT governance. According to the TOGAF version 9.1, IT governance supposedly provides the framework and structure that links IT resources and information to enterprise goals and strategies. “IT governance institutionalises best practices for planning, acquiring, implementing and monitoring IT performance…” Standards like COBIT, which stands for Control OBjectives for Information and related Technology, might also be in place.  

And then, of course, there is a range of issues to do with compliance to the requirements of external regulators in relevant public bodies, as well as commercial institutions in sectors such as insurance and banking. So, is this a case of an irresistible force (Agile) meeting an unmovable object (governance)?

What is Governance?

Let’s go back to first principles: What is governance?

Here’s a definition I came across recently in TOGAF 9.1:

“The discipline of monitoring, managing and steering a business to deliver the business outcomes required.”

As an Agilist, I have no problem with governance described in this way. An obstinate focus on the delivery of business outcomes is the very stuff of Agile. It is the way governance is applied that is the problem. Typically, specialist governance bodies are set up in a hierarchy at each level of which procedures are mandated, documents are required for signoff, and auditing procedures abound. The Agile principle of trusting professionals to get the job done is about as welcome as a trap door in a canoe. Fear of non-compliance drives very different behaviours from those we are trying to grow with Agile.

When these kinds of bodies and procedures get imposed on software development teams, there is one guaranteed result: delays in the delivery of value to the customer (often protracted delays at that). Phase-gates block the development path. Waiting for signoffs builds queues of work items. Sometimes the whole development ‘track’ is idle, like a train sitting at a signal waiting for it to turn green.

Software Development is Designful

The scenarios I have just described are in no way conducive to the achievement of business outcomes. In fact, very often, it is the governance procedures which are the major obstacle to their delivery? Why is this?

Business value is much more likely to be delivered using the agile model because of its fast feedback cycles. These are necessary because software development is inherently unpredictable. Its practical processes are more like what goes on in the design rooms of product development than it is like the assembly lines of mass manufacture.

"Design is not passive. It is wise for designers to harmonise with the ways of nature but the ways of nature follow context and change." - J.O. Coplien and L.Zhao

Mass manufacture is predictable. The uncertainties have been ironed out and removed in the design “phase” but software development is not.

While not everything in software development is design (problem analysis should shape design, after all), its 'implementation' is creative. Even when we are crafting code, we are only designing the instructions that the computer will run. Design is dominated by uncertainty. New information emerges during the process itself and is incorporated as quickly as possible. Feedback cycles surface that information, allowing the development team to converge on a solution that delivers business value to the customer.

A New Model of Governance?

Traditional governance procedures follow the motto, “Plan the work; work the plan”. They assume predictability. There are many corporate procedures where governance for predictability is appropriate. Software development is not one of them. Governance for feedback; governance for responsiveness is what is required. In many agile-adopting organisations, a “two-speed” solution is evident. Where predictability reigns, traditional governance procedures are maintained. Where feedback drives success, different approaches operate.

In Scrum, the Product Owner is responsible for achieving the business outcomes inherent in the product development. She owns the product for the business, and is accountable for, amongst other things, its alignment with the strategic goals of the business. She is also a peer member of the Scrum team. One of the reasons you rarely see formal, outlined business cases, followed by detailed business cases and post-project audits against them in Scrum is because it is unnecessary. The Product Owner role and the Sprints’ inspect-and-adapt cycle takes care of that stuff in a more ‘light touch’ way.

Loading...

Similarly, the quality of the product is best ensured by embedding testers as developers in the Scrum team. The goal of testing then itself becomes feedback. The ‘Whack-The-Mole’ pattern means defects can be removed by the Development team before the increment gets to the Sprint Review, let alone Release. The ping-pong between programmers and testers that so characterises (and delays) waterfall development is eliminated by making the Scrum team responsible for quality.

While any overall solution to the governance issue will be situational, and may yet require some external oversight, the general line of approach seems obvious to me. Business stewardship and quality assurance are, in my opinion, stronger in Scrum than they are in waterfall precisely because the specialist skills needed have been brought into the Scrum team, and the team is accountable for them. The Scrum Development team is supposedly fully cross-functional: it should contain all the skills necessary to deliver the product. If that requires specialists in governance, then include them in the team.

Let the team figure out, through conversation and collaboration with whoever it needs – external regulators included – the best way to ensure the proper delivery of business outcomes.

J.O. Coplien and L.Zhao, Towards a General Formal Foundation of Design: Symmetry and Broken Symmetry. Monograph

Author Bio:

Alan O'Callaghan has been using Scrum since 1998 when, as an active member of the patterns community and with a special interest in organizational patterns, he saw Scrum presented as a pattern language at the 1998 OOPSLA convention. A Certified Scrum Product Owner (CSPO) and Certified Scrum Professional (CSP) with Scrum Alliance, he is also a Professional Scrum Master (PSM) with scrum.org, a PMI Certified Agile Practitioner (PMI-ACP) and a SAFe (Scaled Agile Framework) Program Consultant. As Principal Product Owner of Emerald Hill Limited, Alan consults and/or acts as Scrum Coach for major corporations, government departments and NGOs world-wide, as well as for start-ups and small and medium-sized enterprises. He has worked with Learning Tree International as an instructor and course author for eighteen years, and was, until recently, Curriculum Architect for Learning Tree’s Software Engineering and Agile courses.