Scrum – as the runners of Scrum.org will tell you – is not a methodology. It is a framework at its core, a framework of a method that relies on scientific methods to solve what can be complex problems. Scrum originated in the developer and programmer world but has found footing in other arenas as well, including sales, research, and marketing. We will only be discussing its role from a software development and project management standpoint for our purposes here.
Scrum is often confused with agile development, but the two are not quite the same. Scrum certainly contains elements of agile philosophies, but that does not mean they are the same thing. We will be examining the scrum framework, scrum principles, and scrum philosophies in the rest of this article, all in the hopes that it can help raise your awareness of how scrum can change your software development process.
History of Scrum
From a software development perspective, the phrase scrum first found footing in 1986. The Harvard Business Review published a paper named “The New New Product Development Game.” The phrase had already existed before this point; however, it was used in different terms. Prior to this point, scrum was used in the sport rugby and described a formation of players. Since the idea of scrum centers around “teams,” it makes sense that it was adopted as the name of this development ideology (for lack of a better word).
An interesting piece of trivia – or, rather, a bit of trivial knowledge – scrum can be written in a number of different ways. You will see it as Scrum, SCRUM, and scrum – it really depends upon who is writing the phrase. For purposes of this article, we will use lowercase unless it starts off a sentence or otherwise requires capitalization.
The authors of that fateful piece of work – Hirotaka Takeuchi and Ikujiro Nonaka were not traditionally software developers, interestingly enough. Takeuchi was a professor who studied business and marketing, while Nonaka was an organizational theorist who studied knowledge management. According to the two of them, the idea behind scrum was that it was a form of “organizational knowledge creation.” They thought of it as a new approach to produce commercial products to maximize the speed and flexibility of manufacturers.
The idea of scrum was based on research by Ken Schwaber and Babatunde Ogunnaike, who thought complicated products required empiricism, lest they fail and become riskier to develop. All of that is beyond the scope of this article, but the important part to know is that Schwaber implemented scrum at his own company, Advanced Development Methods. At the same time, three men at Easel Corporation (Jeff Sutherland, Jeff McKenna, and John Scumniotales) also adopted an early version of scrum. This led to Jeff Sutherland and Ken Schwaber presenting a paper that described the scrum framework at Object-Oriented Programming, Systems, Languages, and Applications ’95 – or OOPSLA ’95.
All of this lead to further development of the concept of scrum and culminated in a book co-written in 2001 by Ken Schwaber and Mike Beedle titled “Agile Software Development with Scrum.” From there, the Scrum Alliance was formed and, seven years later (in 2009), Scrum.org was founded. The rest, as they say, is history, albeit a long and interesting one, well beyond the scope of this article.
The Basic Concept of Scrum in Software Development
Scrum can best be described as a “process framework” that project managers can use for software development in very simple terms. It encourages – indeed, depends upon – teamwork, knowledge, and learning through experience, self-organization. Scrum is comprised of team roles, meetings, and tools that are designed to allow development teams to better structure and manage their workloads.
To better understand the scrum framework, you really need to know the basic elements of scrum. Here is a list of the important pieces of scrum for developers:
- Scrum Values
- Scrum Teams
- Scrum Events
- Scrum Artifacts
What are Scrum Values
There are five scrum values, and using them successfully is supposed to be the key to scrum success. They may sound a little hokey or like a corny philosophy on the surface, but in reality, they serve a legitimate purpose for software development teams.
The five core scrum values are:
Scrum Value: Courage
The Scrum Guide states: “The Scrum team members have courage to do the right thing and work on tough problems.” The idea behind this is that team members need to be honest and transparent with not just themselves but also stakeholders and other involved parties. They need to be open about the project’s current progress and any obstacles that they are encountering. This is an incredibly important value, as it ensures everyone is on the same page and resources can be allocated to prevent roadblocks, scope creep, and small problems from becoming major challenges.
Scrum Value: Focus
Focus is another important scrum value. Staying focused on goals and tasks is key to software development, no matter which “philosophy” you are following. This is even more true when your team uses the scrum framework for software creation. Each member of the team has the ability to affect the development flow, and if they do not remain focused on their assignments, the whole project can quickly fall behind schedule.
Scrum Value: Commitment
Scrum commitment is really all about not just being committed to the success of the project but really about being committed to the members of your development team. Each team member needs to be able to rely on one another, to be honest, complete tasks, and not cause any bottlenecks. If all team members are committed, it increases the chance of overall project success.
Scrum Value: Respect
Respect, in scrum regards, refers to respecting your team members as equals in all ways: equally important to the project and its success. It implies that you trust your team members and their ideas. This respect ties in closely to commitment. As The Scrum Guide says, “Scrum team members respect each other to be capable, independent people.”
Scrum Value: Openness
Openness means being open about your progress with regard to a given task. If a developer is having issues or roadblocks causing trouble with a task, they need to practice “openness” to ensure that others are aware they are having a problem. They must also be open to hearing other ideas and be open to trusting their teammates may have a solution. In addition, they should be open and honest about their teammates’ work and not shy away from offering honest feedback at all times.
Other Scrum Principles and Discussions
To cover scrum in its entirety would take an entire book. In fact, it has – it’s called The Scrum Guide. To cover the entire breadth of scrum is simply not possible in one article, as you may have surmised. To that end, this is the first part of an ongoing series that will discuss the elements of scrum, scrum tools, and software development using the scrum framework.
In this part, we covered the history of scrum and scrum values and the basic principles of scrum. In our next article, we will learn about scrum teams, how they operate, and the ominous-sounding (yet very important) scrum master.
You can read more about Scrum in the follow-up articles to this series: