Fearful of Agile? Dispel the myths and transform!

22 March 2016

Samantha Hollingsworth

Samantha Hollingsworth

Principal Programme Consultant

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?

About the author

Samantha Hollingsworth

Principal Programme Consultant

Sam is a highly experienced and trusted IT management professional with over 25 years business transformation, IT and project management experience, including exposure in EMEA, North America, Australia, MENA  and APAC.

Sam’s industry experience is extensive and includes consumer products, FMCG, fashion retailing, manufacturing, oil and gas, banking, pharmaceuticals, education, law enforcement, local and central government. She has also worked in operational management roles in food retailing, law enforcement and has setup and led a SAP Competency Centre. Sam has also held senior voluntary roles in education as a Chair of Governors of a large school and oversaw a £10m PFI project and transition of two schools to a hard federation and centre of educational excellence.

Areas of Sam’s special expertise include change management, stakeholder management, benefits management and realisation, project and programme management of local and global system implementations, commercial and quality assurance management.


Bluefin and SAP S/4HANA - welcome to the one horse race

We use cookies to provide you with the best browsing experience. By continuing to use this site you agree to our use of cookies.