Agile Software Development with Scrum (Schwaber/Beedle, Prentice Hall, 2002) A reading report of Robert Hagedorn and Hagedorn und Dr. Juho Mäkiö What is actually Scrum and how can it successfully be used in the system development? - The reader finds it out while reading the book „Agile Software Development with Scrum“ of Ken Schwaber and Mike Beedle.

1

Contents of the book The book is subdivided into nine chapters. 1. 2. 3. 4. 5. 6. 7. 8. 9.

Introduction (p. 1-21) Prearrangements for Scrum (p. 23-29) Practises with Scrum (p. 31-54) How to use Scrum (p. 57-83) Why Scrum? (p. 89-103) Why does Scrum work? (p. 105-121) Advanced Scrum applications (p. 123-136) Scrum and the organisation (p. 140-146) The values of Scrum (p. 147-153)

The authors clarify the emergence of Scrum directly at the beginning upon a case example. On the basis of further case examples functionality and use of Scrum can be reconstructed, what in the first chapters already leads to a fast and good understanding of the matter. Furthermore the authors describe their experiences at the use of Scrum for the system production. Further case studies arrange a practical feeling for Scrum based projects and its management for the reader. According to the authors Scrum is a radically different approach for the process of the system development. Scrum implements an empirical approach which is based on process control theory. This empirical approach reintroduces flexibility, adaptabilities and productivity into the system development. With Scrum it is possible, fast, direct and economical to revive as well as to end successfully advisable and problematic projects into breaking off. Such a problem is very descriptively treated directly in the first case example. Scrum is a management and control process which specifically steers the attention on the consistency of software development and economy. Scrum was used for example also for the development for Extreme Programming (XP). The central elements of Scrum are: •

Product Backlog

•

Product Owner

•

Scrum Teams

•

Sprint

•

Scrum Master

•

Sprint Planning Meeting

•

Daily Scrum Meeting

•

Sprint Review Meeting

These central elements are explained in the following more precisely. 2

Product Backlog The Product Backlog is a list, in which all tasks and ideas concerning the project are held. Additionally the list is organized by a priority sequence of every single element. New ideas and tasks are also organized after priorities and taken up into the Product Backlog. It is an important quality of this list that she is never completed statically. Even on the contrary: Arising tasks are inmaintained dynamically during the actual software project. This means that a complete task list does not have to exist before the beginning of an implementation. So the Product Backlog develops parallel to the actual project. In principle, everyone, who is directly, or indirectly involved in the project, can contribute to the contents (Thus: User, customer, sales department, marketing department, Customer service, development department). Furthermore the Product Backlog can be seen obviously by all employees, so that the currently most important elements are evident to every interested party. The Product Backlog gives also information about which tasks are just at the moment been proceeded by the Scrum Teams.

Product Owner The Product Owner is the person who accepts tasks and ideas, organizes these after priorities and inserts them in the Product Backlog. Only the Product Owner is particularly entitled to it. He matches an effective course of development thereby.

Scrum Teams Scrum team is called a small, function-spreading group of developers. This team accomplishes all development. The Scrum Team decides itself on how many tasks from the Product Backlog it works on during a sprint.

Sprint A Sprint is a 30 days fixed time period, which is also called iteration. In this time period, the Scrum Team works isolated and exclusively on the tasks it has looked out of the Product Backlog. A restriction of the teams takes place only because of organisation standards, conventions and the frame of the Product Backlog which the team has selected. Every sprint must end by the completion of new executable product functionalities. During a sprint three different meetings take place. At the beginning the Sprint Planning Meeting is held: During the sprint phase the Daily Scrum and at the end of a sprint this Sprint Review Meeting.

Scrum Master The Scrum Master is affiliated to the management and takes on the responsibility for success and failure of Scrum. He represents the buffer between the Sprint Team and the remaining enterprise surroundings. This means that he represents outward both the team and the management to the outside. He takes over all organizational functions so that the team can concentrate as well as possible on his fixed tasks in the sprint. He represents the contact person for the team, cares about the elimination of all hurdles mentioned by the team, and supervises the team with the development. During a Sprint the Scrum Master is the only person, who may influence the Sprint Team. The Scrum Master holds all meetings which concern the current sprint (Sprint Planning Meeting, Daily Scrum Meeting, Sprint Review Meeting). He is supposed to guarantee that every meeting can as planned take place and he specifies rules, so that meetings can take place without interference. 3

The specified rules are to be dealt with later. The Scrum Master cooperates with all institutions involved. Finally he forms the team together with the management, he creates parts of the Product Backlog for the respective sprints together with the customer, he plans and initiates, too. The Scrum Master is -briefly said- the one who has the overview over the sprint, who coordinates it and makes purposefully advances.

Sprint Planning Meeting Customers, users, management, Product Owner and the Scrum Team determine the goal for the next Sprint in this meeting. The selected tasks which must be processed up to the next Product Increment are then distributed on the members of the team. This meeting is subdivided again into two parts. All listed parties are present for the determination of the actual goal in the first part, while in the second part only the members of the Scrum team come together, in order to plan the further procedure. The most important basis of this meeting is the Product Backlog and above all its points of high priority.

Sprint Backlog The construction of the so-called Sprint Backlog is a component of the Sprint Planning Meeting and takes place after the aim definition during the Sprint Planning Meeting of the current actual sprint. In the Sprint Backlog the tasks to be undertaken are specified again. Each task in such a way specified must be described in detail and everybody, who is putting it into action, should be interpreted for four to 16 hours. This Sprint Backlog is also not static, but changes dynamically during the Sprints. Then services, which newly arise, are for example inserted or tasks changed, if the processing takes less or more time as estimated. Changes in the contents of the Sprint Backlog during a Sprint may only be accomplished by the respective Scrum Team. The Sprint Backlog shows visibly for everyone the current state of the processing by the Scrum Team back into real time.

Daily Scrum Meeting The Daily Scrum Meeting is a daily status meeting, in which the current course is discussed; obstacles are identified and then removed by the management. A good opportunity to observe the level of the progress, which the team reaches, is offered hereby to the Scrum Master. The time as well as the place of this meeting should always be the same to avoid unnecessary organisation effort. It is another important quality of this meeting that it has an exactly specified and a fixed operational sequence. A Daily Scrum takes therefore about 15 minutes. During the meetings only members of the Scrum Team may speak and only the following three topics for discussion are permitted: • What has been done since the last meeting? •

What is to be done up to the next meeting? And:

•

What has obstructed the work or what will still obstruct it?

Furthermore the sequence of the speakers is fixed. Each Team Member reports in the clockwise direction, until everybody has at least reported once. The great advantages of the meeting are that many individual status meetings are avoided, the reading of innumerable reports is dropped and progress, problems and decisions take "only" 15 minutes daily. 4

Sprint Review Meeting After a Sprint carried out the parties, who already set together in the Sprint Planning meeting, meet again. In this meeting the team presents now the product expansion (Product Increment) developed during the sprint to the management, the customers, users etc. The authors describe in their remarks to this topic that in this meeting the members of the Scrum Team could report about their experiences during the Sprint and name the problems they had, but also which tasks could be processed successfully according to plan.

Further chapters of the book The following topics are treated essentially in the second half of the book: • How can Scrum be implemented in an enterprise? •

Why should one make up his mind for the introduction of Scrum?

•

Why does Scrum work so successfully?

•

How can Scrum be used in "large" projects? And:

•

Which effects has Scrum on the respective enterprise?

The authors offer quite a number of case studies for illustration; their methods are made more convincing thereby. Beyond that, they are easy to understand and can be well reconstructed. The remarks are very much detailed to each treated chapter with reference to the respective ones involved. Schwaber and Beedle can refer to an extensive accumulated experience, in which they let the reader participate in their book extensively. They point out many errors and possible solutions which can arise at the application of Scrum. Straight one therefore it is very helpful to consult this book at complications. Often repetitions from previous chapters can be found, which make it also possible for the hasty reader to get in without a detailed previous knowledge in a chapter of the book progressed further. The authors use likewise some graphics, in order to clarify certain processes. If the existing diagrams should not be sufficient for the interested reader, further good diagrams can easily be found with picture search machines in the Internet, which can be consulted for better understanding.

Conclusion Finally it is to be stated that the book "Agile Software Development with Scrum" of Ken Schwaber and Mike Beedle is a successful introduction to Scrum. The plenty case examples from the practical experiences of the authors along with thorough explanations as well as the high degree of the detail accuracy are quite helpful to the reader. Thus one receives a fast and extensive insight into the history, the range of applications and possibilities of Scrum.

5