Pages

Wednesday, December 14, 2011

Who should be blamed for a failed Scrum Project ?

image
An interesting discussion about  Who should be blamed for a failed Scrum Project ? in Scrum Practitioners forum  made me to write this short article.    


As I started putting the comment together to respond, I was getting more questions than answers.
Here, are some of my thoughts:

  • Personally, I feel that as long as there is a blame game culture around, the weakest one gets the blame. My experience has been that being more vocal one could push away blame easily.
  • As far as I know, there is no democratic debate to nail down the culprit, its all about witch hunting.  Following paragraphs provide additional reasoning.
  • Wearing a purists hat, Trust is the foundation of all the work. Whether it is Software or non-Software work, Whether one follows Waterfall, Six Sigma or Agile. Failure is a hall mark of Mistrust.
  • Failure will not happen just like that one day. It is the culmination of issues built up over a period. The issue keeps accumulating every hour/every day. Scrum Meetings, Retrospectives were recommended to catch the issues at an early stage before it leads to FAILURE. With the context of Scrum in mind,
  • Here is the list of few more questions one should ask:
  • Did the team raise any issue at all during the Scrum Meeting ? If not, why not ? 
  • If, they had raised the issues, did the Scrum Master track it ?
  • Did Product Owner attend the Scrum Meeting regularly ? Did he/she catch the issues ?
  • Are the team afraid of bringing out the issues upfront ? Who is influencing this behaviour?
  • Did retrospective happen regularly, and issues were brought out during retro ?
  • Did stakeholders/Sponsors attend the retrospective ? Did they show any interests in the “What is not working well” column ?
  • If the team is not following any of the Scrum recommended practices, project itself is initiated with the wrong footing. Should someone be blamed for this ?

  • Answers to the above questions evoke a different set of answers and emotions.

    Before ending this article, let me share a good quote 
    As Karyn puts it:
    Blame gives people an easy out. If it’s not your fault then it’s not in your control. If it’s not in your control then there is nothing you can do about it. If there is nothing you can do about it, then you don’t have any obligation or any need to try to change. If you can blame someone else, somehow, it lets you off of the hook

2 comments:

Dave Ziffer said...

It seems to me that the person who should be blamed for a failed SCRUM project is the person who decided to use SCRUM in the first place. The idea that you can view a software project as nothing more than a linear series of features ("backlog" yeah right) is as preposterous as viewing a house as being nothing more than a collection of rooms, having no underlying common architecture, shared infrastructure, plumbing, wiring, foundation or roof. Oh yes and no architect and no blueprint. How much sillier can you get?

Venkatesh Krishnamurthy said...

Dave, Thanks for the comments. I agree with your inputs partially. Probably the person who might have decided would have done with a good intention.