The emergence of Scrum management

The name Scrum in the context of development originated from the article The New New Product Development Game. Professors Hirotaka Takeuchi and Ikujiro Nonaka published the article in the Harvard Business Review in 1986.

From research at various companies such as Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox and Hewlett-Packard, they concluded that the successful development of new products is best done according to the rugby approach.

The rugby approach provides the speed and flexibility needed during development to meet customer needs in a rapidly changing market.

The traditional sequential approach is like a relay race. One group of specialists complete their work and passes on a partial product to the next group of specialists. This approach proves insufficient for the development of new products in a changing environment. In the relay approach, the process is defined and the project goes from phase to phase: concept, analysis, design, development process, pilot production and then production. Functions are specialized and segmented so that the product under development is processed separately by different specialists in the different phases.

The companies that are successful with their new product developments are companies in which the development process is created by the constant interaction of a multidisciplinary team, whose members work together from the beginning to the end. In the project, several phases are in progress and overlap into the later phases of development. The multidisciplinary team works together as a rugby team. They take the next sprint together while they pass the ball to each other to achieve a good result.

The management process that the companies used to work according to the rugby approach was called SCRUM management by Nonaka and Takeuchi. It is named after the SCRUM in rugby; a formation of players who get together in a tight group when the game has to be resumed to come to the next attack.

The Scrum framework

In 1995, Ken Schwaber and Jeff Sutherland put Scrum on the map in the world of software during the OOPSLA conference. In the article SCRUM Development Process, Ken Schwaber introduced the Scrum approach based on work in the New New Product Development Game, his research and work in the field of empirical process control.

For several years now, Ken Schwaber and Jeff Sutherland have written the official definition of the Scrum framework in the Scrum Guide. The Scrum Guide has now been translated into many languages and can be found on Scrum.org under the Scrum Guides.

The Scrum flow

Scrum is an agile approach to develop new products. It is a value-driven approach that ensures that the most value is delivered within the constraints of time and budget. The central question is no longer “are we still on schedule and within budget?” But the central question is “what prevents us from delivering to our customers today?”. This gives projects a focus on creating customer value instead of meeting a schedule. The result is a product that only has valuable functionality, better meets the needs of the customer, is cheaper to develop, is delivered faster and is of higher quality.

Scrum assumes that you don’t know exactly what your product will be and you don’t know exactly how to make it. There are more questions than answers! That is why you want to learn as much as possible during the project about what the product should be, how to make the product, what customers find important and at what cost the product can be realized.

To properly deal with the associated risks, Scrum sees the development process as an empirical process or a black box. This creates opportunities to frequently inspect where you stand with your product development in terms of progress, costs, risks and expected value. Scrum also ensures that you always take the latest insights and customer feedback with you to determine the next step in the development process.

Vision

A Scrum development process starts with a vision. A vision that indicates which customer needs are solved, who the customers are, which attributes are essential in the product and how it provides a business model. The Product Owner is the driving force behind the vision and uses the vision to obtain financial resources. This vision is concrete enough to provide a clear direction. The vision is also vague enough that the path to realization is free to emerge. The vision is realized in collaboration between the Product Owner, the Development Team and customers. As a result, the people in the team are involved and feel responsible for the success.

Product backlog

Based on the vision, the Product Owner makes a plan together with the Development Team. An important part of the plan is the Product Backlog. The Product Backlog is a value-ordered list of all the assumptions of the work that must be done to realize the vision. What is most valuable is determined in consultation with the Development Team and stakeholders. What is valuable depends on the risks of costs, technology, business value and knowledge. The product backlog is the starting point and is rearranged after each sprint based on the most recent information.

Iterative and incremental

To reduce the various risks and learn as much as possible, development is done in short sprints of up to 30 days. A Sprint starts with a Sprint planning in which the Product Owner and the Development Team determine the work for the upcoming sprint. The Product Owner is responsible for the value of the work being done. The Development Team is responsible for the quality of the work that is delivered.

During the sprint, the self-organizing Development Team meets daily in a Daily Scrum meeting of max 15 minutes. In the Daily Scrum, the Development Team examines where they stand and how they can best help each other that day. They also make a daily schedule together. The Development Team ensures full transparency by making visible every day which work is in progress, what the estimated work is still to be done and what the progress is. The Development Team has all the skills required to successfully complete a Sprint.

At the end of a Sprint, a working Increment or an extension of the software product is delivered that is potentially deliverable to production. The increment is inspected by the stakeholders in a Sprint Review meeting. Furthermore, the Sprint Review meeting discusses progress to date, organizes the product backlog and obstacles that stand in the way of the Development Team. The purpose of this meeting is to create transparency for the stakeholders, to get feedback and to determine what is most valuable to tackle the next sprint.

The Sprint concludes with a Retrospective. In this meeting, the Product Owner and the Development Team will examine how they can improve in terms of collaboration, the process, tooling and the quality of the Increment. The result is actions for improvements to be picked up in the upcoming Sprint.

Risk management in Scrum

In Scrum, you deliver an increment of working product that a customer can experience in every Sprint. The result is:

That customer feedback reduces the risk of developing a product that does not meet the customer’s needs;
That you reduce investment risk because you can finance per Sprint. This allows you to decide to quit after each Sprint when you have added enough value. Or to invest more depending on the reactions of customers and other stakeholders.
That customer feedback validates the assumptions earlier.
That feedback from customers and stakeholders help you determine what is most valuable to pick up next;
That it is completely transparent what work has been done, what work has not been done and how much work still needs to be done. This gives the stakeholders maximum information so they can make the best decisions;
That you measure real progress and can make a reliable prediction about when the functionality will be ready;
That the product has been tested in the production environment and that errors are detected and solved when it costs relatively little to solve them;
That you are completely ready for every Sprint and can, therefore, make optimal use of the opportunities that arise. You can quickly respond to new information and opportunities that come by;
That it is clear whether the Scrum Team has the right knowledge and skills to realize the vision within acceptable costs and duration.
That you receive a higher Return On Investment due to frequent delivery of your product