The McKinsey Quarterly
Agile software development continues its forward march. Technical practices like Test Driven Development and Continuous Integration introduced by Extreme Programming at the start of the decade are now common place. The short sprints and product backlogs of Scrum are changing the way development work is project managed. Yet to fully realise the benefits of Agile companies need to change how they go about project governance.
Governance – and the related issue of requirements – is the next challenge for Agile development. At the moment many so called Agile projects are still governed under the traditional model. As a result they do not fully realise the value of Agile development.
The traditional model
Traditionally projects start with the definition of a set of requirements and a defined set of expected benefits. Based on this information a budget can be set and resources allocated. The governance process is thereafter largely concerned with ensuring the requirements are met within a given timeframe and within the agreed budget.
Assuming all goes to plan the benefits are delivered at the end of the project – although it might be months before the benefits can be measured and a final assessment made of value added (or destroyed). Consequently while projects are in flight they are governed by monitoring proxies such as time elapsed, features competed or budget spent.
While many Agile projects have been governed by this model it imposed limitations on the projects. Maximising value – and chances of success – from an Agile project means letting the requirements evolve in tandem with the software. As the software is created needs are identified and added to the potential work.
As a result it is difficult to use the traditional governance model. The requirements and features under development are unknown – and potentially expanding. The end point is open ended and it is hard to know what resources to allocate to the work.
Fortunately while the traditional proxies are not available Agile projects do allow benefit and value to be measured directly as the work proceeds. Thus there should be no need to use proxies such as progress on a chart or percentage complete.
On one hand delivering benefits as the work proceeds represents an opportunity for better governance yet on the other hand it creates a problem. If work begins with only vaguely defined requirements how does one know when it is “done” ?
If a team are delivering value to the business with new software every few weeks, when is the right time to stop the work? Stopping it too soon will miss opportunities and reduce value; letting it run too long imposes unnecessary costs.
Borrowing another governance model
As with much else in the Agile toolkit, the answer lies in borrowing a practice from software product companies. In this case it is the venture capital model used to fund software start-ups that provides a solution.
Venture Capitalists (VC) are skilled at evaluating business plans and allocating money in increments to the companies. In the first instance seed funding may be quite small and come from a business angle. The money is used to develop a basic product to demonstrate the business plan objectives.
The business plan itself is not a requirements document. It identifies the opportunity, sizes the potential, outlines a strategy and describes a success story. As with battle plans few business plans survive contact with the enemy, or in this case the market.
As the software is developed – and trialled – the business plan is honed. When the money runs out the company must appeal to venture capitalists for more funds. They will only be granted these funds if they can show progress.
This cycle repeats, the more successful the company is at generating cash itself from the product the less need it has to persuade outside investors of future value.
For their part VCs have a pot of capital to invest in a portfolio of companies. This is capital the investors are prepared to risk in return for the opportunity to profit. VCs expect to show a return from the portfolio as a whole knowing most companies will be failures and a few outstanding successes.
In the corporate world
The same model can work inside the corporation. The process starts with the identification of a potential opportunity. It could be an opportunity to save money through automation, to change business process, or to introduce a new IT based service offering. The key is the identification of the opportunity and the sizing of the potential return.
At first only a small amount of money is allocated to allow investigation of the opportunity and initial technology development. These activities happen in parallel and feed off each other. This accelerates the work and increases the flexibility in deciding how to address the opportunity.
When companies spend months creating detailed requirements less time is left for technology development. The same requirements come to restrict the options available to the team. When such requirements run to hundred of pages they are difficult to use. In the best cases detailed such analysis serves as background information, in the worst cases they are a hindrance which restrict options.
It is far better to set a combined team an overall goal and let the team decide how to meet the goal. The team needs to include business and technology team who are multi-skilled and will stay with the project for most of its life. The team develop both the business idea and technology in parallel.
When the money runs out the team return to the governance committee. If they can demonstrate progress in technology and business opportunity they are awarded more money. With more funding the team can continue and possibly expand. The cycle repeats in an iteratively along the lines of most Agile development teams. Thus the governance model is aligned with the Agile approach.
Under this model a corporation has a number of ongoing development activities. Each will have an evolving business case, a collection of candidates features and a track record of value delivered. This makes it possible to look across the development activities and determine which should continue and which should be stopped.
These decisions need to be made in the context of the whole portfolio and within the agreed portfolio budget. Developments are not just judged on their own progress but in comparison with the other activities in the portfolio.
It is entirely possible that each activity can demonstrate a track record of deliverables that added value, each has a rosy business case for future development and a positive ROI. But that does not mean all activities should continue. It may be a better use of resources to stop one project and divert the resources either to a new activity or to support other activities.
This is how Agile projects reach the end. Not by completing some percentage of predetermined features but when, in the context of other work, the project does not represent the best use of resources.
Of course, with the projects being Agile it is possible to stop them very quickly. There is no need for a lengthy test-fix-retest cycle, or laborious end of project documentation exercise. Agile projects will have undertaken these tasks as they go. Ideally it is only necessary for the project to finish the current iteration.
The reverse should also be true. Agile projects that have been stopped can be relatively easy to restart should the business environment change. Again this is because Agile teams are producing the necessary documentation, tests and keeping the design sound all through the project.
Corporations which adopt a iterative governance model which looks at the portfolio of development projects will be better placed to leverage the true power of Agile development. Those which continue to govern Agile work using static, largely waterfall, models will still see benefits from Agile: more productive teams, higher quality and lower costs. But they will miss out potentially transformational change.
While this model may be radical within corporations it is hardly new. The venture capital approach may appear risky to corporations but it should be no more risky than using a static model that does not match the way projects are now managed.
About the author: Allan Kelly helps companies navigate the adoption of Agile methods and assists the creation of a learning and improvement culture. He is the author of Changing Software Development: Learning to Become Agile as well as numerous articles and conference presentations.