If you watch rugby, you’ll know a scrum involves a load of players closely packed together in the dirt, fighting over a ball. The ‘Scrum’ workflow system is, unfortunately, nothing like this in the slightest. It’s less to do with struggling in the mud against your enemies, and more to do with getting tasks done in an efficient and timely manner.
Scrum, like the similar system Kanban, is an agile framework for keeping a well-organized workplace. It’s particularly popular in software development, and works well for teams of around three to nine people, but it can be applied to pretty much every workplace. Unless you work as a rugby player, in which case it’ll probably create confusion.
Scrum: What is the Scrum system?
Scrum was first introduced as a term in 1986, in a Harvard Business Review article by Hirotaka Takeuchi and Ikujiro Nonaka. The two authors actually do describe the system in terms of rugby, with a workforce acting like a team that “tries to go the distance as a unit, passing the ball back and forth”.
At the core of the Scrum system is the approach of wrangling a team to work together on specific, achievable goals within fixed periods of time. Instead of having ten people working on different, unrelated tasks with no clear end-point, Scrum endeavors to draw people together to work collectively on incremental jobs.
This is based around several roles in a Scrum team. At the top, there is the product owner, who represents the product’s stakeholders. Below this is the scrum master, who is essentially a project manager that’s responsible for putting the Scrum system into action. Below this is the development team itself.
The core workflow goes like this: the product owner comes up with a product backlog, which acts as a wish list of features to be worked on. This goes to the scrum team, with the scrum master picking a number of tasks from this backlog to be worked on. In Scrum parlance, these are called ‘stories’. These stories are then focused on during a ‘sprint’; a period of time in which the developers work on these goals and only these goals.
At the end of the sprint, the work should be completed. A review happens to gauge whether the sprint was a success, this feeds back to the product owner, and the whole cycle starts again.
Scrum board: Physical or digital?
Managing a Scrum team tends to revolve around some form of Scrum board, which helps to visualize the workflow. This could involve a big, physical board, split into columns of works to be done, works in progress and works completed. It could alternatively involve some kind of digital board, such as those from companies such as Trello and Asana.
In Trello, for example, you create columns for different stages of a workflow and populate this with cards detailing different tasks. The physical version of this board would be organized much the same, albeit with more post-it notes. In either case, the board will become the focus for the ‘sprint’, where the focus will be on getting all stages of a task finished within the time period. A sprint could last for two weeks, or it could last for a few days.
As this scene from HBO’s Silicon Valley shows, the aim is generally to get your developers working on tasks (sorry, ‘stories’), guided within the framework of the Scrum workflow.
Scrum vs Kanban
A related system to Scrum is Kanban, which also revolves around brightly colored post-it notes and words like ‘agile workflow’. The biggest difference between Scrum and Kanban is that the latter is a continual process, with workers taking cards across the board as and when they can. In Scrum, work on the board pivots around set ‘sprints’.
Roles in Kanban are also looser, whereas Scrum has a particular fondness of names like ‘scrum master’, presumably because it’s less boring-sounding than ‘project manager’, even though they are essentially the same thing. Scrum also tends to have regular catch-up sessions, called scrums, where the progress of the workflow is discussed by… you guessed it: the scrum master.