When I first sat down to write about agile governance, my mixed metaphor and oxymoron meter started redlining. As I researched to see how prominent this topic has been, I encountered phrases like “tail wagging dog” and “are you kidding me?” It seems that the Agile advocates and the governance advocates don’t see eye to eye, if they even talk to each other at all. While several authors have addressed this topic (notably Dr. Peter Merrick in a recent article in Information Age), most of the coverage is theoretical. My goal in this post is to outline some practical approaches to ensure that the requirements of large-project governance can be met by engineering teams that employ Agile software development methodologies.
Let’s start with some working definitions. I define governance as accountability and risk management of IT projects and resources as perceived by non-engineering personnel. Agile can be defined as the set of engineering methodologies that rely on incremental development cycles, flexible long-term planning, and rigid short term-planning. Though many will comment on these definitions, they will serve for our purposes here.
Looking first at governance, it should not surprise anyone that the CFO or CEO of a Fortune 500 company might be interested in exactly how their $100M annual IT budget is being spent and how this spending benefits the company. That’s their job as representatives of the business interests of the organization. Similarly, the business stakeholders at an independent software vendor, such as account representatives and product managers, need visibility into the activities in engineering in order to communicate to customers, investors and other external stakeholders. Put another way, governance of engineering assets is a requirement for business – without it, the engineering or IT organization is operating in an opaque fashion without accountability.
On the agile side, it should also not be a surprise that after decades of being blamed for late projects, over budget software releases, and failure to meet customer requirements, engineering organizations are fast embracing agile as a way to manage software development projects. Starting with the axiom that requirements are rarely fully specified, agile provides a scheduling and requirements management framework that enables teams to work successfully on under-specified requirements today, and adjust their plans as requirements change tomorrow, next week, or next month. Put another way, agile solves the requirements management problem that every business has – without this solution, the engineering or IT organization may be transparent (“See, here’s our project plan”), but is likely not satisfying business requirements.
