Skip to content
July 22, 2011 / David Bleeker

Agile in the Broader Context

This is the first in a series of posts that deal with Agile development in the broader context of the overall business.

Agile is driven by the backlog, and the backlog is driven by the Product Owner. Simple enough. But not enough to make Agile development successful in most organizations.

Most software development occurs within the context of a business initiative that is managed using a typical waterfall project management approach. Some of these projects are initiated within the context of contracts executed with customers. Some of these projects require lengthy marketing projects and public announcements. Depending on the situation these requirements can have a far reaching effect on the software development process overall.

Folks in the Project Management Office don’t like Agile development because it messes with their control points and makes things untidy. It is more difficult to measure Agile projects using waterfall stage/gate criteria. I will deal with this aspect in another post. Suffice to say that there are hurdles when attempting to manage Agile on the backlog alone.

When the backlog is managed as a simple funnel, things can go wrong. Here’s an example:

  • Business projects are funded on the basis of a business case (formal or otherwise) that defines scope, cost and timeline.
  • When software development is required, it is usually a component of the overall business project, subject to scope, cost and timeline constraints imposed by the business case.
  • The Product Owner typically manages multiple business projects, some of which require changes to the same systems (their product).
  • Project scope is broken down into stories that are implemented by the development team. These stories consist of small, incremental changes to the product.
  • Stories are added to the backlog. Thus all projects are funneled into the same backlog.
  • Stories are prioritized based on business need. Features that are lower in priority can be shifted out to accommodate pressing concerns.
  • Backlog prioritization may cause features to persist in the backlog indefinitely. The Product Owner could even cancel stories that no longer hold value.
  • The delivery of a specific project cannot be predicted because prioritization may affect the delivery of approved scope.

A key issue here is that Agile can make it difficult to measure value against the original scope, cost and timeline. Timelines may be extended indefinitely, scope may be adjusted, actual business value may vary. You may have noticed that a key planning element is missing from the steps above. While it is not a shortcoming of Agile, it is possible to implement Agile without proper release planning, or a limited release planning approach. Without this key step in place, the results can be quite unsatisfactory.

Here are a few suggestions to help make things easier:

  • Plan releases, and plan them around specific projects or stakeholders. Avoid the temptation to make the next release simply a collection of miscellaneous features from multiple areas. Planning around specific projects ensures that the team is focused on delivering a coherent set of changes at the same time. Quality is increased, as is consistency since related feature changes are made at the same time.
  • Break projects into smaller releases or phases. This provides the team a way to take care of multiple stakeholders without having everyone wait for the completion of a large project. It is like working on multiple projects at a time, except the projects are interleaved without creating churn.
  • Formulate the business case around the smaller releases. Each release provides incremental value. Track that value for each phase.
  • Track scope changes and adjust the original business case. Too often Agile teams forget that the stakeholders who approved the project may not be aware of decisions to move scope around. This is the role of the Product Owner, but the entire team should insist on this simple requirement.
  • Keep the release date commitments. The business relies on solid commitments from the development team.

I would love to hear your thoughts. Let me know if you have any other suggestions or comments about this topic.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: