Agile is for Life, Not Just for Christmas

In a recent article on TechRepublic, Ilya Bogorad reminded me how the mere possession of an IT buzzword does not make for good practice. In this instance, the topic of discussion was ITIL, the increasingly popular IT Service Management approach, or a "framework of common sense" for IT service providers, as some analysts point out.

The same cautionary tale is true for Agile, which as a buzzword is currently on the ascendancy, but as a practice has been around for as long as anyone capable of remembering can recall, albeit in different guises: RAD/JAD, Scrum, and DSDM set the scene for what is now roundly known as Agile close to 20 years ago. So why the current hype?

Traditionally, hype is fuelled by a promise of something new or better than before. That's true for Agile methodologies - done correctly, they can deliver successful software projects faster, cheaper, and to a greater degree of quality than traditional lifecycles.

The hype exists because Agile is becoming a brand, and all a brand has is a promise. Without substance, a promise leads to a rush of inflated expectations, until we fall into the trough of disillusion as characterised in the infamous Gartner Hype cycle.

So can we expect the same pattern for Agile? It all depends on what we use it for: what is the product behind the brand?

In Marketing speak, the "product" is the "proof of delivery on the promise" of the brand. Some of the products that deliver faster, cheaper and better software projects under the Agile brand are:

  1. Better estimation techniques from scoring features according to complexity
  2. Higher transparency from involving the customer in the projects from day one
  3. Greater flexibility to change, through focusing on working software in iterative development cycles
  4. A stronger emphasis on face to face interaction, rather than silos of individual effort and heavyweight documentation.

Here's some examples of the Agile product you might not have thought of:

  • try using a Planning Game for estimating complexity of an entire project, not just the software development effort: "We can build the new software in a week, but there's a 60 day lead time on the network circuits."
  • try having customer representatives attend daily stand-ups for prioritising outstanding Service Requests in an ITIL framework: they'll tell you what's important and urgent, and feedback your efforts to the user community really quickly.
  • try a "mash-up" of Agile and Prince2 to give you grass roots control and report up to overall project governance: Run the Project Board through your card wall, and invite the Stakeholders to your daily stand-ups (don't forget to tell them they are just chickens!).
  • try using face to face communication as much as possible: ban internal e-mail one day a week and see if your productivity increases.

Used this way - and these are all real world examples - Agile itself just becomes a framework for common sense. The brand may end up being used and abused as an increasing number of companies create then jump onto an Agile bandwagon , but the fundamental tools and techniques will remain.

This site uses cookies. Continue to use the site as normal if you are happy with this, or read more about cookies and how to manage them.