The Basics of Scrum

I've personally been interested in various production methodologies since about 2005. The two that have been the most interesting to me are The Cerny Method and Scrum. Gameloft recently gave me an opportunity to participate in a Scrum Master certification course which was a lot of fun. I've since passed my PSM I Assessment and have begun implementing Scrum in a few of our teams. Today I had a small formulization of the ideas while driving to work. I've put this down here under the "Basis of Scrum".

Definition

Scrum is a framework for developing complex products.

Basis of Scrum

Scrum is based on four main ideas:
  1. Kaizen (continuous improvement)
  2. Timeboxing (a fixed period of time for an activity)
  3. Self Managed Teams (trust them to accomplish their goals)
  4. Prioritizing Value (working on the most valuable features first)

Scrum's Kaizen

Kaizen in Scrum is accomplished by using the three pillars of Scrum in conjunction with timeboxing. Scrum has various timeboxed events. The main one is called a Sprint. Sprints are generally 2 weeks to 1 month in duration. Each Sprint has the following sub-events which are also timeboxed: a Sprint Planning Meeting, Daily Scrum Stand Up Meetings, a Sprint Review, and a Sprint Retrospective. These timeboxed events give formal opportunities to employ the three pillars of Scrum which are:
  • Inspection
  • Adaptation
  • Transparency
These pillars are active in the timeboxed events in the following ways:
  • Daily Stand Up Meeting — an opportunity for transparency. Everyone knows what everyone is working on. There is a small amount of inspection and adaptation going on here too: "Oh, you're waiting for me to do X before you can do Y? Ok, I'll work on X today so that you can start on Y tomorrow."
  • Sprint Review — all the work that was done during the sprint is presented. It is an opportunity for the team and the stake holders to inspect the progress and quality of work. It is also an example of transparency.
  • Sprint Retrospective — this is an opportunity for the team to discuss what went well, and what didn't go so well. They can make a plan on what to do differently during the next sprint. This is an example of inspection, adaptation, and transparency.
  • Sprint Planning — a chance to apply the agreed upon adaptations.
Scrum teams also generate various "artifacts". These can include a Product Backlog, a Sprint Backlog, a Release Burndown Chart, Sprint Burn Down Charts, and Task Cards. These serve to visualize the project status and are viewable by all team members and stake holders and are yet another opportunity for transparency.

Prioritizing Value

Scrum has this great artifact called a Product Backlog. This is a list of every feature or requirement for your product. It isn't just a feature list though; every feature has an effort estimate (determined by the Development Team) and a value estimate (determined by a Product Owner). The Product Owner's role is to represent the interests of the client/customers. Based on what is valuable to these stakeholders the Product Owner prioritizes the Product Backlog to maximize return on investment. Generally the higher value/lower effort features make their way to the top of the list.  By following this method, if a product development time get's cut short, at least the most important features are already done.

Self Managed Teams

The Product Owner can determine what features a development team works on, but not how the work gets done. Development teams take the top priority features from the Product Backlog and determine what tasks need to be done to complete the requirements of said features. They estimate how long the tasks will take to complete and they verbally commit to completing them during the daily standup meetings. Because the "how" is in their hands, and because they verbally commit to completing tasks, members of development teams are more likely to become highly functional teams capable of solving complex problems.

The Contract

Stakeholders agree not to interfere with a development team during the duration of a sprint (if they have a new top priority item, it can be added to the product backlog and worked on in the next sprint if it really is top priority) and the development team commits to transparency and delivering value by the end of each sprint. That means a working increment of the product composed of the highest priority features.

Implementing Scrum

The easiest aspect of scrum to implement is the daily 15 minute stand up meeting. In this meeting, each member of the development team says:
  • What they finished since the previous stand up meeting
  • What they plan on finishing before the next stand up meeting
  • Anything that is blocking them from finishing their tasks
You don't even have to be using Scrum to take advantage of this short daily meeting. The rest of scrum is a lot more confusing. For instance, the classes and books don't really tell you exactly how to implement a Product Backlog, nor the right way to do it for your organization. My advice is to follow a kaizen process for all of this other stuff too. Just start to make a Product Backlog. Don't care about writing the perfect story or making the perfect estimate or doing the perfect grooming or the perfect prioritization. Just get started and make adjustments as you come across problems. Scrum is fairly open to tweaking so long as you don't do anything to reduce the three pillars of inspection, adaptation, and transparency. By the way, I've talked a little bit about Product Owners and Development Teams but there is one more role in a Scrum Team that I have yet to mention: the Scrum Master. The role of the Scrum Master is that of a "servent leader". Their main responsibility is to ensure that the Scrum framework is being used properly — that means educating the organization, development team, and product owner about Scrum; facilitating the timeboxed events as needed; and maintaining the artifacts as needed (the team can do these things too). Their other main tasks are to identify and remove impediments to the development team, facilitate communication between the development team and the product owner, and to otherwise be an advocate for the development team.

Further Reading

This entry was posted in Game Dev, Philosophy. Bookmark the permalink.

2 Responses to The Basics of Scrum

  1. Justin Roth says:

    This is totally rad stuff, Thomas. I have been increasingly interested in ways to manage big projects lately.

    As a writer, I am very aware of the amount of work an individual can perform in a given period of time. But as an employee in a business with many employees, I am less clear on how much work groups of people can accomplish and how to make sure that the communication between those people is effective enough to ensure the right outcome.

    I have found that the most frequent problem in any group project is a lack of communication. Individuals and groups do not tell each other about their progress, important revelations, and road blocks, resulting in uneven progress and needless redundancy. Scrum seems like a good method to increase communication in a structured and useful way.

    Furthermore, Kaizen, Timeboxing, and Prioritizing Value could be useful for me as an individual working towards a goal, as well. Still, it can be hard to reconcile such structured approaches with the artistic mind…sometimes the two seem to be at odds.

    Anyway, great post. Keep writing! I find nothing is more valuable when seeking to gain clarity in ones own mind than endeavoring to express yourself clearly to others.

  2. lion says:

    Timeboxing is really helpful. I make up time boxes for myself and for my reports all the time. The idea is that work expands to fill the time available for its completion.

    And those daily standups are key for communication. It is vital that you keep them to 15 minutes or less, otherwise people will feel that they are a burdon. The recommendation is same time, same place, every day. If you run up against the 15 minute time box then either 1) you have too many people in your meeting or 2) people are discussing something. As Scrum Master you need to remind people that they can have their own breakout meeting after the standup meeting to discuss their solution. We’re able to get through a team of 20 in under 15 minutes, though Scrum officially recommends no more than 9 people per team.

    Constraints are commonly cited as helping creativity. The structure reduces some of the mental anxiety or writers block and creates its own kind of space for the problem solving to occur.

    Totally agree with your last point.

Leave a Reply

Your email address will not be published. Required fields are marked *