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:

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:

These pillars are active in the timeboxed events in the following ways:

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:

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