The following timeline shows a brief history of Scrum:

The first mention of Scrum in the context of product development was in The New New Product Development Game-Takeuchi, Hirotaka, and Ikujiro Nonaka, Harvard Business Review 64, no. 1 (January–February 1986).

In the paper, the two professors describe efforts by companies to try to speed up their product development life cycles to decrease their time to market. They observed that companies that were successfully doing this were employing some interesting alternative approaches. 

These companies were assembling small teams of highly capable people with the right skills, setting the vision for them to build the next-generation product, giving them a budget and timeframe, and then getting out of the team's way to let it do its thing.

Some observed characteristics of these teams included having all the skills necessary to carry out the job they were being asked to do—the essence of a cross-functional team. They were allowed to determine how they best carried out the work,  so were self-organizing and autonomous. They used rapid, iterative development cycles to build and validate ideas.

Nonaka and Takeuchi called it the rugby approach because they observed product teams passing the product back and forth among themselves as it was being developed, much like a rugby team passes the ball when moving upfield. In a rugby game, the team moves as a unit and even though each team member has a specialty regarding position on the field and gameplay, any member of the rugby team can pick up the ball, carry it forward, and score a try or goal. The same was true of these product development teams—their contribution to the product development was specialist and highly collaborative.

In the section of their paper titled Moving the Scrum downfield, they list the common characteristics of the teams they observed as follows:

• Built-in instability: Some aspect of pressure was introduced, which encouraged the product development teams to think out-of-the-box and use an innovative approach to solving the problem.
• Self-organizing project teams: The teams were given the autonomy to decide how they carried out the task of solving the problem handed to them.
• Overlapping development phases: Instead of the normal sequential-phased development that you get with processes such as Waterfall, the teams worked iteratively, building quickly and evolving their product, with each iteration. Multiple phases overlapped, such that the following steps might be informed by the discoveries made in the previous one. In this way, the teams were able to gain fast feedback about what would and wouldn't work.
• Multilearning: A trial-and-error learning culture is fostered, which allows team members to narrow down options as quickly as possible. They are also encouraged to diversify their skill sets, to create team versatility. Nonaka and Takeuchi called this multi-learning because they said it supported learning along two dimensions: traversing different layers of the organization (individual, team, unit, and group) and across various functions. This cross-pollination of skills is an aspect of cross-functionality we encourage today.
• Subtle control: The approach to managing these projects was very different. To create a space for the team to innovate, they realized command-and-control supervision wouldn't work. Instead, management would check in with the team regularly to check progress and give feedback, leaving the team to manage its work how it saw fit.
• Organizational transfer of learning: If and when the development life cycle began to move towards mass manufacture, the product development team would often be strategically placed in the wider organization to seed knowledge and assist with the preparation for production.

The approach described by Nonaka and Takeuchi has similarities to the Skunk Works projects started in World War II by Lockheed’s Advanced Development Programs division. 

The Skunk Works team were originally tasked with designing and building a highly secret prototype jet fighter aircraft around a new jet engine developed by a British company, deHavilland. The work commenced on little more than a handshake, and the team was formed in a location separate from the rest of the group and given relatively free rein on how to proceed. They were given 150 days to complete their prototype; they finished it in 143.

Lockheed's Skunk Works took on many secret projects after the war finished. Their approach gained notoriety among other companies, including Apple who built the Macintosh in a Skunk Works type operation behind a restaurant in Cupertino. It also seems to have permeated through to the product development teams that Nonaka and Takeuchi were observing when they wrote their paper.

Everett Rogers (in Diffusion of Innovations, 4th Edition) points to the reason for isolating a project team and allowing them to take this crash approach to product development: it's because companies operate as bureaucracies. The stability and continuity that a bureaucratic organization seeks are at odds with the instability needed to foster innovation. Most find it undesirable to disrupt their own, currently successful, business model. The Skunk Works approach fosters maximum creativity by isolating the teams away from the organizational mainstream, allowing them to innovate around both their process and product.

Some of these ideas would go on to influence Jeff Sutherland and Ken Schwaber when they started working on the Scrum framework in the early 1990s. In 1995, they formalized and presented it as a paper at the Business Object Design and Implementation Workshop held as part of OOPSLA’95 (Object-Oriented Programming, Systems, Languages, Programming, and Applications) in Austin, Texas. In the following section we'll introduce Scrum and talk through the basics with an overview of its characteristics, roles and events.