Infosys-Oracle Blog

For the uninitiated, SCRUM is a relatively new software development methodology that uses an iterative and incremental process for developing software. It is one of the various agile software development methods like Crystal, Extreme Programming (XP), Open Source Software Development (OSSD), Agile Methodology (AM) etc.

A SCRUM consists of a series of less than thirty day sprints, with each sprint producing an executable. It is a “lightweight” development process since it focuses on completion of limited features based on select high level functional requirements. The objective is to iteratively build software through sprints with each sprint generating a standalone demonstrable entity. There is no big bang requirement gathering and design phase but a piece by piece progression in development. As more and more sprints are completed, both the product and the project team evolve. A SCRUM can also have Spike teams that are responsible for setting the business and technology level direction across sprints.

Scrum methodology is known to address one of the biggest pain points of the Waterfall Model, namely the linear nature of work. In a lot of projects, the requirements change during the development lifecycle and the business users find that the end product is totally out of sync with their requirements. An iterative, flexible and collaborative approach like SCRUM is said to be very suitable for dynamic design scenarios or in cases where clients have IKIWISI (I’ll Know It When I See It) type of requirements.
To be very frank, when I first heard about the SCRUM methodology I was a little skeptical about its effectiveness and delivery quality. A quick search on the Internet revealed that there are several projects where managers are happy with the outcome of this methodology. Large corporations like Microsoft have also employed it successfully to ensure faster product turnaround times. I had a conversation with some of my “very tired” project team members who were fresh out of the experience of executing a Sprint. They seemed pretty satisfied with the outcome of the methodology but brought out some salient points saying—“The success of the methodology depends on having skilled resources at your disposal and having very good Sprint Planning. Small emergencies like a team member falling sick can set the plan back quite a bit.” Given the length and size of our development effort, we need to see how each sprint progresses. My project team and I are eagerly waiting for the final outcome, to see if we can move more modules to this methodology!

It would be good to know if any of you have any prior experience with Rapid Application Development Methodologies and can share any learning’s/thoughts on it. Your comments are highly appreciated!