I am starting a series of posts to explain quickly what Scrum is.
It turns out that Scrum is very simple, and yet also very hard 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 does.
Scrum is an agile method co-created by Jeff Sutherland and Ken Schwaber in the early 1990's.
It was known then, and has been known since, to enable Teams to achieve much more 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 there 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 in. The fewest possible constraints to enable the Team to pop up to a new level of functioning.
What is Scrum most essentially? Ah!, this is hard to say. It was created by two guys in New England, and they usually like to express themselves very 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 see how they are doing, and then decide what to do about that.
We mean a real Team. That is, all members of the Team are expected to collaborate. And each is supposed to take full ownership of the full success.
This does not mean that everyone is equal or that they all have exactly equal skill sets, or that they all have skill sets in all areas. But that, together, they are taking on the goal of success. They are taking on the Vision as defined (usually and mainly) by the Product Owner.
We mean a real Team. Virtually everyone in business has been told 'you are on team X.' But 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 bought-in to that purpose. To accomplishing that goal.
Within the Team Scrum defines 3 roles:
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. And I find this is unhelpful.
Scrum lore has the 'chicken and pig story.' I am told some cultures do not like this story (I do not know which ones or why), and so it is used less. But in the US (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 not good. The chickens are normally less reliable in delivering what we want on time with high quality. But we find that 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 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. Very typically, the 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. Mainly to give us feedback. I will say more about them later.