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:
- Kaizen (continuous improvement)
- Timeboxing (a fixed period of time for an activity)
- Self Managed Teams (trust them to accomplish their goals)
- 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.
2 Responses to The Basics of Scrum