Agile development: key questions for IT leaders

How do you monitor the funding of an agile development?

All organizations in the public or private sectors are faced with the constant dilemma of a finite pot of money and seemingly infinite ways to spend it. It’s a balancing act of competing demands for capital to support tactical and strategic projects, and programs in an ever-changing landscape. So it comes as no surprise that fiscal oversight and cost control is a major concern of CIOs and business as agile goes mainstream.

Normally, the key concern is the allocation of capital to what is often perceived as an ill-defined set of requirements and scope. This can lead to organizations adopting waterfall practices for project initiation and funding sign-off, with the intention of delivering the remainder of the project using agile practices. This model may satisfy the funding committee, but often results in wasted effort and time developing a large requirement document that is not necessary.

A more practical approach is to define a high-level view of the project based on story epics (a major scenario that represents a set of users’ stories)  or minimal marketable features (MMF) sets; these then become the project “rails.” Funding is based on the understanding that the project will run on the agreed “rails” without major deviation. This still leaves room for change, but if we agreed to build a car and suddenly asked to add wings and a jet engine, we would clearly be off the rails and dealing with serious scope-creep – even beyond agile’s flexibility. The epic or MMF approach also has the benefit that it supports the stage gate funding model. Successful delivery of major sets of features forms part of the “go” or “no go” decision to release funds for the next batch of iterations.

This approach can be extended to self-funding or seed-funding projects. In the same way a venture capitalist (VC) may fund a company to get it off the ground, agile seed funding covers the initial iterations to an agreed point where we expect to see a return from the delivered features. At this point a percentage of the project’s realized benefits are siphoned off to fund the next phase. This is only really feasible where the benefits are tangible. This has a profound effect on how we fund IT projects. Instead of placing all the risk on one or two projects within the portfolio we can “seed” a mix of high- and low-risk projects and let them grow or wither based on their success. But self-funding and seed funding are not for the faint hearted; after all, they follow a VC model.

How do you manage and monitor the costs to the organization?

Ongoing cost control of an agile project normally means tracking story-development effort at the task level, just as you track tasks in a non-agile project. The major difference is that agile’s short cycles provide a more accurate picture of what is really going in the project and how the money is being spent. By capturing task effort associated with completed stories, we can start to correlate story points with cost. Burndown charts can be annotated with the loaded cost of completed user stories (remember a story is either done or not done, nothing in between). Having developed a correlation with story points and delivery cost we are better placed to forecast the cost of delivering the remaining backlog at any given time. Remember that story points are a relative measure of size, so you have to normalise story points when dealing with multiple teams.

More-formal tracking methods such as earned value management (EVM) have been adapted for agile. Agile EVM has the benefits of being able to measure actual earned value (EV) as opposed to estimated EV which is the case with EVM and waterfall projects.

There is an increasing number of agile-project tracking tools, such as VersionOne, Rally Software ThoughWorks Studio, Parasoft, Agile-Team, to name a few, and the list of traditional project management tools that now have agile support is growing.

Up to now we have focused on funding projects but we must also consider a delivery model for products. Product funding is open-ended; it’s a commitment to a solution, provided the solution has business value. Products still have the same fiscal oversight, and feature benefits vs. feature delivery cost have to be monitored just like projects.
Effective agile development depends on effectively monitoring changes in the business environment. What processes and methods should companies put in place to effectively monitor dynamic changes? How do you know if you are getting it right?

Agile development is a closed feedback-loop system, and the single most important part of that loop is business feedback. To formalize this we can use John Boyd’s Observe, Orient, Decide and Act Loop (OODAL) cycle, below:

Observations is the most critical stage for agile regarding sensing external and internal change. External influences include shifts in market trends, competitors’ new products or new government legislation, while internal influences include the drive to decrease operational cost, integration following mergers and acquisitions, etc.

Line of business (LoB) and process owners have responsibility for making sure they are aligned with corporate strategy. They also have the responsibility of communicating changes in strategy to product owners. Unfortunately, many product owners are not part of the wide management loop and fail to spot shifts in direction. The worst case is where the team is using a product proxy such an IT-based business analyst and LoB may not even have these individuals on their radar and hence strategy changes are not communicated.

Agile teams need to make sure their product owner is keyed in to the wider organization. Don’t assume just because the product owner has the pulse of their user community that they are in the business loop.

Finally, as agile development is a closed feedback system the very act of feature delivery changes the environment that spawned the initial requirements. User Experience (UX) engineering is a critical part observing the internal change.

How do you decide which projects are suited to agile development and which projects are not?

When selecting a project for agile I always ask the following:

1.    Is there a business driver to use agile – time to market, risk of change etc.
2.    Is there active senior sponsorship to use agile on the project?
3.    Will the business stay the course? The No. 1 fail mode for agile is business walking away.
4.    Is the organization culture a good fit for agile and, if not, can we change it?
5.    Will we have a strong and committed product owner?
6.    Do the teams have or can we train them on the agile principles and practices?

There is a saying in the aerospace industry: “We could make a toaster fly if we wanted to.” With agile, we have made the toaster fly. All those verticals and domains that said agile would not work for them have one by one adopted agile in some shape or form. Medical devices, defense, regulated environments, SAP, real-time systems (yes, there is an agile system engineering community) are all tough domains and all have successful examples of agile development. It’s not a question of whether agile suits some domains rather than others; it’s a question of how much you are willing to change to make the toaster fly!

However, we need to take some caution. Agile is not a silver bullet to all development problems. It is one tool in the tool box. We need to use agile where we are playing to its strengths, such as in projects or products that have a mid to high degree of requirement uncertainty like research and development, innovation, developing new revenue streams. and areas where time to market is critical.

Yet, speed and flexibility are not the only reasons to use agile. Many government agencies are adopting agile after disastrous experiences with big bang delivery. For them, the drivers are greater user involvement, a more-interactive supplier process and minimized surprises (the “How much?!” effect).

Areas where change is not an issue, the domain is well understood and time to market is not a driver can realistically still use waterfall. Waterfall will be with us for a very long time, and when used correctly it works. We must also not forget that traditional iterative methods fill the gap between waterfall and agile and suite projects that require more guidance or do not need to “make the toaster fly.”

David Norton is a research director at Gartner.