Someone once confidently told me that Scrum was a complete project management method that dealt with stakeholder management, risk analysis and all the usual PM stuff and did it better than every previous methodology.
I’ve considered this assertion at length. Scrum does protect from change and scope creep ruining your project. Scrum does protect from a lack of communication. Scrum does protect from team under-performance. However, I’m pretty certain that scrum does not protect a team from risks from other sources.
I once ran a project which involved the amalgamation of one small company into another. A significant part of the project was the movement of a number of servers physically from one location to another over a weekend. The move had been ear-marked for a couple of weeks down the line but I happened to hear the FD having a heated conversation with the landord of the building we were moving out of.
I have to put my hand up here and admit that I had been relying on constant communication with the team and had not been formally conducting reviews of the risks on the project on a regular basis but I sure as hell wanted to have one now! I called a meeting straight away and we draw up the risks involved with the move. Overwhelmingly the risks of keeping the servers on site were vastly out factoring the risks of moving the servers early and so that’s exactly what we did.
I’ll never know if that was the right call or not (such is the nature of risk management) but the project didn’t fail – so I guess it was. However, it did teach me that communication alone is just not enough and as such Scrum is not sufficient as a stand alone method to manage risk on large risky projects.
Scrum is not a “complete project management method.” Scrum is a framework with large holes in it.
http://danube.com/blog/michaeljames/this_page_intentionally_left_blank
I wouldn’t even agree that Scrum protects from scope creep ruining your project. Scrum protects from scope creep within one Sprint (30-day iteration) only. The Product Backlog gets bigger every Sprint, and only aggressive Product Ownership can protect scope creep from ruining your project. The *minority* of Product Owners who ship tested products on time are the ones who rescope the release every single Sprint. Every single Sprint we learn more than we did before, both about our velocity, and the requirements.
Depending what your risks are, Scrum *may* help. Scrum is about taking risks early and often. Building a potentially-shippable product increment every Sprint requires doing the risk-exposing activities of integration and test earlier than we’d do in waterfall. Sometimes we discover early that the project isn’t viable at all. “Fail Fast” is seen as a good thing in these cases.
–mj
Michael James
Certified Scrum Trainer
http://danube.com/blog/michaeljames
I dont completely agree with this. One of the tenets of Agile-scrum is to surfaces risks /issues well in advance to all the projects stakeholders so that risks/issues can be maneged efficiently and on time. It does not give a solution to a problem but definitely exposes the issues on the forefront to be timely tackled.
We have successfully used some PRINCE2 management products as stabilisers for our larger projects. Whilst the Scrum Team and ScrumMaster were collectively capable of providing solutions to ‘technical’ and ’soft’ risks respectively, it became apparent that without judicious Product Owner involvement, our projects might well fail because of the impact of ‘external’ risks. The Scrum Team pushed for the Product Owner to become a Project Board consisting of the PRINCE2 roles of Senior User, Project Executive, and Senior Supplier; their main responsibility to monitor external risks and contend with any issues that fell outside of the Scrum Team and ScrumMaster’s remit. It isn’t ideal, I know, but our ScrumMasters also have other responsibilities besides ‘protecting the flock’. That’ll be our next recommendation…