Businesses need to be comfortable that not all projects are going to succeed. Out of a portfolio of projects, people need to be comfortable that these projects will not achieve what they originally set out to do. Don’t expect that, even with agile methods and values guiding your teams, these projects will achieve what they set out to do.
Some projects aren’t set up for success. Poor organisational governance, leading to unrealistic expectations established from the outset often set up a project for a real death march. Or perhaps projects spun out of the whims of one set of people only to not understand what organisational capabilities they really have. Sometimes it comes down running a project with the wrong mix of skills and without a support structure in place that creates a time bomb waiting to explode.
Don’t forget that agile and lean methodologies cannot guarantee success. At the heart of it, agile will surface problems and make them visible. Organisations need to be prepared to confront the truth (many are not ready for this level of transparency) and support changes that will make it better.
For projects destined to fail, your best result is often to Fail Fast, take those lessons and then do something differently. Avoid the situation where a project sucks up resources that could be more effectively allocated. And don’t forget, just because a project didn’t achieve what it set out to do, it’s only a true failure if you don’t learn anything from it.
“Businesses need to be comfortable that not all projects are going to succeed.”
No, not comfortable. I mean, it happens, but it’s a *bad* thing.
The problems that you discuss are the problems that a good implementation of Agile are mean’t to address. If a project is not set up properly, hopefully the problems will become quickly apparent and can either be addressed, or the project terminated.
I do agree that merely using Agile and/or Lean for a project does not guarantee success. It can definitely help to quickly identify issues and take appropriate action.
Hopefully lessons can then be learned to avoid those same issues happening again. If the culture is open to change, it can happen. Too often the status quo is maintained, and root causes are not addressed. However I’ll keep a positive outlook and say that lessons can be learned, and things can change for the better.
I’m worried about the current trend. Agile/lean is pushed as the silver bullet although everyone is quick to deny that. The worst thing is that we are introducing quite clear antipatterns. I would say that a badly executed Scrum project is much much worse than traditional waterfall approach especially if the domain is complex.
For example if you look at CHAOS reports, it is clear that unclear/ambigious/missing requirements and specifications are one major reason for complete project failure. Despite this there is an increasing buzz about using vague “User Stories” and Code-and-Fix type development (very little or no design/analysis up-front, massive refactoring, no clear architect & architectural design and construction). Also UI design and usability in general has been largely ignored until lately.
This is horrible. We have gone from strict waterfall to the opposite end (cowboy coding). What happened to common sense?
In software development it is important to minimize the cost of change and embrace change by allowing changes along the way. However, this certainly does not mean that you should immediately start writing code based on vague stories. E.g. rapid feedback can be obtained in many ways. Incremental concurrent construction is obviously a good strategy but what happens before it is the key.
I agree with your view that Agile does not guarantee success. I hope professionals in IT are not so naive (anymore) to believe any method, process or even something like good teamwork alone is a guarantee for success.
But I think the view needs to be extended, success is a tricky thing. I find it too simplistic to try get make aim for success of every project. If projects always succeeded then there would be no risk involved which probably means aren’t venturing into new territory to stay ahead of competition…and not learning much because we’re too conservative. The essence is: you have to crash once in a while to know how fast you can really go! That’s why the CHAOS studies are pretty useless in measuring long term effectiveness of IT projects; they only focus on one project at a time (and only measure if it went according to the initial plan how un-Agile can you get?).