From the outside, the main goal of Scrum is to delight customers through early and continuous delivery of high value software. From the inside, at the software team level, Scrum is an iterative software development process that empowers teams to self organize their work, while at the same time providing a framework for the team to self improve. Customers to Scrum Teams can be end users, internal users, marketing personnel, or any other person not on the Scrum team itself, who has a stake in the software that is being developed. Scrum is a process that works in short cycles, or mini-projects, of 2-4 weeks, with software deliveries that occur every 2-8 weeks.
While no one member of the Scrum team has authority over any other member(self organization), there are three explicit roles that define specific responsibilities. One might think that self organizing teams might be prone to laziness, lack of direction, or gridlock, but Scrum Teams are still held accountable, as a team, by those (outside of the Scrum Team) who pay their salaries and/or fund their budgets.
Framework for Optimization
Scrum is considered a framework more than a process, meaning that Scrum provides a strong framework of practices, but also leaves a lot of room for team customization and optimization within the framework. The Scrum framework is probably best defined by a document called The Scrum Guide, written by the creators of Scrum. While only roughly twenty pages, the document is extremely dense with principles, rules, and practices. As an aside, many people have successfully “lifted” Scrum concepts for use in places other than software development. While some of the concepts transfer readily, others, like delivering a fully functioning, new version of a product, every 2-8 weeks, do not.
Many previous software development processes were modeled after large scale construction or manufacturing processes, which are defined processes. Defined processes are ones where the inputs and outputs are generally fairly known and repeatable. Scrum is based on empirical processes like custom made items or research and development, where the inputs and outputs are not as perfectly defined or repeatable(usually due to complexity). As such, often no two outputs look exactly alike. Think of a house that is totally pre-built and ready to move into (known as a Spec House), versus a house that is custom built from the ground up based on customer input. The custom built house is the software features that Scrum teams produce. Moving to an empirical model means that Scrum teams are no longer thought of as assembly lines, but more as teams of creative knowledge workers that produce a custom made software product.
The name Scrum was picked as a metaphor to symbolize the team effort in the sport of Rugby. This team effort is one where the entire team works closely together, all of the time, to move the ball down the field and score. The team is one where individual positions and specialties matter much less, and the overall team accomplishment matters much more.
The Real Value of Scrum
Because Scrum is based on relatively short cycles that occur dozens of times a year, the Scrum Team has dozens of re-tooling points at which to improve, based on the built-in Scrum feedback loops. As such, there is ample anecdotal evidence that Scrum greatly improves both value delivered to the customer, as well as software team efficiency. Some evidence points to mature, hyperproductive Scrum Teams that achieve 200-400% and even higher productivity gains. Further, many Scrum teams experience much improved morale as team members have full authority over how they work, as well as full authority over how they explore new software approaches and technologies.
Filed under: Scrum