Skip to main content

Scrum Methodology - Initial thoughts

From a collection of writings I wrote when I first got exposed to this methodology around 2007.



At the workplace, there has been a sudden impetus to adopt this methodology. Whether we like it or not, we would eventually have to adopt this as there is a tremendous push from the top.

Hence have been reading up some stuff and trying to relate it to apply it to my daily professional way of work. From what I have observed, I believe the methodology is promising. It would invariably help in the kind of work we do. Some of the inherent positives I see include:


  • The focus on the working software over extensive documentation - Most of the time documentation is out of sync with the software and is created more as a ritual than as a knowledge base.
  • The incremental Development approach - Will provide better control and tracking of the projects.
  • The collective responsibility on the team - I expect the peer pressures to build accountability to the members of the team and would hopefully helping setting higher standards for individuals.
  • No changes during iteration - This provides sufficient cushion for the team to execute the committed tasks without hindrance and with certainty.

But, I think there are going to be sufficient challenges for this adoption:
  • Resistance to Change - I think everyone would not willingly take to any new process. The F.U.D factor is going to play a big role during the early days of adoption.
  • Politics - A new methodology is going to bring in changes in Roles and Responsibilities of different individuals. Not everyone is going to be game for this and hence politics is going to raise its ugly head. At least, at this stage, I believe the biggest antidote for this would be a strong sponsor, who can stand firm and enforce the process.
  • Learning curve - We will begin by taking baby steps. We are bound to fall and learn. But patience should prevail. Every fall should not be used as an opportunity to tout the previous two challenges.
  • Maturity of the team - From the look of it, the strength of the methodology lies in the concept of team work. The expectation is team is mature and skillful. Need to see how the behavioral aspects play out.

Bottom-line is that, it looks to be a good methodology to adopt for the kind of work we do (product development-enhancement-maintenance). But the adoption process is going to be challenging. I am planning to log my experience of that. So keep tracking this column.

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.