An Introduction to Scrum

On the 9th of May Achim Kümmler, a man with decades of experience in software development and member of the Fraunhofer Institute, elaborated on the principles of a more modern approach to software development: Scrum.

Scrum is a method of agile software development and as such adheres to the values of the agile manifesto. Accordingly, people, results and flexibility are assigned a higher priority than detailed documentations and contracts, rigid plans and the processes utilized. The term itself is derived from rugby to emphasize the importance of teamwork.

Scrum can be broken down into three core parts: Roles, Ceremonies and Artifacts. The different Roles describe what part every individual of the group, which is sized anywhere between five and nine people, has to play in the project. The Product Owner, ideally a member of the party the software is developed for, defines, adjusts and prioritizes the required features, decides upon release dates and whether or not the fabricated results are to be accepted and is responsible for ensuring profit. The ScrumMaster essentially supports the group by enacting the Scrum values, removing obstacles and outside interference and enabling close cooperation. They, however, do not make decisions for the team, they may only assist them. The Team is usually composed of full-time members, who each work across multiple fields of software development. On the other hand, every area of expertise is covered by multiple people.

The Ceremonies describe the structure of the whole Scrum process. First of all, a so-called sprint is planned. A sprint is a phase of work lasting two to four weeks with the goal of producing a shippable product increment by the end of it. To plan one properly, the product backlog, a catalogue of requirements, is analyzed and a sprint goal working towards fulfilling one or more of those requirements is set. Also, the initial sprint backlog, a list of tasks needed to achieve the sprint goal, is created. During the sprint the first activity of every day is the Daily Scrum, a ceremony of about fifteen minutes in which every participant talks about what they did the day before, what they will be doing today and whether they have encountered any problems. Tasks can freely be added to and adjusted on the sprint backlog as needed. For every item on the backlog an estimate of remaining work hours is created and updated every day. Team members are not assigned their tasks, they themselves sign up for the tasks they want to work on and thus everyone carries responsibility, as they do not execute what someone else explicitly ordered them to. Afterwards the sprint is reviewed as the whole team demonstrates their accomplishments in an informal way. For the sprint retrospective everyone inspects what is or is not working, for example by asking themselves what to start doing, what to stop doing and what to continue doing.

Artifacts are the aforementioned product and sprint backlogs and a burn down chart, a visualization of the remaining amount of work in relation to time.

For projects which require more manpower, a Scrum of Scrums can be created. Every group delegates one member to send to a meeting to coordinate and communicate with the others.

The close customer collaboration greatly reduces risking to fail to provide the product needed to truly fulfill the established requirements and in the speaker's experience switching from the waterfall model to Scrum had increased productivity by about 40 to 50 percent. However, he also reported programmers to be under more pressure than before.

Ultimately it was quite fascinating to hear about agile software development from a man who was involved in "both worlds" extensively and could gladly provide detailed insights into just about any matter connected to it.