For a year I worked in a company that practiced Scrum. When I asked why, they said they had chosen Scrum because it was very similar to the things they had done before. During that year the process changed in many different ways. I began to read about Scrum, mainly Ken Schwaber's writings, and I watched some presentations available on the well-known video sites on the Internet. As I found out, frequent changes and improvements are part of the Scrum philosophy.
Here is a fuzzy summary of Scrum.
Common Sense
Transparency
Simplicity
Communication
Self-Learning
Sashimi
Common Sense about something means everybody knows it, understands it, and agrees to it (e.g. if it is a decision). Creating and keeping common sense guarantees that all team members will be well motivated and informed.
Transparency is very close to Common Sense. There will be no Common Sense about things that are not transparent. Wikis are very useful to quickly create transparency.
Simplicity relates to the Agile principle KIS: Keep It Simple. Things that are not simple bear risks. Complexity has to be split into simple building blocks.
Communication is an essential part in every software development. It is the opportunity to use the business knowledge of ALL project participants to optimally solve problems. Communication forms a land from a lot of islands. It enables learning from each other.
Self-Learning is the ability to accept critics and dare subsequent improvements. Self-Learning mainly is done in the Scrum Retrospective Meeting (see below).
Sashimi is sliced fish. This Scrum term designates a technical concept. The product is developed in time periods called Sprints (about 2 - 4 weeks), and every Sprint should produce a full slice of the "fish", including bugfixed code, unit tests, documentation, architecture, online help, quality issue fixes and so on.
The Scrum method involves the roles of a
Product Owner (commercial responsibility), a
Scrum Master, which knows and teaches the Scrum method and communicates with all roles, and a
Team, which is made up by developers, architects, testers, ... everybody that contributes to the product, up to 7 people.
Following are the process and its data.
Data:
The Product Backlog contains Features written, time-estimated and prioritized by the Product Owner. A Feature is a big thing, it might be "Integrate the temperature table into the weather report detail view". It must not be an accompanying activity like "Upgrade all database installations".
The Sprint Backlog contains the Features planned for a certain Sprint, and Tasks. Tasks serve to split Features into smaller parts. Tasks are created by Team members during the Planning Meeting, or during the Sprint. A Task should last 2 - 8 hours.
Process:
The Planning Meeting may last up to 8 hours for a 4 weeks Sprint. Pending Features are presented by the Product Owner, and are added to the Sprint Backlog. All Scrum roles take part in that meeting. Time-estimation improvements should be done. The outcome is an agreement between the Product Owner and the Team about which Features will be done in the pending Sprint. A Feature that is in the Sprint Backlog MUST NOT be changed anymore during the Sprint, e.g. by extending or simplifying it.
During Sprint Features are implemented. A classical duration is 4 weeks. Team members assign themselves Features or Tasks and work them out. The Scrum Master MUST NOT assign anything to Team members, this would break self-organization! Tasks are added to the Sprint Backlog when necessary. Result of a Sprint is, beside the product progress, a Burndown Chart, which is a diagram that maps time to done issues. It shows the progress of work, and finally the fact whether the planning was met or not. Daily Standup Meetings give the Product Owner and Scrum Master the possibility to track work. It lasts up to 15 minutes. A good time is shortly before lunch. This meeting is meant to be management information, no issue details should be discussed here. Every Team member answers three questions:
What have I done since the last meeting?
What am I going to do until the next meeting?
Am I blocked by something?
In the Review Meeting the "fish slice" is presented by the Team to the Product Owner. It may last up to 4 hours for a 4 weeks Sprint. Features that are not complete & running are not part of the Review, they go back to the next Sprint Backlog. After the Review Meeting a common sense about the status of the product should exist.
The Retrospective Meeting takes place after the Review. It should last no more than 2 hours for a 4 weeks Sprint. The Product Owner does not take part. The Scrum Master leads the Team to a discussion about what could be done better, and find the reasons why things go wrong. It is not meant to figure out "who caused that bad Burndown Chart".
Practicing Scrum showed different problems.
Developers spoke in Task numbers instead of topics: "Since yesterday I fixed 1234 and 2345, until tomorrow I'm going to do 4321 and maybe 5432, nothing blocks me, Thx." The Daily Standup Meetings were very short. After a time we agreed that this makes no sense, because we did not realize what each other did, and could not detect interfering activities. So we went to the contrary. Tasks were explained, and it was described how they were fixed. As expected, meetings grew very long. It took some time to get to a medium variant where information was presented in a consumable way, and everybody understood what the colleague was talking about. But it continued to degenerate.
It is an important responsibility of the Scrum Master to teach people what to say and how to say it. If this fails, the daily meetings might be absurd.
When I listened to the things presented in Daily Meeting, I frequently had the wish to discuss details, and how to solve issues elegantly. The Daily Meeting brings the divers to the surface, and this is the best moment to show them the dark clouds before they dive down again.
But such is not part of Scrum. Scrum is a way to manage projects. The Team is expected to be a collective that carries out Tasks through self-organization. The Daily Meeting is time-framed and too short for detail discussions.
The Burndown Chart tells a collective progress of work. You can not detect yourself in a Burndown Chart. So learning from it will be at most a collective learning. If the Scrum Master tends to "beautify" it (e.g. by taking out Tasks during Sprint), it will not even tell the collective truth. If the way to beautify it is frequently changed, you can not trust it at all.
One more important responsibility of the Scrum Master: not to beautify the Burndown Chart, and to give good environmental information about what it exactly shows. Keep it simple. Do not use charts with more than three curves. People will not understand it, and will start to ignore it. It is hard enough to learn from it.
Scrum books talk about a productivity rise of up to 300 % (Agile principles like communication over documentation might stand by when trying to increase performance). I could not observe such an enhancement, but I can imagine it. One role in traditional software engineering is the project manager. He thinks over the things that developers will have to do, and he controls their reification. Both activities are not really productive, they are just virtual. From the Scrum perspective they are wasted time.
Self-responsible developers can think over things by themselves, and quality assurance will test the outcome. Scrum Master and project manager overlap, but the Scrum Master role does not cover Team responsibilities.
How does a Scrum Team work? Is it possible to have the same Scrum process for both testers and developers? Do their iterations interfere, are there dependencies so that they could block each other?
Scrum does not say how Team organization should be done. It just gives some hints like preferring big communicative rooms over small bureaus, or encouraging punctuality and time frames.
Finally here is a list of some common Scrum mistakes:
Scrum Master assigns Tasks to developers.
This should not be done. It breaks self-organization.
New Features are appended to the Sprint Backlog during Sprint, or existing ones are changed.
Only Tasks may be appended during a Sprint. Features in Sprint Backlog are frozen during the Sprint.
The Review and Retrospective Meetings are dropped due to time problems.
This would break common sense about the state of the product, and stop the self-learning process.
The Product Owner is not present or does not know its responsibilites.
The Team might get incomprehensible Feature specifications, or no feedback about achievements.
No agreement about the Features covered in Sprint is established after the Planning Meeting.
Common Sense about the Sprint would be missing, expectations might not be met.
Meetings are not time-framed.
The purpose of the meetings has not been explained sufficiently by the Scrum Master. The Sprint loses time.
Features look like To-Do items.
Features must not be activities. Their outcome should be presentable.
So should we really use Scrum, or is this just a new fashion? Aren't our long-grown project management methods better and already include Scrum capabilities?
I think practicing Scrum needs a deep understanding about the things that happen when people get self-responsible. There is power in trusting the capabilites of Team members, and showing them that they are more than just small wheels in a big machine. And if you don't have confidence, it's time that you take part in Daily Standup Meetings, where you can relax your feet from everyday's marathon sessions :-)
ɔ⃝ Fritz Ritzberger, 2010-04-22