Skip to main content

Scrum: End of Release Review

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".

Comments

Popular posts from this blog

Overview of Hadoop Ecosystem

Of late, have been looking into the Big Data space and Hadoop in particular.  When I started looking into it, found that there are so many products and tools related to Haddop.   Using this post summarize my discovery about Hadoop Ecosystem. Hadoop Ecosystem A small overview on each is listed below: Data Collection  - Primary objective of these is to move data into a Hadoop cluster Flume : - Apache Flume is a distributed, reliable, and available system for efficiently collecting, aggregating and moving large amounts of log data from many different sources to a centralized data store. Developed by cloudera and currently being incubated at Apache software foundaton. The details about the same can be found here . Scribe : Scribe is a server for aggregating streaming log data. It is designed to scale to a very large number of nodes and be robust to network and node failures. Dveloped by Facebook and can be found here .  Chuckwa : Chuk...

Big Data: Why Traditional Data warehouses fail?

Over the years, have been involved with few of the data warehousing efforts.   As a concept, I believe that having a functional and active data  ware house is essential for an organization. Data warehouses facilitate easy analysis and help analysts in gathering insights about the business.   But my practical experiences suggest that the reality is far from the expectations. Many of the data warehousing initiatives end up as a high  cost, long gestation projects with questionable end results.   I have spoken to few of my associates who are involved in the area and it appears that  quite a few of them share my view. When I query the users and intended users of the data warehouses, I hear issues like: The system is inflexible and is not able to quickly adapt to changing business needs.  By the time, the changes get implemented on the system, the analytical need for which the changes were introduced is no longer relevant. The implementors of...

Dilbert on Agile Programing

Dilbert on Agile and Extreme Programming -  Picked up from dilbert.com - Scott Adams.