Scrum Delivers

15 May 2006

Boris Gloger
boris gloger

Introduction

“In factories around the globe, Toyota consistently raises the bar for manufacturing, product development, and process excellence,” says Jeffrey K. Liker in The Toyota Way. He goes on to define fourteen principles that he claims drive Toyota’s success.

If we accept his premise that Toyota is the world’s best manufacturer and that this success is based on fourteen clearly identified principles, then we should model these principles in our own product development processes to increase our own success. Scrum practices map very well to these principles and provide an effective way of making them part of your day-to-day workflow.

Principle 1: Base your management decisions on a long-term philosophy even at the expense of short-term financial goals.

In a Scrum project, the vision is defined by a key representative of the organization: the product owner. He translates the company’s long-term philosophy (road maps or financial goals) into specific, tactical decisions within the project. These decisions are communicated to the project through the product backlog.

Principle 2: Create a continuous process flow that brings problems to the surface.

Scrum requires a clear production workflow that is based on goals. This workflow includes timeboxed activities, clearly defined review and feedback points, and clearly defined roles: ScrumMaster, product owner and team members.

Principle 3: Use “pull” system to avoid overproduction.

In Scrum, the product owner is responsible for scheduling work deliverables according to business demands. The team works on these deliverables just-in-time, so there is no wasted work.

Principle 4: Level out the workload.

Scrum levels workload by having team members self-assign tasks from task boards based on the tasks’ complexity and their own schedules. In addition, the product owner works with the team to define the whole team’s workload, or production cycle, upfront—wecall this cycle a “sprint.” Team members respond by prioritizing each of their own tasks to deliver the desired results.

Principle 5: Build a culture that, while minimizing work stoppages, is able to fix problems to get quality right the first time.

Scrum demands that you deliver potentially shippable code at the end of each sprint. Doing this successfully requires that quality be built in from the first sprint on.

Scrum also has fixed review cycles. Only working deliverables (working code) are allowed. If you cannot deliver working code, you stop and replan your project. As soon as you know that you cannot achieve a goal for a given sprint, either the team or the product owner will stop the workflow (Scrum flow) through a process called abnormal termination. After a short replanning activity, the cycle will be set up again so that the project is back on track.

Principle 6: Standardized tasks are the foundation for continuous improvement and employee empowerment.

New tasks are inherent in new product development. So how can we standardize the way we develop our application? Three words: Test-Driven Development (TDD).

TDD standardizes the way the code will be delivered. It shows a clear path to producing code without restricting the creativity of a developer. TDD delivers high quality code. TDD is not tool-driven but mind-set driven. Everybody can use TDD, regardless of what language you are developing with.

Principle 7: Use visual controls to avoid hidden problems.

In a Scrum project, two kinds of information are tracked every day: 1) how many tasks are done; and 2) how many deliverables are done. This information is visually displayed on two charts:

  1. Sprint Burndown
  2. Product Burndown

We also gather other important management information from each sprint’s review meeting, or retrospective.

Principle 8: Use only reliable, thoroughly tested technology that serves your people and processes.

Scrum’s use of proven engineering practices such as TDD and standardized ways of running tests serve the development teams. Most of the time, these practices need to be implemented by the teams themselves, which might take more time.

Principle 9: Grow leaders who thoroughly understand the work, live the philosophy, and teach it to others.

To run Scrum you must have a patient and engaged ScrumMaster. He trains the organization (team members, product owners) in the Scrum process. The ScrumMaster focuses on implementing a culture of reduced waste and individual responsibility for the process.

In addition, the ScrumMaster works on all levels of the organization to remove impediments that hinder productivity. ScrumMasters drive change throughout the organization.

Principle 10: Develop exceptional people and teams who follow your company’s philosophy.

Scrum is designed to create high performance teams. Scrum is based on core values that stress:

  • Interactions and individuals over processes and tools
  • Working code over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

These values, coupled with a rigid, one-piece flow, will enable teams to become hyper-productive.

Principle 11: Respect your extended network of partners and suppliers by challenging them and helping them improve.

Working with more than the internal core team is essential for large-scaled projects. Scrum supports working with partners and vendors by using scaling approaches. A key element of these approaches is to manage the interfaces and expectations from partners by having clear defined contracts in the form of product backlogs.

Principle 12: Go and see for yourself to thoroughly understand the situation.

Scrum increases first-hand understanding in several ways. First, the Scrum workflow demands that teams and management have a review of the deliverables at the end of each sprint. This gives all parties the possibility to see the real status of the project.

Second, because after each sprint you have a fully functional work product, you do not have to base future decisions on guessing but on actual hard facts.

Finally, Scrum places work on risky or unknown issues very early in the project phase, so you find out early in the project what works and what doesn’t. You can then base your decisions going forward on real data instead of on speculation.

Principle 13: Make decisions slowly by consensus, thoroughly considering all options; implement decisions rapidly.

The commitment of all affected parties is crucial to the success of a given sprint. The Scrum workflow creates a common understanding before the start of a sprint, so that all parties will agree on the desired results. This agreement is based on the company goals and on the current situation and capabilities of the team that delivers the goods.

By working cross-functionally within the teams, all decisions can be made at the right time.

Principle 14: Become a learning organization through relentless reflection and continuous improvement.

Each sprint ends with a short retrospective about what has happened during the iteration. This clearly defined process was created by Norman Kerth and is now a key element of correctly performed Scrum implementations.

Reflection about what happened is a mandatory in Scrum and if done correctly results in continuous improvement.

(For a downloadable chart on how different methodologies, including Scrum, map to Toyota’s practices, click here.)

Closing

We have only scratched the surface of ways in which implementing Scrum can help organizations improve their product development capabilities. Eventually, we hope to extend Scrum to non-software development projects and organizations by showing that Scrum is a good way to implement the principles that are cornerstones of one of the most successful companies of the 21st century.

Article Rating

Current rating: 0 (0 ratings)

Comments

Anonymous, 3/3/2007 2:29:49 PM
Great article !
Link for down loadable chart mention in article is missing.

Sang
Anonymous, 3/3/2007 3:01:40 PM
We've fixed the broken link. Thank you for you comment.
Jack Sindre Hallgrim Johansen, CSM, 1/13/2009 7:05:13 AM
The link to ComparisonofMethodologies.pdf appears to be broken again. Sindre
Anonymous, 1/13/2009 8:58:29 AM
We have once again fixed the link. Thank you for reporting it.

You must Login or Signup to comment.