The February issue of the Scrum Alliance's eNewletter presented an article by Henrik Kniberg, an Agile & Lean coach at Crisp in Stockholm and member of the board of directors of the Agile Alliance. The article entitled "What To Do When Scrum Doesn't Work" addresses a very common perception with the Scrum methodology. The premise of the article is that everyone loves Scrum when the project is running smoothly and is quick to blame Scrum when slippage or failure occurs. The article takes you through 5 steps for diagnosing the real problem, which, easily apply to any delivery methodology. What follows in the blog is my analysis of the 5 steps and applicable best practices for addressing issues.

Diagnosis 1: Are you using the process correctly? Are you doing stand-ups but allowing them to turn into 1 hour meetings? Are you not collocated? Be aware that saying that you are using Scrum as your methodology is not good enough. You need to apply it correctly in order to be successful. The author does not expect that it be followed to the letter of the law. There is room for adapting the methodology to your particular environment or project. There are core principals, however, that need to be followed.

Diagnoses 2: Are you blaming the messenger? Scrum tends to highlight problems. Sometimes this means exposing reasons why the project should not be completed. By this, the author illustrates that following the methodology often leads to the discovery of other issues which may warrant the project to fail. Creating a business case on inaccurate requirements for example, would cause the project to stop and reassess or possibly be canceled.

Diagnoses 3: Are you being impatient? Many times, scrum is seen as a quick fix. If a team is new to the methodology it will take time for them to form into a collaborative, high performing team. Give the methodology and the team time to work.

Diagnoses 4: Do you need to adapt Scrum? Sometimes, following the rule book does not work. If you have tried to follow the formal approach to scrum and the first 3 diagnoses do not apply, consider adapting the process. If writing user stories on cards doesn't work, use a spreadsheet. Print it and post in on the wall instead. Be careful not to adjust too much or you end up going back to diagnosis #1.

Diagnosis 5: Are you using the wrong process? Sometimes Scrum is not the best methodology. Whether executed right or wrong, the wrong methodology will still result in failure. There are projects that have to be delivered as waterfall. Server upgrades for example, really can't be broken up into multiple iterations and rolled out in pieces.

The author provides the following advice: "The key point here is, don't jump to conclusions…whatever you do, don't blame the tool. Scrum doesn't succeed or fail, people do. People choose where, when, how, and why to apply Scrum"

I am a supporter of the scrum methodology and there have been occasions (although few) when I have had to admit scrum was not the best approach. However, I would also add that you can easily replace "Scrum" with SDLC or UML or Waterfall, and the message would be the same. Whichever methodology you select, try to adhere to the core principals yet be open to adjustments if it does not quite fit your situation. If things do not go as expected; don't rush to blame the process. Take the time to diagnose the root cause of why the project is not successful. Once you have identified the issue then address it accordingly.

I have also seen many teams adjust the scrum methodology and made it work. After all, a methodology, by definition, is just a documented process that provides procedures, techniques, and explanations on how to deliver a project. But at the end of the day not all projects are created equal and therefore a methodology cannot always be applied the same way every time.