Scrum: Mid Term Review

From a collection of writings I wrote in 2007 when I first explored this methodology.



We are almost at the middle of our release and have been trying to learn, adapt and incorporate Scrum methodology for about eight weeks now. I think this would be a right time to jot down few points on how we are progressing as I believe that, the initial euphoria/dejection about incorporating a new process has now died down and people have dirtied their hands sufficiently for about four iterations now (we have each iterations spanning 2 weeks).

First the Positive impressions about Scrum:

• Personally I am impressed by the methodology. Forget everything else, by breaking down the deliverables into atomic units, it helps the managers and engineers to monitor the work at on a regular basis (every two weeks) and make appropriate course corrections whenever mandated. This according to me is the biggest bang for the buck.


• It builds a healthy working relationships between the different stakeholders. I am really happy to note that the people from QA, Development and Doc are working together as a team intending to make progress towards the common goal rather than trying to find fault at each other's short comings.


• It helps early assessment of the modules under development and since many of the features can be demonstrated early, the feedback is also early and same can be incorporated early.

Second, What as changed?

• I think the most significant change is that we are no more doing the wasteful exercise of creating a mandatory Functional Specifications and Test plans which anyone seriously reviewed. This is not to mean that there are no documents being created in the scrum world, but the documents being created are relevant to what actually matters and to an extent is stripped of the excess fat and gloss that goes into a formal document. The biggest advantage of this approach is the material created are small, concrete and focused.


• The concept of major milestones is gone. Now we don't have to worry to meet the development complete date and keep wondering when the QA will start testing. The FUD about QA testing usually used to make us factor in a huge buffer during our planning cycle.

Third, the challenges that I think we still need to work on:

• The ability to breakdown tasks into atomic testable units - It is difficult to change the mindset of the engineers who have been thought and conditioned to think vertically. The basic idea that has always been ingrained a developer's mind is that he is responsible for his feature and on completion of his feature, QA will test, validate and certify the feature. This mindset has to change. The engineers need to think horizontally as to how, at the end of each iteration, he can give something which is complete (developed, tested and documented) which can add value to the customer. Every subsequent iterations should add additional value to the customer.


• Ownership and responsibilities - One of the basic premise of scrum is each individual takes the responsibility and works towards the fulfillment of the team's goal. This can happen when the individuals who is part of the team are mature and take responsibility for their actions. People in our teams have been tuned to taking directions and usually end up looking for directions and resolutions. This mindset need to change and the empowerment at all levels have to happen. This is a chicken and egg problem and guess will take some time before is completely sorted out


• Automation - I think we are significantly behind in this. We need to make more effort in spotting and implementing test cases that can be automated. The more automation we have, we can reduce the repetition and increase the overall productivity


• Proactive involvement of the Product Management

Fourth, What are the risks we face?

• This risk of ritualization - I am already noticing some evidence of it. It is human nature to forget the philosophy behind anything and ritualize every damn thing.


• Forgetting the Macro picture - Since everyone is focused on getting their committed items for that iteration out, I think there is definitely a risk of loosing the bigger holistic picture. Definitely concerned about how this will impact the QA effort (Hope the hardening iterations we have will take care of it)


• The risk of inter group fights - Scrum forces creation of small unified groups. Sooner or later, a tendency rises among the group to outsmart and outdo the other groups. Though this creates a competitive mindset, unless properly moderated can prevent adequate knowledge sharing across the groups.

Finally What did we loose?

• Not much - One thing we lost was the concept of weekly status meeting. The intent was to let everybody know what others have been working on. Personally speaking, I have not been a great fan of status meeting for I always thought it never achieved it's purpose.


• The big fat functional specifications and test plan - Personally, I thought this was more of a ritual than of any practical use.


• Dedicated Time for architecture and design. Personally I am still not sure where I stand on this. At one level, I understand the need to have a dedicated time for a good architecture/design, but many a times, I have observed that the design work consumes the time allocated for it, however large the allocated time is. The other issue I have with having a detail design is that too much of design results in over-designed features which are of little value to the customer.