Recently I challenged the Oil & Gas industry to disrupt their traditional waterfall methodology and embrace an agile approach to delivering projects. The wins appear so obvious. Given the demand for projects to provide quick returns on investment they need to be implemented rapidly, delivering exactly what the business needs. So if it’s that simple, why isn’t everyone ripping up plans, putting up more whiteboards and getting the post-it notes out?
If I look back and reflect on the many conversations I’ve had with Project Managers, technical architects etc. there is a common denominator and that is fear. This fear is often attributable to many ‘myths’ around Agile.
What’s causing you to fear Agile?
1. No documentation is produced – this is the number one statement I hear all of the time. Agile isn’t anti-documentation; it gets prioritised along with the other deliverables and it’s not done just for the sake of it. I think more fundamentally, Agile forces face-to-face communication rather than falling back on a number of weighty documents to do the talking!
2. There aren’t any plans – I see more planning and interactions on agile projects. The plans are not static as we have accepted that things change and the plans change to reflect that. Remember this is about being nimble to drive down delivery costs and drive up the value of what is delivered to the business.
3. There is no discipline and rules are flouted – certainly not true. You have to test, get feedback, be prepared to deliver smaller packages of functionality more frequently, change and update the plan throughout and if there is any bad news to report it’s got to be done early.
4. It requires a lot of throwaway rework – this one is interesting and I think there are two forms of rework. Firstly, the requirements may change as the customer understands what they really, really want. Secondly, there’s the rework of the solution if the developers find a better way to design it. Things cannot keep changing indefinitely or the solution never gets delivered, so there’s a balance to be struck. The key is to ensure that everyone is empowered to iterate so long as it’s within the projects means – namely quality, time and budget.
5. It ignores architecture – not true. A central tenet is to keep the solution simple and not over engineer: only add the complexity (and the bells and whistles) when you need it. Empower the team to challenge.
6. Agile can’t be used in very large projects – I don’t think any methodology truly scales very well. It’s very difficult to manage large groups of people and ensure they are all moving in the same direction towards the same goal. I guess this is where I constantly fight my inner battle about how best to deliver large programmes. I think we should look to see how we scale down the larger programmes into more easily deliverable chunks.
So where’s the catch?
I’m sure many of the myths I’ve talked about have been repeated by others before me and that there are many more out there. Indeed, I’ve heard some bold statements that Agile is a silver bullet for projects and I actually have to disagree with that.
Any project can fail whether or not it’s delivered using an Agile, Waterfall or another methodology. What an Agile approach provides you with is a much earlier indication that your project is going to fail as you have transparency and visibility throughout the project. Being accountable for large projects, I see this as a huge benefit. I want to know if anything is going to go wrong as soon as possible and not at the point in time I can’t intervene. Once we’ve reached the point of no return then we really do have issues with time, quality and budget.
Transformation is necessary
If I were to stick in my comfort zone I would say let’s keep it simple and keep the status quo. However, my instinct is shouting ‘no’ and my experience of working with Oil and Gas customers recently only serves to make this feeling even stronger. How can I honestly advise my customers to continue ‘as is’ and deliver IT solutions that may not realise the benefits first envisioned, and, at worst, deliver a product that isn’t fit for purpose and won’t be used. That is failure and all for the sake of feeling comfortable and safe.
It’s time to disrupt the traditional mind-set and transform the way in which we deliver projects. Challenge yourself to dispel the myths and transform... can you really afford not to?