I talked in previus posts about the agile methodology compared with the more classic waterfall one.
Now I will introduce one of the most widely used: Scrum.
In another series I will talk more about how to introduce scrum in a company, and in another post about other agile processes as Lean or Kanban.
A very very short history of Scrum
In 1986, Hirotaka Takeuchi and Ikujiro Nonaka described in an article in the Harvard Business Review [PDF] a new approach that would increase speed and flexibility in commercial new product development.
They compared this new holistic approach, in which the phases strongly overlap and the whole process is performed by one cross-functional team across the different phases, to the rugby game.
There the whole team “tries to go to the distance as a unit, passing the ball back and forth”.
This article was widely influential in the software development area and several teams tried to put those ideas in place.
In the early 1990s, Ken Schwaber used an agile approach at his company, and at the same time, Jeff Sutherland and others developed a similar approach at their corporation and were the first to call it Scrum (Scrum in the rugby game is a way of restarting the game, either after an accidental infringement or when the ball has gone out of play).
In 1995 Sutherland and Schwaber jointly presented a paper describing Scrum at OOPSLA ’95 in Austin, TX, its first public appearance. In 2001, Schwaber teamed up with Mike Beedle to describe the method in the book “Agile Software Development with Scrum.”
What is Scrum?
Scrum is a process skeleton, which contains a set of best practices describing an iterative incremental framework for developing new products.
The core ideas of Scrum
A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements.
A second principle is to empower the teams, making them a small unit able to take all the necessary activities (cross-functional) and decideing the best way to do it.
The best practices of Scrum
- Scrum has frequent intermediate deliveries with functionality providing value to the customers, like all other forms of agile software processes. This enables the customer to get working software earlier and enables the project to change its requirements accordingly.
- The work to be done (in the form of a set of set of high level requirements) is prioritized and visible to everyone.
- During an iteration, no one is allowed to change the committed features, which means that the requirements are frozen for that iteration.
- Customers become an active part of the development team. They decide which work they want to be completed for every iteration, decide on the priorities and are available to discuss the work with the team.
- Transparency in planning and module development—let everyone know who is accountable for what and by when.
No problems are swept under the carpet. No one is penalized for recognizing or describing any unforeseen problem.
- Frequent stakeholder meetings to monitor progress—balanced dashboard updates (delivery, customer, employee, process, stakeholders)
- An advance warning mechanism, i.e., visibility to potential slippage or deviation ahead of time.
- Teams are empowered. They commits which work can they do in every iteration, everyone in the team decides its own part. Teams are self-organizing and cross-functional.
Communication across all team members and disciplines that are involved in the project is encouraged.