Agile or Fragile? 10 Lessons from Day 1 of Certified ScrumMaster Training
Today was the first day of my 3-day Certified ScrumMaster classroom based training here in Singapore. Usually I’m better at self-learning and not quite bullish on classroom training. But when I started reading about Agile practices in software development, and Scrum in particular, I had more questions than answers. I was very skeptical of it and almost sure that this stuff wasn’t going to work on my projects. I wanted to challenge it and bring up my problems to an Agile protagonist. Well who better than the co-founder of Scrum Training Institute, Pete Deemer. When I came across Pete’s class I decided to register for it, primarily for one reason - asking lots of questions (and hoping to get answers which would convince me one way or the other).
Since I don’t have a separate blog on Agile practices, I decided to use this space to document my learning. Considering that I just came out of the class, this stuff is fresh off the oven. It also means that it’s somewhat “raw”, probably not as well drafted, or as comprehensive, or as well-researched, as some of the other articles that you’ll find on this blog.
Before I start, I want to make 2 things clear.
- These are just 10 most important things that I learned today, and didn't know before the course.
- I'm a novice as far as Agile is concerned. So, if you don't agree with something that I've posted here, use the comments section and correct me.
Notes from CSM Training
- Scrum gives more importance to Customer Satisfaction (happy customers) than to the other components of the triple constraints (scope, time, cost, quality, risks etc.).
- Scrum is people-powered. Self-driven and self-directed teams are at the heart of Scrum. Nobody tells the Dev Team how to get the work done. The team decides how to accomplish their work.
- Scrum Master is "not" a Project Manager. In fact, there's no project manager in Scrum. Another important point on the same lines - do not put a manager (or a boss) to whom the Dev Team members report, as the Scrum Master. This is because the team may not be comfortable in sharing their problems openly with their boss, and it may also take away the self-driven factor out of the team.
- The Dev Team estimates their work and sets their target. Do "not" set a penalty for missing the targets. It would actually demotivate the team (we had a very interesting exercise in the class to demonstrate this).
- Sprint in Scrum is a misnomer. Sprint doesn't really mean moving as fast as we can. It actually means moving at a sustainable pace.
- Though Scrum is an adaptive approach, no one is allowed to make changes to the Sprint Backlog (read Sprint "scope") while the Sprint is in progress. If an emergency change must be made during the course of a Sprint, then that Sprint must be terminated, and a new Sprint started.
- Scrum works with distributed (or virtual) teams as well. But it is more effective with co-located teams.
- Scrum works best for complex projects where the value at stake is high. If you have small, or low-complexity, or low value projects, just continue using your existing approach.
- Scrum is not a silver bullet to all the problems in software development. In fact, it is pretty hard to practice Scrum. It requires lot of discipline and a huge change in mindset in order for it to be successful in your organization. It will bring out all the problems that had been swept under the rug for years.
- Scrum works best when you are developing new features. If you are working on projects such as infrastructure upgrade, or just doing setup work for a development environment, Scrum may not work very well.
In conclusion, the training is going better than my expectation (which was actually pretty low to start with). I’m still skeptical about Scrum, and haven’t been convinced one way or the other. But it’s still early days. We have 2 more days to go, and I’m looking forward to Day 2. Stay tuned for more updates.
Image credit: Flickr / bb_matt
3 Comments
Lisa
Harwinder Singh
Hans Garre