From a collection of writings I wrote in 2007 when I first explored this methodology.
To sum it up in one short sentence - "Scrum was abandoned". Many might spin it the way they like, but the hard fact remains.
This was really unfortunate given that the process during the initial days were adopted quite enthusiastically by everyone and many really tried to follow it to the best of their abilities. Now at the end of the release (which proved to be one of the more stress full releases), the whole SCRUM methodology - as adopted and followed by us is in shambles. It attracts no credibility among the team and everyone including yours truly is skeptical on the way ahead.
At a personal level, I am very disappointed as I believed and continue to believe that Scrum offers significant advantages during the Software Development lifecycle. What attracted me and in which I still see merit are:
a) The focus on doing the most important thing (biggest bang for the buck) first
b) Ability to take stock of the situation every two weeks and adjust the progress accordingly
c) The concept of shared responsibility
I am sure, there are many who share the same view across the organization. I am also sure that most of us want the process to succeed. Hence it becomes imperative to understand the causes for the failure and see how we can work through it. I have been thinking through that and this is my laundry list of reasons:
a) Any process is as good as the people in it. It is one thing to tout about a process, but it is a different ball game to commit and adhere to its core principles. I found this lacking. I observe that there is a tendency to pass on personal inadequacies and use the process to cover the same up. With monkeys around, it is fair to assume that you will end up in a mess, whether they are on trees or in a palace.
b) Executive sponsorship and need of a supportive management. It is one thing to tout about the process but a different ball of game to believe in it and enforce the same across all the stakeholders. For that you need a sponsor who is a strong believer in the process, who has sufficient credibility, and will to push the process through. He/she should exert his influence and ensure that everyone adheres to a shared vision. The management by and large should buy into the vision and be accountable for enforcing the process across the length and breath of the teams. But from what I observed, it appeared that we were always more keen on maintaining the fire engine, for we knew for sure there is going to be a fire. Rather, a better strategy would have been to spot the sources of fire, manage them thereby preventing the inferno. I believe that use of a fire engine should be an exception and should not become the solution to the problem.
c) Inability to enforce - For any process to succeed, there is a need to create a shared vision and once the majority buy in to the vision, enforce the same brutally across the board. There will always be dissidents and it is imperative that there is a credible check and balances to monitor that the process if followed and exceptions are dealt with. It is really naive to assume that any system will correct itself, without a feedback loop, to control the system and keep it on track.
d) Abdication of Responsibility - Even at the end of the release, I cannot recollect an instance when I got the opportunity to discuss an issue with the Product owner. To be honest, I was not sure who the product owner was. At the end of the release, I am not sure whether we would be able to find the velocity of each of the scrum teams or associate a shared sense of responsibilities to the teams
e) Ritualization. There is a tendency to forget the core philosophy behind a process and follow the rituals. What is the fun in having ritualistic release planning, iteration planning, scrum meetings, etc. when the underlying reasons for having them is lost.
f) Territoriality - I fail to understand why we are so obsessed with territoriality. It has come to an extent that people hold on to their resources and teams. There have been instances, when due to this attitude, we end up doing stuff that are so low in order of priority and pass on which are considered to be more important. Everyone appears to be more interested in protecting their own turfs rather than adhering to a shared vision.
I am disappointed that a golden opportunity was squandered. This is not because, we encountered some unique set of issues, but rather, we were unable to effectively address rudimentary issues that crop up during any "change".
To sum it up in one short sentence - "Scrum was abandoned". Many might spin it the way they like, but the hard fact remains.
This was really unfortunate given that the process during the initial days were adopted quite enthusiastically by everyone and many really tried to follow it to the best of their abilities. Now at the end of the release (which proved to be one of the more stress full releases), the whole SCRUM methodology - as adopted and followed by us is in shambles. It attracts no credibility among the team and everyone including yours truly is skeptical on the way ahead.
At a personal level, I am very disappointed as I believed and continue to believe that Scrum offers significant advantages during the Software Development lifecycle. What attracted me and in which I still see merit are:
a) The focus on doing the most important thing (biggest bang for the buck) first
b) Ability to take stock of the situation every two weeks and adjust the progress accordingly
c) The concept of shared responsibility
I am sure, there are many who share the same view across the organization. I am also sure that most of us want the process to succeed. Hence it becomes imperative to understand the causes for the failure and see how we can work through it. I have been thinking through that and this is my laundry list of reasons:
a) Any process is as good as the people in it. It is one thing to tout about a process, but it is a different ball game to commit and adhere to its core principles. I found this lacking. I observe that there is a tendency to pass on personal inadequacies and use the process to cover the same up. With monkeys around, it is fair to assume that you will end up in a mess, whether they are on trees or in a palace.
b) Executive sponsorship and need of a supportive management. It is one thing to tout about the process but a different ball of game to believe in it and enforce the same across all the stakeholders. For that you need a sponsor who is a strong believer in the process, who has sufficient credibility, and will to push the process through. He/she should exert his influence and ensure that everyone adheres to a shared vision. The management by and large should buy into the vision and be accountable for enforcing the process across the length and breath of the teams. But from what I observed, it appeared that we were always more keen on maintaining the fire engine, for we knew for sure there is going to be a fire. Rather, a better strategy would have been to spot the sources of fire, manage them thereby preventing the inferno. I believe that use of a fire engine should be an exception and should not become the solution to the problem.
c) Inability to enforce - For any process to succeed, there is a need to create a shared vision and once the majority buy in to the vision, enforce the same brutally across the board. There will always be dissidents and it is imperative that there is a credible check and balances to monitor that the process if followed and exceptions are dealt with. It is really naive to assume that any system will correct itself, without a feedback loop, to control the system and keep it on track.
d) Abdication of Responsibility - Even at the end of the release, I cannot recollect an instance when I got the opportunity to discuss an issue with the Product owner. To be honest, I was not sure who the product owner was. At the end of the release, I am not sure whether we would be able to find the velocity of each of the scrum teams or associate a shared sense of responsibilities to the teams
e) Ritualization. There is a tendency to forget the core philosophy behind a process and follow the rituals. What is the fun in having ritualistic release planning, iteration planning, scrum meetings, etc. when the underlying reasons for having them is lost.
f) Territoriality - I fail to understand why we are so obsessed with territoriality. It has come to an extent that people hold on to their resources and teams. There have been instances, when due to this attitude, we end up doing stuff that are so low in order of priority and pass on which are considered to be more important. Everyone appears to be more interested in protecting their own turfs rather than adhering to a shared vision.
I am disappointed that a golden opportunity was squandered. This is not because, we encountered some unique set of issues, but rather, we were unable to effectively address rudimentary issues that crop up during any "change".
Comments
Post a Comment