Scrum: A Breathtakingly Brief and Agile Introduction

by Chris Sims & Hilary Louise Johnson

I’ve been on a handful of scrum teams. I understand scrum and I like scrum. I’m not going to go into the strengths of scrum, or the negative points (unless painfully obvious in the book) of scrum. I’ve done other agile types of development, but scrum seems to be the strongest for the corporate world in my opinion.  With that said, I’ve never been on any team that fully follows scrum. There’s always subtle variations to it that the team needs. The basic ideas are the same though.

The book is short, and you can read it in a half hour. I think it is a great introduction to scrum, and some of the basic goals from all points of view. I would recommend this to anyone who has not been doing scrum, or wants to know more about it. If you’ve done it on a couple of teams, there will be nothing new for you.

The book starts out talking about the types of team members. There are three – the Product Owner, Scrum Master and Team Member. The one I found interesting and I think needs to be addressed is the Team Member. Team Members need to be cross functional in my opinion. The book talks about specialization but later retracts it a bit.

• “People who do the work are the highest authorities on how it should be done.” This to me brings to light one of the biggest downfalls of scrum, and that is poor architecture is often a result of scrum. When a developer has a misunderstanding of the ultimate goal, or different point of view, this can lead to poor decisions with architecture. You also must remember that not all developers are strong in the architecture area
• Doing my job vs. Doing the Job – The ultimate statement of being cross functional. It doesn’t mean you have to be an expert in all areas of technology of the product, but you need to be able to do it.

This goes back to my cross functional team members. I believe that scrum is under the fundamental understanding that nearly everything is able to be completed by any team member. Sure there may be a few things that are an exception, and not everyone will be on the same level, but everyone needs to act on the best interest of the team.

The book brings up burn down charts. Burn down charts are awful any time the scope changes. For example, if my product owner comes to me and adds 6 hours of work to the sprint, and I complete 8 hours of work the same day, according to the burn down, it looks like I only did two hours of work. Additionally, you show me a release burn down where there isn’t a story added. When a story is removed (say it is no longer necessary) it looks as if the team did a great job! I much prefer the idea of a burn up chart.

Meetings vs. Ceremonies – I forgot about the “ceremonies” title. At first, a major selling point of scrum and agile was less meetings. I was sick of having meetings every other day to discuss status on work. Those meetings were an hour or longer. With scrum you have more frequent, but shorter meetings. Probably a wash in reality.

Sprint Planning – I’ve never done scrum with a full time product owner. Having a dedicated resource to be a product owner is expensive. As a result, I’m reminded that I’ve never done sprint planning as efficiently as it could go. The book divides sprint planning into two parts that I don’t necessarily agree with, but I understand what they were going for.

• Part 1 (What will we do.) – The product owner decides what stories will be considered for the sprint. To me, this is pointless. The point of the prioritized backlog is the indicator of what should be done. This step only exists because product owners do not keep the backlog up to date.
• Part 2 (How we will do it.) – The team breaks up these stories and tasks them out. The product owner is available for questions on how to do this. I’ve never had a product owner regularly available during sprint planning. As a result, I believe developers need to groom the stories early to help understand the stories. This will not occur during any “sprint ceremony”, but needs to be a regular occurrence. This will also help understand the end goal of the system. The problem with my preference is that it does take a lot of time.

These are based on my experiences and opinions of scrum. Like I said earlier, every scrum team has their own obstacles that won’t work in the textbook definition of scrum. Scrum is about small teams. And if you don’t have a small cross functional team that can be trusted, you’re in for trouble down the road.