Agile: Why it's not an all-or-nothing proposition

Agile: Some of us love it, some of us hate it, and some of us are just not sure.

Whichever camp you’re in, it’s worth thinking beyond how and where you might use it. Could certain elements of agile – rather than wholesale adoption – be useful in how you deliver your projects?

In Agile project management: When it doesn’t fit, I discussed how agile can be used as part of your overall delivery toolset alongside other traditional techniques.

For example, the daily stand-up meeting is commonly seen as an element of agile project management, but it can also be a good way to keep your project team focused in an intense period of delivery within a more traditional project delivery approach.

[ Want a contrarian take? Read also: Beware the dark side of agile project management. ]

Similarly, there is no reason you can’t adopt an agile approach for one aspect of a project while using a waterfall structure for the project as a whole. This might be for a specific deliverable within a project or for different phases – for example, applying a traditional waterfall approach to your planning stage (where more structure and definition is deemed key) and then using agile during the development cycle to help drive more rapid deployment of outputs or increased customer collaboration.

Assess each project for agile fit

Using agile, or elements of agile, doesn’t make sense for every project; each one needs to be assessed individually. Factors such as the organizational culture and environment play a big part in determining the right approach to take. Large organizations with rigid processes and policies are less likely to embrace agile, but that doesn’t mean it’s completely out of bounds and you shouldn’t consider adopting certain agile techniques that may be appropriate for your project.

The key is to be clear about what agile is and what it isn’t. In our industry, there is a common misperception that agile means you don’t need to document requirements, therefore saving time and avoiding difficult conversations with users and stakeholders.

[ Want an agile project management primer? Read Agile project management, explained and Agile project management: 10 reasons to use it. ]

In fact, it’s simply a different approach to get to the same point, albeit on an iterative cycle of engage/build/document/release. This increases the pace at which stakeholders start to see an output, but it doesn’t mean that the requirement isn’t documented in some form. It simply happens after a period of collaboration and exploration.

Consider the merits of a hybrid approach

A hybrid approach can often be an effective way of working through challenging situations in which your user or customer is not certain of the finer detail of the end product they need, but they know they need something to meet a certain set of objectives by a certain point in time.

Here, you can effectively couple an agile methodology with a wider traditional product construct which allows for iteration and exploration to get to the product required while still holding firm to a specific delivery date.

We often see frustration at organizations where senior leaders believe that agile has created a seemingly never-ending cycle of iteration but failed to get to the broader results desired. Combining elements of certainty while allowing for cycles of iteration is a good balance of tradition and modern, as it provides increased levels of collaboration while meeting an agreed date for delivery.

You don't have to follow agile to the letter

My advice? Resist becoming a pedant and getting swept along in the wave of “agilistas” who force the adoption of every word in the agile manual. Such a theoretical and academic approach has long been a bugbear of mine – not just for agile but for best practices.

Years ago, I presented at a conference on the topic of ITIL service management titled “The right pages in the book, not all the pages.” I feel that this applies equally to agile project management.

When it comes to agile, keep these five key points in mind:

1. Agile is a set of ingredients, not a complete recipe
2. Using agile doesn’t mean wholesale adoption and training your entire organization in support of this
3. Using agile doesn’t mean you can’t use waterfall or other methods
4. Consider (as discussed in my previous article) whether the adoption of agile is right for your project or organization before jumping in
5. Don’t treat agile as a religion

Without a doubt, agile can help deliver results quickly. That is why the above step 5 makes use of agile techniques, but only when they make sense for a specific project – not at the expense of everything else. The key is to choose the approach and the tools that are right for each environment and set of circumstances. After all, one size does not fit all.

[ Culture change is the hardest part of transformation. Get the eBook: Teaching an elephant to dance. ]