What is Scrum?
Note: This is the first in a continuing series of posts re Scrum Intro.
I am starting a series of posts to explain quickly what Scrum is.
It turns out that Scrum is very simple, and yet difficult to explain concisely.
The main purpose of this series is to give my course attendees a bit more of an introduction than the Scrum Guide.
Scrum is an Agile method co-created by Jeff Sutherland and Ken Schwaber in the early 1990s.
It was known then, and has been known since, to enable teams to achieve greater productivity, to find work more satisfying and to produce wonderful products for customers. Scrum is not a miracle, it is not a panacea, it is no guarantee, but teams regularly do impressively better by using it.
Scrum is one of many agile methods.
Agile methods are usually defined as those methods that follow the Agile Manifesto and the Agile Principles. Jeff Sutherland and Ken Schwaber were both present when the Agile Manifesto and Agile Principles were created. They helped create them.
One of the key things about Scrum is that it is simple.
Scrum is only providing a bare framework for a team to work. With the fewest possible constraints it enables the team to pop up to a new level of functioning.
What is Scrum essentially? Ah!, this is hard to say. It was created by two guys in New England and they like to express themselves practically, so you may have to experience Scrum for awhile before you can answer the question.
Scrum is a team sport. Scrum tries to enable a team to be more successful, or at least to evaluate how they are doing, and then decide what to do with their findings.
I mean a real team. That is, all members of the team are expected to collaborate. Each is supposed to take full ownership of the success.
This does not mean that everyone is equal or that they all have equal skill sets, or skill in all areas. Together, they are taking on the goal of success. They are taking on the vision as defined (usually and mainly) by the Product Owner.
I mean a real team. Virtually everyone in business has been told, “You are on team X.” Mostly those are work groups or something similar, not real teams.
Among the attributes of a real team is that each member is 100% dedicated to only one team, and the team has a common purpose and all members of the team are invested to that purpose to accomplishing that goal.
Within the team, Scrum defines three roles:
- Product Owner
- Implementer (role)
Note that the current Scrum Guide calls the implementer role the ‘team’ role, which I think is confusing to beginners. It gives the impression that there is a team within a team. I find this is not helpful.
Scrum lore has the ‘chicken and pig story.’ I am told some cultures do not like this story (my apologies), and so it is used less, but in the U.S. (where I live), it is still a useful metaphor. (Let us of course agree that no one truly wishes to be compared to a barnyard animal.)
I will not give the story here, but the idea is that the pigs are committed and the chickens are ‘only involved.’ From the point of view of the pigs and their work, to be ‘only involved’ is not bad, but it also is not good. The chickens are normally less reliable in delivering what is wanted on time with high quality, but we find chickens are always necessary. The pigs can never, in my experience, complete their work without some help from some chickens.
Roles Outside the Team
I want to mention two more roles outside of the team.
- Customer. Customers are those real people who will use our product. They may be internal or external to the organization we work in. It is in delivering something wonderful to them that we get the greatest satisfaction. Typically, customers are in ‘pain’ (in some sense or other) and we are delivering pain relief. One can appreciate the urgency in doing that.
- Business Stakeholders. I use this term to represent the people that must work with the team part-time, but every Sprint, to give us feedback. I will say more about them later.
Enough for today.
The next related post is here.