Scrum - from a Skeptic’s Point of View

Three days of training and a certification exam later, I’m now officially a Certified ScrumMaster (CSM). The 3 days spent in the class was time well-spent. It was a good and refreshing experience for me. In the previous post I said I was a skeptic. So, have I bought into Scrum now? Do I like it? Do I think it works? Is it better than the traditional waterfall (or SDLC) approach? Read the full article to find out.

I was a skeptic, but went into the training with an open mind and a desire to learn something new. After the training, my view point has definitely changed. I won’t say I’m totally bought into Scrum, but at least I see merit in it.

Do I like Scrum?

Yes, I do. I like Scrum’s back-to-basics, old school, no nonsense, and pragmatic approach to software development. The concepts of Scrum are really simple. Learning Scrum is relatively easy too. But applying Scrum, especially in large organizations, can be really really hard. It’s like learning a new language and becoming proficient in it. The key is to experiment, start small, inspect and adapt.

Do I think Scrum works?

In other words, do I think Scrum would work on my projects? Yes, but conditions apply! And what exactly are those conditions? The most important conditions for Scrum to work (in my personal opinion) are:

• Management Buy-in: Top management needs to recognize the need for improvement first. Then they need to understand what Scrum is and buy into it. Finally, they need to support the organizational change required at various levels to implement Scrum properly and provide continuous support.
• We should use Scrum, not ScrumBut (in other words, Scrum should be applied properly).
• Scrum has to be applied with rigor and discipline.

Is Scrum better than the traditional waterfall models?

In other words, would Scrum help to produce better software, improve productivity and boost team morale? I think it would, but I need to apply it on a few projects and see the results to be 100% sure.

Key Takeaways

• Scrum is radically different from the traditional waterfall models and requires much more discipline.
• The central theme of Scrum is Self-Organizing teams.
• Scrum doesn't mean "no documentation". Scrum says if you need documentation, do it, and do as much as you need. But the key point to remember is that working software is given more value than documentation.

  Hours spent on documentation should be worth more than the same number of hours spent developing software.

• The higher priority or riskier items get added to the top of the backlog and usually get completed first. This helps to reduce the risk on the project and ensures that the highest value items get delivered to the customer first. So even if the project is delayed, only the low priority items are delayed or left out.
• Scrum is not for people with command and control attitude.
• Scrum is not for slackers. If you are one of those people who spend 25% of your time on Facebook, 25% on personal phone calls, 25% swiping and tapping on your iDevices, and remaining 25% on decorating your status reports, then make sure that you don't end up on a Scrum team.
• Bad news for Project Managers - there's no Project Manager in Scrum (and there's no Team Lead either). The role of the Project Manager is split among the Product Owner, the Scrum Master and the Dev Team. The Project Managers have to adapt themselves to get into one of those other roles.
• Good news for Project Managers - many of their existing skills will serve them well in their new role in the Scrum world.
• Scrum Master is a specialized role. Assigning Dev Team members as Scrum Master on a rotation basis is not recommended.
• Scrum Master is a servant leader, a facilitator, not a decision maker. However, Scrum Master is always needed. It's not an optional role.
• The Product Owner owns the release.
• Individual team member performance appraisal is not a good practice in Scrum. So, what is the substitute, you may ask. I dont have the answer right now, but I'll find out.
• There is a significant change in the role of a Manager in Scrum.
• Distributed teams present additional challenges in applying Scrum.
• Requirements are documented in terms of User Stories. The key difference between User Stories and traditional requirement documents is that User Stories also tell you "why" you need something.
• User Stories are designed to be incomplete so that the team can have a conversation.
• The most important step in requirement gathering is to show working software to the customer.
• Dev Team doesn't have to wait until the end of the sprint to verify the product with the product owner. The key is to be flexible and not have any waste.
• It's better to avoid electronic tools, especially when a team first starts using Scrum, and use the old school paper-on-the-wall approach.
• Planning Poker is a very interesting estimation approach. I'm very tempted to compare it with the 3-point estimation techniques used in traditional project management. I'm not sure which is better just yet, but I like the idea that the whole team estimates every task.
• There are no fancy formulas or complicated techniques. Most things require only common sense to understand.

I have plenty of more notes, but this list captures the essence. I’ll be posting a detailed review of the entire CSM training program and details on the certification exam next.

If you have any comments, feel free to post them. I’ll be happy to hear your thoughts.

Image credit: David Castillo Dominici