Agile. It’s a great word, isn’t it! I mean who doesn’t want to be agile? To be nimble, flexible, fast … what great skills. Now transfer this to a project. Imagine a sleek puma project, racing through the organisation. Wow! Now, what does waterfall conjure up? Hmm, no wonder the puma looks so attractive.
We can easily be swept along in the hype. “This project is going to be done using agile. I’m going to do agile”. Problem is you can’t “do” agile, you need to “be” agile.
I hear people wanting to ‘do an agile’ project, but when I question them further, I cringe because what they really mean is, “we want this project to move quickly”, or “we would like to see some quick wins”. Substituting ‘agile’ for ‘rapid’ is a common mistake.
Breaking projects into streams, or smaller chunks or limiting the functionality are appropriate ways of moving more quickly or getting early buy-in, but it has nothing to do with being agile.
Being agile isn’t always easy or necessary, it is as much a mindset as a methodology. I like the way Gartner’s Janelle Hill uses the phases “doing by design” or “design by doing”. The former is suitable if you are clear on your end goal and have definitive ideas. In these situations, a waterfall project that is built to a specific design can be quick and effective. However, if the end goal is murky or difficult to define, then a project that is built through a series of iterations or prototypes may yield better results. This approach, which uses a ‘design by doing’, is more suitable to an agile methodology.
Many variables affect the speed of a project. Methodology is just one factor. Moreover, if the wrong methodology is chosen for the project, it will actually reduce the speed and can jeopardise the project outcomes. Imagine a sweeping statement such as “a diving aqualung can help you get to your destination quicker”. If a race was held on the basis of swimming from the beach to an ocean floor wreck and back again then we would agree. But if the race organisers changed the objective and said, “run from the beach to the hilltop and back again”, anyone wearing the aqualung would be severely hampered.
In using an agile methodology, a project team should consider the objectives, the people involved and the product. All three variables have a big impact on the methodology fit. Budget and timeline are outcomes of this mix, not the inputs. Commencing a project, with statements like, “we want a quick project, so we’ll doing this using agile”, or “we have a limited budget, so an agile approach will help us” are a sure sign the project is destined to fail.
One last note, whilst there are no hard and fast rules, I do want to make the case that certain products naturally lend themselves to be more suited to either agile or waterfall:
- ERP products would be a case where waterfall is generally more suitable. Typically, there are defined outcomes and a clear objective.
- SharePoint, BI, BPM products would generally favour agile. It is often difficult to articulate a final design and can be easier to demonstrate detail than write plans.
- CRM is a product on the cusp. The specific CRM module and audience are likely to be better indicators of methodology than the product itself.
So if you are implementing an ERP application and someone says “let’s do this using agile”, my advice would be to sit back and say “Why?” There may be good reasons why agile has been chosen, and ERP products can be implemented successfully using agile. However, unless there is a sound basis for choosing a particular methodology, the project is always going to be on unstable ground.
Blog written by Chris Pennington, Consultant to Professional Advantage. The opinions expressed here are the personal opinions of the writer. Content published here does not necessarily represent the views and opinions of Professional Advantage Pty Ltd.
You can read more about how Professional Advantage supports CIOs and IT managers here.