In today’s world, where things are moving faster than ever and consumers are becoming more and more demanding, getting the product right has become increasingly difficult and complex. It involves a team of people with different skills, working collaboratively and in a synchronized manner, often having only a rough picture of where they want to get.
This is why, more and more teams are turning their heads to the software development domain, famous for its complexity and speed of change when trying to adapt to this new reality. And in this software world may lie a potential solution to these problems: A framework called Scrum.
Although Scrum has been around for more than 25 years and is practiced by millions all over the world, it is still new to many people. Further on, let’s explore the history of Scrum and what is this framework all about.
Scrum origins can be traced back to Japan where the term was applied to describe an accelerated development process, which was first referenced by 2 Japanese professors, Takeuchi and Nonaka, in their 1986 HBR article, called “The New New Product Development Game”.
The term “scrum” was the analogy used to describe a better approach to product development in which the “team tries to go the distance as a unit, passing the ball back and forth”. The rugby comparison was made when they looked at the “relay race approach to product development – exemplified by NASA’s phased program planning system” in which they note that the rugby approach “may better serve today’s competitive requirements”.
In 1993, Jeff Sutherland while working at Easel Corporation read “The New New Product Development Game” in the Harvard Business Review. Inspired by the article he created the first Scrum team that worked on development of Object Studio. Their product, Object Studio, was reported as industry leader by computer trade journals. Little did they know that Scrum would be their greatest contribution.
Later on, in 1995, Jeff introduced the Scrum team to Ken Schwaber, CEO of Advanced Development Methods. Ken agreed that Scrum was a better way to build software than traditional methods used at IBM and the big eight consulting firms. He worked with Jeff to formalize the framework, which they named Scrum, as a tribute to the famous HBR article. They presented it at OOPSLA’95 and this is considered the birth of Scrum.
A Short Description
According to the Scrum Guide, Scrum is “a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.” It is designed as a collection of events, artifacts and roles which are bound together by the Scrum pillars and the Scrum values. An easy way to remember them is the 3-5-3-5-3 rule:
- 3 Pillars: Transparency, Inspection and Adaptation
- 5 Values: Openness, Focus, Respect, Commitment, Courage
- 3 Roles: Product Owner, Scrum Master, Development Team
- 5 Events: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective
- 3 Artifacts: Product Backlog, Sprint Backlog, Product Increment
The framework operates this way: At the start of a sprint, the team reviews what it must do. It then selects what it believes it can turn in to an increment of potentially shippable functionality, by the end of the iteration. The team is then left alone to make its best effort for the rest of the iteration. At the end of the iteration, the team presents the increment of functionality it built so that the stakeholders can inspect the functionality and timely adaptations to the project can be made. This loop is repeated continuously until theirs is nothing left in the Product Backlog, or until the funding is cut.
The heart of Scrum lies in the iteration, called a sprint. The team takes a look at the requirements, considers the available technology, and evaluates its own skills and capabilities. It then collectively determines how to build the functionality, modifying its approach daily as it encounters new complexities, difficulties and surprises. The team figures out what needs to be done and selects the best way to do it. This creative process is the heart of the Scrum’s productivity.
Splitting the whole product development effort into these small periods of time provides a couple of advantages:
- The team has frequent touchpoints with their customers, so they can adapt their strategy easily
- Planning is happening on the go, from sprint to sprint, instead of one big effort at the beginning of the project.
- The time to market is much lower than in the traditional way of working
- The riskiest assumptions can be validated first