Over half of Agile Projects fail OR are late, over budget, or “don't make customers happy” - Time to bin fragile Agile?

Over half of Agile Projects fail OR are late, over budget, or “don't make customers happy” - Time to bin fragile Agile?

47% of agile projects are late, have budget overruns, or result in unhappy customers and on top of this a further 11% of agile projects fail outright and end up delivering nothing (Scrum, 2021).

This statistic was first brought to my attention by a friend, something of a die-hard advocate of waterfall, which did, at first, make me question the “fact” - like a Manchester United fan being told City are better. (I’m a Manchester United fan and this is happening a lot lately!!)

The claim seems to date back to a Forbes Insights and MIT Sloan Management Review and more recently was amplified by Jeff Sutherland, the Co - Creator of Scrum and Creator of Scrum@Scale.

Given that over three quarters (77%) of Agile Transformations?are?Scrum Transformations, it seems brave to draw attention to such a high rate of failure and major challenge, but Sutherland’s share does give the statistic some extra weight.

WHY IS AGILE SOMETIMES SO FRAGILE?

Experience teaches us that agile projects are rarely brought down by a common recurring factor – how easy would that be!? No, instead, the problems, challenges, and difficulties are normally unique to the project and/or the organisation and/or its people and/or how you execute and/or stakeholder buy-in and/or … you get the idea. You could follow the exact same methods as another project team but fail because of experience levels of its different personnel or idiosyncrasies of the project.

There is a big dilemma in this, of course, if there isn’t one great big obvious problem then there cannot be one great big obvious solution, nor is there a single help guide, textbook or even blog that can act as a panacea (not even this one).?Stoneseed’s portfolio of project support resources, on the other hand – worth giving me a call!

There are things you can do of course, getting the basics right helps, and being true to your chosen methodology and keeping your project and business needs in alignment won’t steer you far wrong. Also, based on personal experience of where agile projects go wrong, I developed a Triple E checklist as a (hopefully) helpful mnemonic of things that you may want to pay attention to:

Being mindful of …

Effective PMO & Governance;

Engagement;

Experience;

… can mitigate potential failure and maybe even eliminate fatal issues in agile projects altogether.

I easily could end the blog here! You know what these words all mean! I could just point you in the direction of Stoneseed’s Project Management as a Service solutions to help with any experience or knowledge gaps and our Project Management Office solutions to help with effective PMO & governance – but if you’ll stick with me, we’ll drill further down into these later.

Besides, we should pick out and celebrate the hidden good news … MORE THAN FOUR IN TEN AGILE PROJECTS AREN’T CHALLENGED AND DON’T FAIL – THEY SUCCEED! Remember the Standish Group’s often-quoted CHAOS Report (2009) put waterfall failure rate at 68%, i.e., just 32% succeed. Already, agile’s 41.62% success rate is looking less fragile!

And …. what if it’s not the methodology that’s at fault?

BAD IMPLEMENTATION

I mentioned Jeff Sutherland already, the Scrum legend claims “most of these failures are down to bad Scrum implementation” and I’d echo this. That’s true of most project failures, isn’t it?

If we’re honest…

I mean, most car accidents are down to how the person behind the wheel is driving the car, not the car itself.

Similarly, most project fails are down to implementation and execution of the chosen methodology,?not the methodology itself. It’s a hard truth to swallow, but a forensic post-mortem of most fatal projects would reveal enough of the project team’s DNA on the victim to secure a conviction! It’s just easier to point the finger at “waterfall” or “agile”. As they say, when you point a finger, there are three fingers pointing back at you!

METHODOLOGY-AGNOSTICISM

At Stoneseed, we provide resources and talent for IT projects via our as a Service model. PMaaS (Project Management as a Service) is a flexible, innovative on-demand resource model that allows you to dial up and down IT project resources in sync with your delivery need.

Whether you need access to single resources for a flexible time period or a fully managed service, we have a?resource pool of Programme and Project Management specialists, who are all?experienced practitioners from across the complete portfolio of project and programmes - in fact, anything with an IT flavour.

To make PMaaS as flexible as possible, we are agnostic when it comes to methodology. As a project management consultancy, we’ll advise what we think would work best but, ultimately, if you’re a waterfall team our talent will fit in with how you like to do business – and you can read the same for Feature Driven Development, DSDM (Dynamic Systems Development Methodology), Scrum or any other agile methodology.

The bottom line with?any?methodology is that it should be chosen based on its fit with your organisation, your people and your projects. Anecdotally, I think the greatest successes are being generated by teams operating with hybrid methodologies, but many are picking and choosing from and modifying agile methodologies to suit their available team, project portfolio and company culture. However, most experts agree that adapting methodology practices before gaining experience is a risky business. Leading ‘agilite’ Alistair Cockburn said as much back in 2001 – better to select a methodology, gain?experience?by sticking close to the formal definition and?then?adapt it.

Experience brings us nicely onto your …?

TRIPLE “E” CHECKLIST

Whichever way you proceed, this?TRIPLE “E” CHECKLIST?for eliciting (or “EEEKing”!) the most value out of your agile experience may be useful:

Effective PMO & Governance

Effective PMO is key for any agile methodology to have the best chance of delivering success. The beating heart of every successful project team is an effective Project Management Office (PMO), ensuring well defined processes and governance, planning, forecasting, project resourcing, the foundations for success.

The PMO is the invaluable link between your business strategy and project delivery, and while PMOs come in many shapes and sizes, from smaller Project Support Offices to full enterprise PMOs, and it’s never a one size fits all – the impact they bring is tangible.?So, whether it’s a small team, an office or even virtual, effective PMO sets and maintains standards for project management throughout an organisation and oversees creating and embedding procedures and best practices.

At Stoneseed our?Portfolio, Programme and Project Management Office, with P3O qualified staff,?is the backbone of every service we deliver via our Project Management as a Service (PMaaS) model. From onboarding clients to resourcing projects; through consultancy, service provision and transition, it is integral to the success of all our services.

Stoneseed offer a complete Project Management Office (PMO) range of services from provision of single resources to a team of PMO experts; or a full PMO service package via a Managed Service. We also offer PMO Consultancy and Technical Design Authority, if you have a PMO you wish to refine and improve.

Engagement

A recurring comment I hear from challenged, failed or failing agile projects is that X just didn’t buy-in or Y just didn’t get it.

I think you have to channel the founding members of the "The Agile Alliance", who back in 2001, met at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, where they talked, skied, relaxed, ate, drank and agreed on the Manifesto for Agile Software Development.

I mentioned Alistair Cockburn earlier, I remember reading his initial concerns - "I personally didn't expect that this particular group of agilites to ever agree on anything substantive."

His post-meeting thoughts “I was surprised that the others appeared equally delighted by the final phrasing. So, we did agree on something substantive."

For agile methodologies to deliver, all involved must agree?substantively, that includes sponsors, management – everyone. As ScrumInc put it “This requires more than executive sponsorship, it requires?executive participation as Agile leaders.” Agile methodologies are a ‘lighter touch approach’ and as a result are only as strong as their weakest link.

Experience

Touched on this already, but experience weighs heavy when measuring project success.

My waterfall evangelist friend and I?are?exploring a switch to agile, the greatest concern he has is a valid one – lack of experience.

You are better off sticking with what you know and confidently delivering a ‘successful’ (albeit less efficient) project than making a leap in the interests of greater efficiency and failing. It’s a no brainer – but it happens – teams are lured from their tried and tested by shiny new methodologies and it doesn’t always end well.

My friend’s project colleagues are divided across three teams that have organically established over time, and while each team ‘prefers’ waterfall - that’s more of a cultural thing (executive management support, clear statement of requirements, proper planning protocols are considered cultural essentials).

Of these three teams, I estimate one could run projects using an agile methodology now, one would struggle and one (made of relatively new starters, i.e. three years or less) is chomping at the bit!!!

My suggestion is to split the teams up and spread the experience across the whole organisation (and use Stoneseed’s PMaaS to plug any short-, mid- or long-term gaps). The complementary talents of this team will naturally lift each other’s skill sets. Years of waterfall structure and know-how are not lost by switching to agile they are given a new lease of life.

Meanwhile, combining ‘team you can’t teach an old dog new tricks’ and ‘team new tricks’ can have transformational effects with everyone’s different experiences merging to create a combined ‘hive mind’ that is greater than the sum of its parts.

If you don’t have the option to spread experience across your teams, remember you can buy it in! Stoneseed’s Project Management as a Service team have experience of multiple technology solutions, sectors and industries, and we work on all types of projects and programmes, like Business Change, Transformation, Infrastructure, Digital and IT Project Delivery.

All Stoneseed's PMaaS services are available onsite or remote, in fact we are experts in Remote Project Delivery.

In conclusion, it’s over two decades since the Manifesto for Agile Software Development was drawn up and, like IT Projects and business landscapes, it’s been evolving ever since.

Far from binning agile, we should be bolstering it as it evolves.

And remember – the Triple E!

Strive for maximum stakeholder engagement and access Stoneseed’s Project Management as a Service solutions to help with any experience or knowledge gaps and our Project Management Office solutions to achieve effective PMO & governance.?


Find out more about Project Management as a Service from Stoneseed


Sources

https://financesonline.com/35-essential-project-management-statistics-analysis-of-trends-data-and-market-share/

https://www.pmi.org/learning/library/agile-problems-challenges-failures-5869

https://scruminc.wpenginepowered.com/wp-content/uploads/2020/08/Why-47-of-Agile-Transformations-Fail.pdf

https://www.scruminc.com/why-47-of-agile-transformations-fail/

Rob Kirk

Project Management Consultant at Stoneseed Ltd

1 年

What a headline! The thing is a with Scrum and as a qualified scrum master and someone who has seen scrum both succeed and fail, I am a massive advocate of it . Just like a I am an waterfall. I think these statistics could be challenged, the beauty of scrum and any other agile framework is that it gives you the flexibility to try change that a standard waterfall approach doesnt give you. I.e. lets try a few sprints to implement something and see where we get to, it might not work but it gets people moving an embracing change. The backlog often gets filled with everything and everything that a business wants changed which is both good and bad because it gives you the chance to get the small things changed, but does it get prioritised? Is this where these failure figures are coming from or do the things in sprint ever get finished because the complexity is misunderstood?

要查看或添加评论,请登录

社区洞察

其他会员也浏览了