scrum project management

So I had a phone interview with a gaming company the other day and I feel like it went pretty well. I do not know if I’ll make it to the next step of the screening, however, the interviewer recommended I read up on Scrum (a project management process), as it would help me in the future. A friend of mine was fortunately in possession of a PDF copy of the book she suggested I read in particular — Agile Project Management With Scrum by Ken Schwaber — that he sent to me until I could secure a physical copy of the book myself, and I’ve been reading through it since yesterday morning.

So before I dive back into reading it for today, I’m going to write this article as a sort of tool for memorization/comprehension of what I’ve read, but also as a light informative piece to all of my readers. Please note that because of this I may not be completely accurate in my understandings of Scrum just yet, and any “facts” I go on about should be taken with a grain of salt until you have read about Scrum from a more reliable source.

Before I begin, let me bring up an opening thought that I know most people think about when I explain what I’ve been reading: I don’t know why the process is called Scrum. I thought it would be one of the first things addressed in the book or that SCRUM was an acronym for something clever and tech savvy. So to answer this question, I’ll head over to the reliable Google:

A scrum is a team pack in rugby where everyone in the pack acts together to move the ball down the field of play.   — From this website

Aha! Well, that certainly makes sense. It’s not very techy, but I do understand the parallels between the sports term and how the process works. I can only assume that Scrum’s creator Ken Schwaber must have been a rugby fan, then. The more you know!

Scrum is described as both a simple and yet challenging process to learn — simple because it’s easy to understand and based on what should be common sense, but challenging because it drifts away from the traditional “project manager” mindset that many companies and individuals are used to.

The Scrum system is made up of three roles: The Product Owner, Scrum Master, and the Team.

The Product Owner is usually the client or voice of client, who funds the entire project. They create a list of requirements of the project in question called a Product Backlog, which is basically the first and most important step in the entire affair. The Product Owner has a lot more input and hands in developing the project, rather than simply saying what they want and leaving the project lead to get it done. The Product Owner’s biggest concern is the ROI — Return Of Investment, or rather, what the company gets back after putting time and effort into a product. A common example of a Product Owner would be, say, a representative of EA overseeing the production of Bioware’s Dragon Age III.

The Scrum Master is not a project manager. Project Managers are somebody’s boss; traditionally, they assign tasks to team members and oversee the progress. Scrum Masters are more like a coach and Scrum guide, as well as a sheepdog that guards its flock (the team) against any wolves (distractions in the form of unneeded assignments or other meddlesome people). They teach others how Scrum works, enforce the rules of Scrum and helps the team keep focus. They lead each sprint and daily scrum (I’ll go into those in a bit), but allow the team to govern itself.

The Team is pretty self-explanatory — a group of talented individuals that take the objective at hand and make it happen by the deadline. In Scrum, teams are cross-functional and no individual member is expected to do one solitary kind of work. There are always experts in certain fields, of course, but everyone acts as a problem solver and designer throughout the project. More importantly, the teams are self-managing and self-organizing; they determine what they’re going to do, and don’t really report to anyone outside of their daily scrum and sprint meetings. The ideal Team size is no more than 8 people, but in the case of one of the book’s examples, a larger team may break into smaller, more manageable teams according to the scrum rule stating teams are allowed to self-organize.

A Sprint is a 30 day period during which the Team completes one of the requirements from the Product Owner’s Product Backlog from start to finish, concluding with a presentation of an item that is completely polished and if the Product Owner suddenly decides to, able to be shipped on its own. Sprints begin with a Sprint Planning period during which everyone is present: the Product Owner, the Scrum Master, and the Team. Examples in the book have explained how any of the members of those three roles missing the meeting can prove disastrous to the project’s organization and morale.

The Planning Sprint lasts no more than 8 hours: the first four hours are dedicated to the Product Owner introducing the project in mind and his or her Product Backlog. Together, the Product Owner and Scrum Master narrow down the list of requirements to the items of highest priority. The last four hours allow the Team to choose which high-priority item will be worked on for the next 30 days, and how they can realistically accomplish this goal in a manner that is acceptable to everyone. These meetings have a  time limit to encourage getting to work, rather than thinking about getting to work.

One of the best features of Scrum is how it encourages adaptability; one of the big rules of Scrum is that the Team may not be disturbed or distracted from their assigned task by anyone, including the Product Owner, until the 30 day Sprint is complete. To balance this, the Product Owner may then redirect the Team to focus on another or new high-priority item at the beginning of the next Sprint’s planning meeting as a result. That way, the Product Owner has more of an active hand in what the Team works on, but the Team is allowed to work in peace without being pulled every which way. These two parties are, as I mentioned before, mediated and guided by the Scrum Master.

Daily Scrums, in turn, are quick 15 minute meetings led by the Scrum Master that has each team member answer three simple questions: What are you working on? What do you hope to accomplish between now and the next Daily Scrum? What impediments can potentially stand in the way of accomplishing this goal?

In one of the book’s examples, a Scrum Master misunderstood the process and went around with a list, asking every team member these questions. He was then later corrected and proceeded to go about conducting the Daily Scrum the right way: by allowing each team member to speak for him/herself, rather than checking in on assigned tasks. The two roles don’t seem too different, but people with more autonomy tend to care more and feel more dedicated to the project at hand rather than those simply following orders. These are just some of the key aspects that make Scrum so successful.

As I read and continue to read this text, I am eager to learn how to become a Scrum Master myself. I am fully aware that my college education directed me towards a Project Management role, which I am able to do competently but have never been 100% keen on being a sort of enforcer of tasks. I like the adaptability, team-trusting, and open communication of Scrum, and would be more keen to join a company that utilizes this process.

I’ll post more about Scrum when I finish reading the book. If you’re interested in Scrum yourself, you can purchase the book in question on Amazon here.

And here’s hoping I land the job I was interviewed for!

Leave a Reply