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.
At this point, I am reminded of the old joke: Do you want to make God laugh? Just tell Him your plans. Businesses need to plan their activities to ensure that resources are accounted for and are working to further business goals. Engineering teams need to work on requirements that don’t change, so that the work is focused and efficient. The question then becomes, how to reconcile the governance requirements that business stakeholders have with the just-in-time requirements management approach of agile? There are three practical things that organizations can do to ensure that agile benefits not only engineering, but the business as a whole:
1. Agree on high-level requirements. This is more than just ’software or salsa’. It means that someone in the organization (a product manager at an ISV, for example) must take ownership for extracting and documenting requirements at the highest level. The great myth around agile is that there is no documentation - not true. There is no extraneous documentation. Everyone needs to agree that the organization needs to build an X that meets these A,B,C customer requirements. Agile purists who resist the creation of this document should be taken to task, as should product managers and other business stakeholders who want to meddle in engineering implementation details.
2. Plan for change at the business level. Given high-level requirements, the temptation for business stakeholders is to say “I’m done with my part”. That’s not agile, nor is it realistic. If your engineering organization is working with 30 day sprints, it’s the job of the business representatives to actively evaluate not only the requirements in the backlog, but also the output of each sprint, so that the next 30 day sprint is planned in accordance with any new information about the business requirements of the project.
3. Make governance a part of the agile process. This is the hardest part for engineering organizations to swallow. But the engineering or IT budget isn’t a gift from Santa - it is a hard number that your VP of Engineering or CIO owns and is accountable for. So it makes sense to add a step in the process at sprint review time (the post-evaluation that occurs at the end of each sprint) to formally document the project progress in a form that is useful for the rest of the business. Included in this report should be at a minimum what features were completed, what the cost of these features are, what the rollout plan is for these features, and what percent of the known requirements have been satisfied to date. In this way, the internals of the agile method are only minimally exposed to business stakeholders, who may not know nor care what a sprint is, but the results as they affect the business as a whole are transparent.
I’m sure that readers could come up with a few more practices, or critique my brief set. That’s great - what is needed on this topic is cooperation and frank discussion, so that businesses can move forward with more efficient engineering organizations, and with improved ways of communicating engineering activities to a broader business audience. Ultimately, both agile and governance are about making sure the business is working on activities that add value to customers. So it is in the interest of both agile practitioners in engineering, and business stakeholders across the organization to work together to blend agile and governance in a practical way that maintains the efficiencies of agile, and also advances and meets the overall needs of the business.
Posts
