Why Agile Doesn’t Work

In a world of buzzwords, office acronyms and business talk that qualifies us to know more than others… Does Agile actually work?

Here is some background as to why agile won’t work within your business and what your alternatives may be.

“Agile just won’t find work for I.T. projects! I’ve been doing this for years and waterfall is the only way to plan! How do I run a sprint to capture a vendor order?”

I listened with true concern and understanding as the I.T. project manager ranted on about our organisations change to an “Agile” business. I had taken a big step down to try a PMO Analyst role from my previous Operations Management role. Everyone who didn’t know me thought I was a young junior and didn’t realise I had years of project management and people management experience. My background came from software development, specifically application development for web and mobile.

I had recently joined a company in the midst of “Agile transformation”, the buzzword of the moment. The flavour of adoption was SCRUM and we were surrounded by Agile coaches and attending training sessions to improve our “agility”. To me, it made perfect sense because I’d battled the world of waterfall for years. An iterative approach where you act upon the most up to date knowledge, requestors or product owners can update their requirements as they progress… Sounds like logic and common sense to me.

BUT… It split the company bang down the middle.
A political war ensued and some power shifted out of the hands of the Agile supporters. The pro-Agile PMO which I was part of was overthrown. Unfortunately, I left the role before I saw the conclusion. What I did know is that I.T. project and program managers hated the idea of Agile disrupting what they knew. They continued to say, “Agile is a framework, not a methodology!”
I had an opinion. My response to that was, “SO WHAT!?”.

When has a methodology ever really guaranteed a successful project delivery? When has a waterfall plan ever gone to plan and delivered smoothly? Which project manager can honestly say that the perfectly dated Gantt chart, which inevitably gets filled with buffer to cover butts, ever really delivers on time, on budget and on scope perfectly? If you miss the plan by a day have you failed? Has the project? Yet we stick to this archaic method or more so the view that it is more right.

Here is a secret project managers of the world may or may not know. Waterfall project approaches were born out of construction and we largely cram them into software and I.T. projects because as a workforce we largely lack any imagination to create processes that are logically and widely adoptable. Also, PMBOK and Prince2 like any accreditations are really driven by business organisations that are self-perpetuating (wait for my article on self-serving and perpetuating businesses).

So it’s Agile, right? That’ll solve the problem! Well… No. Not exactly. You see at the time I listened to the waterfall advocates and I was like, well let’s compare. In waterfall, you have a Gantt chart and that is essentially a list of tasks with a start and end date that you estimate in terms of man-days or elapsed time. In Agile we have a backlog which is a list of tasks where we estimate in story points because we’re scared to commit to days because we know traditionally they never turn out correct on a plan. In Waterfall we resource plan and workload balance, in Agile we take a commitment from Agile team members to commit to tasks within given timeframes.

How do you plan a vendor supplying a piece of hardware in Agile? Well, the same way you do in a waterfall project, right? You put a milestone (backlog item) which you arbitrarily mark with a date and hope to hell they deliver (whack it into a sprint when the time is right and assign it to the person chasing and.. hope to hell they deliver).

But will sticking to Agile solve these problems? Will forcing a daily standup and running through planning poker with a diverse team with singular skills sets help improve estimation? Not if you don’t become agile yourself in how you approach teams, company dynamics and adoption to make sure whatever you employ works rather than forcing principles onto people.

What I realised is that people dislike, nay, hate change. They don’t like to apply new concepts to what they know because it makes them uncomfortable to the point we lie to ourselves. We lie that any of these methods really work 100%. Frameworks and methodologies definitely help us get closer and give us a start. Will agile by the book help us deliver? If we are too rigid the only thing it really does is piss everyone off.

What will work is taking the principles it applies.
Focus on one thing at a time if you can.
Focus on as little as you can collectively as a team to remain productive.
Don’t put it aside until you’re done and make sure when you say “Done” you’re all the way done so you don’t take on technical debt you’re forever paying for. You won’t get to that later. Do it right as you can the first time. Remember nothing is perfect, especially your first approach, and adapt as best you can.
Speak more often, plan more often. Work together. And be a team rather than an individual doing their job.

Why Agile doesn’t work? It’s the people, not the method. If you can’t make it work likelihood is you won’t make anything work because even though you hate to admit it, it’s the people, not the method.