A Brief History

Before the advent of SCRUM in the late ’90s and early 2000s, the predominant system for organizing and predicting project outcomes was the waterfall model. The waterfall method involved setting a series of tasks to be completed, where the completion of one task would then trigger the implementation of the next. For instance, without implementing the login module in an application, implementing the session would be impossible. This sequential process seemed logical, as one task cascaded into another.

However, the flaws in this system, while not immediately apparent, were significant:

• Some tasks would become unexpectedly blocked, halting the entire project and forcing developers to skip ahead.
• Task durations often extended beyond initial estimates, rendering the task list (and associated deadlines) completely disconnected from reality.
• The model used time as the unit of measurement instead of considering task complexity, leading to uncertainties in project timelines.
• It lacked features to measure velocity or make accurate predictions.

The Arrival of SCRUM

As the ’90s came to a close, it was evident that the existing project management methodologies were broken. Project managers and team members found themselves in a system that was more of a joke than a tool for success. In the summer of 1995, a group of software development veterans gathered to propose a new organizational system for software development—one that would be useful, data-driven, and enable stakeholders to see the project’s status clearly, allowing timely interventions.

What is SCRUM?

The term “Scrum” originates from rugby, where it refers to a play involving all team members pushing together in unison, creating synergy greater than the sum of its parts. 

Rugby players performing a ‘scrum’

The first step is to identify the total number of tasks required to complete the project. Initially, physical paper cards were used to represent these tasks, allowing stakeholders to “hold” the entire project in their hands.

Next comes the Sprint Planning, where the team decides on tasks for the upcoming Sprint—a time-boxed period lasting between 1 and 3 weeks, typically around 2 weeks. During these meetings, tasks are chosen, and each is assigned story points using the Fibonacci series. For more on this you can read this article on Story Points.

Assigning story points is not an exact science but a collaborative effort. The team members vote on the points assigned to each task, often using tools like Poker Planning. Rather than averaging the votes, SCRUM emphasizes reaching a unanimous consensus through discussion.

Consistency in the chosen scale is crucial throughout the project because the next stage involves measuring velocity—the number of story points completed at the end of a Sprint. Accurately measuring velocity is key in SCRUM, as it enables project teams to predict the project’s duration and estimate the remaining work.

Once the Sprint begins, daily standup meetings are held. Participants stand (historically, to keep meetings short) and each team member shares what they worked on, what they plan to work on next, and speaks up if they are blocked. SCRUM eliminates a common issue where team members could remain blocked without others realizing it.

Retro

At the end of each Sprint, a retrospective is conducted. This involves reviewing the good, bad, and regular occurrences of the Sprint and creating actionable lists to improve performance (and thereby velocity) for the next Sprint. Weak points, communication failures, and other issues are identified, and plans are made to make the next Sprint even more efficient.

Common Misconceptions

SCRUM does not promise magical project deliveries or guarantee developers will meet deadlines. Instead, it warns of upcoming issues in advance, giving stakeholders time to take action and prevent more significant failures. It’s crucial to address some misconceptions about SCRUM:

• Utilizing SCRUM does not guarantee that developers will complete all tasks added to a specific Sprint.
  
• SCRUM does not assure project completion on time, but it does provide early warnings, allowing for adjustments such as adding more resources.
  
• Converting story points directly to time is a mistake. The process is more sophisticated and involves calculating velocity to make accurate temporal predictions, as one story point can represent tasks of varying durations.

Why Zarego Chooses SCRUM

At Zarego, we have embraced the SCRUM methodology as the driving force behind our success in software development projects. SCRUM offers us a framework that is flexible, adaptive, and transparent, allowing us to collaborate effectively with our clients. By utilizing SCRUM, we ensure that our projects remain on track, adapt to changes swiftly, and deliver exceptional results.

Why Clients Should Care

For our clients, the use of SCRUM by Zarego translates to:

• Enhanced project transparency: Clients are involved throughout the process, with clear visibility into project progress and direction.
• Improved adaptability: Changes in requirements or priorities can be accommodated swiftly, ensuring the end product meets evolving needs.
• Timely feedback: Regular interactions and demos mean that clients can provide feedback early in the process, shaping the final product effectively.
• Efficient resource utilization: SCRUM enables us to allocate resources effectively, optimizing both time and budget for the client’s benefit.

Glossary of SCRUM Terms

Poker Planning: A collaborative estimation technique where team members assign story points to tasks.

Retro (Retrospective): A review meeting at the end of a Sprint to identify improvements.

Standup: Daily meetings where team members share progress, plans, and any blockers.

Velocity: The rate at which the team completes work, measured in story points.

Sprint Planning: A meeting where tasks for the upcoming Sprint are chosen and assigned story points.