Skip to main content

Scrum (1995)

The basics​

Scrum is an agile project management framework that helps teams structure and manage their work through a set of values, principles, and practices.

Scrum can be summarised as follows:

  • Scrum proposes dividing the delivery of software projects into smaller iterations known as Sprints.

  • The sprints are usually 2 to 4 weeks long. There is a repository of work items known as the Product backlog.

  • The backlog is prioritised by a team member known as the Product owner.

  • The product owner is a team member who profoundly understands the business and the product.

  • At the beginning of the Sprint, there is a Sprint planning session to determine the Sprint's goal and scope. The work items that become part of the Sprint are moved from the Product Backlog into the Sprint backlog.

  • Every day, there is a meeting known as the Daily Standup in which the team members ensure that work can continue during the Sprint as planned. Resolving any impediments is prioritised during the Daily Standup.

  • At the end of the Sprint, the completed work (known as product increment) is released, and there is a meeting known as the Sprint retrospective that aims to identify ways to improve how the team operates over time.

info

You can learn more about Scrum by reading the guide at Atlassian.

Pros and cons​

"Ease of use may not be the most important feature, but it's the one that's most important to get right."

— Jef Raskin

Moving businesses away from the Waterfall mindset was a big challenge (to a certain extent, it is still a big challenge today), but Scrum (1995) managed to "kill" Waterfall and achieve mainstream adoption by providing organisations with a clear path to adoption, including extensive documentation, certifications, case studies, etc. This ease of adoption gave organisations the confidence necessary for mainstream adoption.

While Scrum helped to improve things, It also presented multiple problems:

  • Too easy to bastardise it into “mini-waterfall”. Scrum emphasis in time-boxes (Sprints), estimates (Story points) and output-based metrics (burn-down charts) encourage organisations to emphasise outputs over outcomes subconsciously. The time-box nature of the Sprints makes Scrum too easy to bastardise into “mini-waterfall” iterations by weak leadership.

  • Unrealistic management of unknowns. Scrum failed to establish an explicit "discovery" phase. The way Scrum mitigates risks (unknowns) is by using time-boxes (Sprints). We know that estimates (Story points) in software are notoriously inaccurate; the longer the project, the more inaccurate the estimate will be. Scrum uses sprints to reduce the inaccuracy of our estimates. We can not eliminate inaccurate estimates. A more realistic approach is to embrace uncertainty through discovery or experimentation instead of pretending that estimates are an antidote for uncertainty.

  • Leads to a downward spiral of failure. Despite knowing that estimates in software are inaccurate by nature, Scrum teams often try to fill the story point capacity of each team member during the Sprint, leaving no room for mistakes. When estimation errors inevitably occur, the team has to compensate by changing the scope, increasing capacity, or changing the deadline. Brooks's law tells us that increasing capacity often leads to more issues, and management often rejects changing the deadline or the scope. Often the only option becomes to take shortcuts and introduce unsustainable levels of technical debt. In future sprints, the technical debt caused further estimation mistakes, introducing even more technical debt. Pressure and frustration ramp up; some employees experience stress, anxiety and even burnout. The best developers leave, and the entire project starts to collapse gradually; the team becomes a low-performance team and enters the dreadful cycle of employee ill-being, low engagement, low motivation, unproductivity and failure.

info

Brook's law is an observation about software project management, according to which adding manpower to a software project that is behind schedule delays it even longer. It was coined by Fred Brooks in his 1975 book The Mythical Man-Month.

  • Leads to low-performance teams. Sprints are often considered a failure when not all story points in a Sprint are delivered. Even if most of the story points were delivered or if the team worked as hard as possible. This can lead to frustration, low morale, and low engagement, ultimately leading to low-performance teams.