How to spot the hidden reason for Scrum/Agile project failure

I have managed pro-bono projects and implemented multi-million dollar systems. In all of them, I faced the usual resource constraints (project triangle), scope breach and (sometimes) difficult stakeholders. A breach in good project principles, like PRINCE2, is most likely the cause - not agreeing a communication plan, not determining the stakeholders' roles, etc. All these issues are well documented and an experienced project manager is able to quickly diagnose and resolve these issues to get the project back on track.

However, there is a very rare disease that causes project failure, which is sometimes hard to diagnose. So far, I've come across this twice in my career, once as a vendor, and another time, as a mentor.

Here's how it happens. At the start of the project, one of the parties proposes to use Scrum and both sides agree to go along with it as it seems like a faster option. Most of the Scrum activities are implemented - the daily standup, user stories etc. After three months, nothing has been delivered and everyone starts blaming each other, but the project manager bears the brunt for not having a project plan à la MSProjects.

For the experienced project managers reading this, you would be asking: What project plan? This is Scrum! We use burndowns and backlogs.
And you're right. IT development teams tend towards Scrum, but the business users may not be able to support Scrum fully as they are not able to commit to the intense level of resourcing needed from them.

However, I'm not here to explain what went wrong with Scrum, nor how to set it up properly. There are plenty of case studies out there. What I want to address is when to spot the fact that a project is on the path to failure - failure that is not due to the project triangle nor due to scope or difficult people.

This hidden failure happens when you think you're in Scrum mode and someone pipes up and asks: "Where's the project plan?"

Cue loud alarm bells. At this point, be prepared for a project delay. Pre-empt this by assessing the situation earlier by monitoring:

• Releases - are these being done on a 2-3 weekly cycle?

• Testing - have users tested these releases and are issues being managed in the Product backlog?

If the answer is no to either of the above, investigate if Scrum is still viable. 
During meetings, monitor the following:

• Is your tech/vendor PM mumbling "change request" ever so often?
• Do you hear stakeholder(s) asking for a project plan?
• Have users complained about too many adhoc meetings?
• Are teams blaming each other or the project manager for delays?

If so, then the project has morphed into SDLC without the anyone realising it.

At this juncture, choices include: re-emphasizing Scrum methodologies and ensure all stakeholders buy in and commit the resources; OR call a halt to the project to re-plan a standard waterfall model. The first option is quite unlikely to work as there is a high likelihood that resources are already constrained and the different teams find it hard to meet quick delivery expectations. Calling a halt to re-plan result in a delay. It will annoy and upset stakeholders. BUT it would show a level of pro-activity on the project manager's part, and form a lesson for the organisation in how to better employ Scrum in future. The time-out allows everyone to regroup, and re-commit to the project; and with specific timelines, teams can work around their other commitments to ensure they devote specific hours to the project.

In conclusion, project managers need to be vigilant at all times to the behaviours and voices of stakeholders.

This article first appeared in LinkedIn on 5 March 2016