How to start Scrum in your orgnaization?

I met a group of people who were doing Scrum without really understanding the Scrum values. They had a backlog, were doing daily scrums, giving demos and were doing Sprint review meetings. Product people were not involved. The demos were internal; the backlog was created by an engineering manager, QA was not included in the scrum; database design was done in the waterfall way!

Can we say that this group is doing Scrum - no! Most of the times, people tend to read one or two articles on the internet and think that it's a cool new idea, lets try it out. I think it takes much more to implement Scrum. The person or group of people initiating Scrum in your organization must be detail oriented. He/she must read Agile Software Development with Scrum first. The person should understand what real scrum values are and what they must do and what they can skip. If the person doesn't have time to study scrum in detail, get a consultant for coaching.

Scrum is a big paradigm shift from waterfall. The organization implementing scrum should first recognize the problems with waterfall process and understand how scrum solves them.

I also think that the team implementing scrum needs to have certain maturity level. When we started scrum, we were already using unit testing heavily; we had continuous integration; we had coding standards in place; we were using confluence and making documents in confluence (wiki) instead of using word documents. We already had collective decision making in place. All these things helped us a lot when we started with Scrum. I think Scrum is much more powerful if used with commonly acknowledged engineering best practices. If your team is not using any of these best practices, its better if you start with these instead of jumping on to the scrum bandwagon.

Daily Scrum Mistakes

Daily Scrum is a very useful meeting. Everybody learns about other team member's status and their road blocks. If the team is using a simple chart on the wall to enter work remaining, this meeting also reminds everybody to enter their remaining hours. Here are some typical mistakes people do in daily scrums:

1. Reporting Status to Scrum master : I have observed that many people look at the scrum master while giving their status. They behave as if they are reporting to the Scrum Master. Scrum master should purposely try to avoid this eye contact to make sure that the team member reports his/her status to the team and not to the scrum master.


2. Design Discussions : It is very easy to jump into design if a team member is talking about a design problem as his/her road block. Scrum master has to ensure that the meeting is limited to reporting progress and roadblocks and not solving the road blocks.


3. Missing people : If the meeting is scheduled early morning or late evening, it is possible that some people may not attend it. The meeting should be kept at a time convenient to everybody. The scrum master should ensure that everybody is present in the meeting every day so that he/she listens to the entire team's progress.
   


4. Requirements Clarification : Small requirement clarifications that take 30 seconds are ok, but all other clarifications should be deferred for off line discussion.

People may get turned away if the daily scrums are taking longer. The scrum master should try to finish daily scrums in 15 minutes. The best way to discuss design and clarify stories is to conduct these meetings right after the daily scrum. You can announce a design discussion meeting in daily scrum and ask interested people to stay back. This ensures that only interested people stay back and you don't have to go through overhead of scheduling a formal meeting. Quick, informal, stand up meetings are much more efficient than scheduled, formal, sit down meetings.