Project failure rate still high. Agile is the answer.
A recent study shows how a disturbing number of development projects still fail due to poor upfront analysis.
I think that this oversimplifies – the devil is in the detail. From experience it is about far more than just “the wrong scope” (I’m referring to the project requirements as the “scope”) – it is also about “scope creep,” “scope change” and underlying business change which inevitably results in “scope change.”
If you want to scope a big development at the start of the development, you are going to have a tough choice when the inevitable scope change requests come. Either, enforce the “letter of the law” by referring to the brilliant/bullet-proof requirements documentation you created upfront OR allow the changes and “donate” the work required to the paying client.
Neither option is reasonable. Someone is going to lose out in either case.
There is an answer. It’s called Agile Development. At WWW, we use a particular methodology called “SCRUM.”
The Agile Manifesto puts the issues squarely on the table.
In simple terms: Work in smaller chunks. Deliver business value often. Collaborate with the software owner/sponsor very closely throughout the process. Accept that change is inevitable in software development – accommodate and encourage it. Ensure that everyone on the development team trained and mandated to maximize business value on behalf of the software sponsor/owner. Everyone on the team is both developer and analyst.
Category: Agile, Developers Interest, Development Processes, Office Stuff, Project Management, SCRUM
Couldn’t agree more – SCRUM and agile methodologies are the way forward…the waterfall SDLC is a thing of the past.
Important to note that SCRUM and agile methodolgies still follow all the project management principles (PMBOK) it’s just the implementation cycle that is different…
While we’re talking about value, members on any team need to be producing value – real value – for one another. Too often, non-agile approaches allow things to ‘slip’ with shoddy work produced on the assumption that another role will be there to step in and ‘test’ or ‘quality control’ or ‘architect’.
The recommended interaction within scrum ensures more talking takes place, which becomes more exposure for work done poorly, and which leads to greater incentive/pressure to deliver high-value work, done right and responsibly. The result: more wins, more often.