Enabling Agility

Agile is particularly good for managing projects where you have significant uncertainty about what you want to build and how you plan to build it.  It can help you cut time-to-market and costs while increasing customer satisfaction.

Here’s an example.  Imagine you want to enter the market with an analytics product that provides your customers with insight into patterns and trends within their employee population. You have various sources of data available (payroll, performance management, organization structure, industry pay ranges, state and region demographics) and a general idea of the things your potential customers might be interested in learning. This is a perfect project for Agile.

Why?

Agile is an iterative process. You build a little, you show results, and you use that feedback to guide what you build next.  Your potential customers probably have some general ideas of what they would like to see, but won’t really know until they get their hands on a system they can play with.  It would be pointless to try to get all of the requirements right up-front, because your potential customers won’t be fully able to articulate what “right” is until they see something. Much of the time you’d spend putting together a comprehensive requirements document would be wasted, since the requirements will change significantly as the project progresses.

Similarly, trying to fully understand the architecture and data requirements up front is also going to be difficult.  You certainly will have some idea of what data you’ll want and how you’ll want to structure it, but you will probably have to evolve this architecture as the business requirements evolve.

You would be less likely to choose Agile for a project where you were performing a set of tasks very similar to one you have done in the past. For example, if you have call centers in five locations, and you are adding a sixth, it probably makes sense to update the project plan you’ve used for the other call center build-outs. You have a really good idea of the requirements up front and how to execute against those requirements. Limited iteration is needed.

If you have a project where you have significant uncertainty about what you are building and how you are building it, Agile is likely the right way to go.  Using a waterfall approach on these types of projects will typically lead to excessive effort defining up-front requirements, significant rework, decreased customer satisfaction,  higher costs, longer time to market, and decreased sales (if it doesn’t do what the customers need, they won’t buy it).

I want to thank Ken Schwaber for providing me with the core idea for this post in his ScrumMaster course.