by Birgit Fingerle
In a working environment characterised by volatility, uncertainty, complexity and ambivalence (VUCA), agility would appear to be the logical answer. Agile working translates into personal responsibility and self-organisation in view of a common goal, as well as the early involvement of customers. In agile working, each individual can use its powers of reflection and problem-solving skills to continuously improve products and processes within self-organised teams.
For the implementation of agile ideals and principles in practice, Scrum and Kanban – ( software development) help establish a project management framework. Just how the Scrum project management method works and which starting points there are for its use in library innovation and Open Science are aspects we will look at in the following.
Approaching the desired result in cycles and step-by-step
Scrum originates from software development, but is now also used as a project management method in many other disciplines, for example, in the development of a service or within research and development. Scrum is based on the principles of the ”Manifesto for Agile Software Development”, the collaborative working result of 17 renowned software developers back in 2001. It lays down values and rules of conduct for agile teams.
Just how Scrum works has been defined in the Scrum Guide. The central characteristic underpinning the method is a procedure involving short, consecutive planning cycles, each spanning a few weeks. By adopting a step-by-step approach in these planning cycles (so-called “Sprints”), teams thus get closer and closer to the optimal result. At the end of each Sprint, there is a finished result.
For example, if a new online service is designed to support students directly in their learning, and Sprints of two weeks duration are chosen. During each two-week Sprint, part of the offer would be completed, in order that it could be put online immediately after the Sprint. With such short intervals, this project management approach addresses the problem of projects getting out of hand in terms of time and money. This goal is also pursued with the principle of “time boxing”, that is working in short, clearly defined time frames (the “time boxes”). Thus, a maximum duration is reserved for meetings, which is then not exceeded. Scrum is essentially very simple, but also flexible enough to manage highly complex projects.
The Scrum team consists of three roles
Scrum teams are highly self-organised. A Scrum team essentially consists of three roles: Product Owner, Scrum Master and (Development) Team.
- The Product Owner takes the view of customers and other stakeholders and describes their requirements for the product in what is known as the “Product Backlog”. During continuous discussions, this individual weighs up the various interests and decides which of the ever-changing wishes and requirements are most important. Staying with our example for a moment: The Product Owner gathers the various wishes and requirements of (potential) users and other stakeholders of the new online offering, and updates and coordinates them on a continual basis. Another important task is to formulate and repeatedly explain the “why”, that is the vision behind the product, for example with an elevator pitch. The Product Owner is responsible for the project’s three central factors: Quality, costs and time.
- The Scrum Master possesses an expert knowledge of Scrum. This person supports the team to ensure its adherence at all times to the Scrum principles, to design the process in an optimal way and to achieve the set goals. Further tasks include moderating team meetings and helping to overcome difficulties and blockades. This individual also trains project participants, in order for them to be able to fulfil their designated role.
- The Development Team typically consists of five to nine people from different disciplines. It determines which tasks are to be carried out and maintains a shared responsibility. Even within the team, the distribution of tasks is self-organised. If, for example, a learning partner exchange is to be set up for the new online offer, the team defines what work is required for this, following which the members then divide it among themselves. The group goes on to develop and supply the product. It determines the amount of work it can handle itself. In return, the team is responsible for the quality of the delivery.
The Scrum Process: Precisely defined from start to finish
Initially, a product vision is described as a long-term plan, the “Product Backlog”, where all the wishes and requirements are recorded as “Items” (task blocks to be completed) in a list. Using the example of the new online offer to be created, the Product Backlog would thus contain the long-term task list for the project’s realisation. This list is then continuously refined and supplemented in the course of the project. The tasks are often described in the form of user stories (German). The Product Backlog is first and foremost a means of communication with the aim of ensuring that everyone involved understands which tasks are pending and why. It is managed by the Product Owner.
The detailed plan (“Sprint Backlog”) is created at the beginning of each Sprint as part of the Sprint Planning process. From the prioritised Items contained in the Product Backlog, the team selects those that it currently considers feasible. In Sprint Planning, the following questions are clarified. Firstly: Which parts (Items) from the Product Backlog should be addressed in this Sprint? Secondly: How does the team distribute the work and what can they deliver at the end of the Sprint? The Sprint Backlog thus represents a list of those task blocks that are processed in the Sprint, using the example of which tasks are completed in the next two weeks, in order to implement the learning partner exchange that is to be completed by the end of the Sprint.
To keep track of the progress in the Sprint Backlog during a Sprint, a Scrum Board or Task Board is usually used for the purpose of visualisation. This makes it possible to see at any time which tasks are to be processed and what their processing status currently is. The Task Board is often a Kanban Board.
All work progress is documented in short daily stand-up meetings (“Daily Scrum” or “Daily Stand-up”) held by the team, obstacles are identified in good time and any cooperation is discussed. During a Sprint, potentially deliverable products – such as homepage functions or visualisations – are implemented. A Sprint, therefore, represents a good risk management strategy, because in every Sprint a functioning sub-project is created that is good enough to go into production.
At the end of each Sprint, the Development Team shows the Product Owner and other stakeholders the results and receives feedback. In our example, the team would present the partner exchange after the two-week Sprint. After the feedback, the Product Owner decides whether it will be put online directly. In the subsequent Sprint Retrospective, the Development Team withdraws and reflects on the work process and cooperation, in order to constantly ascertain sources of potential improvement. The Scrum Master assists to ensure that the set rules are followed and obstacles are overcome. Methods suitable for a retrospective include „Mad, Sad, Glad“ or a Timeline (German).
Scrumademics: Scrum for individual tasks in research
Scrumademics (PDF, German) is a special modification of Scrum for scientists – and could, in principle, also be transferred to other areas. What makes it special: There is no real team, no joint project, no “customers”. Instead, each team member drives its own project (for example doctoral thesis, professional article) and is, therefore, Product Owner and Developer simultaneously. The role of the Scrum Master is assumed by team members in rotation.
Each team member creates its own Backlog in which all products are listed until the project’s completion. Using a common Digital Board (such as Trello) the team records in lists what is currently being worked on and what still needs to be done. These lists are compiled from the individual Backlogs of all team members. To ensure clarity, each team member is assigned a colour.
Scrumademics is also a vivid example of the contribution made by agile working to dealing more effectively with the consequences of the COVID-19 crisis (German).
Digital tools facilitate Scrum projects
A whole range of apps and other tools can support the implementation of Scrum. They can be used, for example, to maintain Product Backlogs and Sprint Backlogs, to keep track of work progress and to support the Daily Stand-ups. These tools include
Digital tools with no particular focus on Scrum can also provide valuable support. Whiteboard systems such as Miro, Mural and NexBoard comprise templates for agile working, for example, for Daily Stand-ups and Retrospectives.
First steps with Scrum
If you want to start your first Scrum project, carefully consider which project is suitable in advance. The first steps might then be, for example:
- Finding a Product Owner with enthusiasm for the envisaged product,
- Writing a Vision Statement,
- Creating an initial version of the Product Backlog,
- Searching for a Scrum Master,
- Ensuring support from management,
- Putting together a Development Team,
- Clarifying the product and Product Backlog requirements together with the team.
Additional ways to get started with Scrum can be found here:
Promote openness with the transparency of Scrum
Scrum, with its relatively rigid framework and the requirements stemming from different roles, is not suitable for every project. Derivations such as Scrumademics show, however, that it is also possible to apply Scrum when modified for your own context. Do you think your project is suitable for trying out Scrum in its purest form? Then you should hold on to the project management method for a while. Only then should you start to adapt Scrum for yourself.
If you don’t want to start with a complete Scrum project, you could take over parts of Scrum for yourself and get into agile work. Meaning that you could start with small steps like Project Boards, Daily Stand-ups, focused work phases or Retrospectives. With these small structural interventions, you can create greater transparency, promote exchange and improve cooperation.
Scrum offers an interesting project management approach to deliver innovation. With its iterative approach and the transparency of (interim) results, Scrum is also suitable for promoting the openness of Open Science projects themselves. What should always be considered: If methods and tools are applied without reflection, this does not necessarily lead to successful agile working. Success stands or falls with the team members and with the motivation, discipline and communication needed to overcome obstacles.
This might also be of interest to you
- Tool collections: Choose the right tools for digital collaboration and learning
- Libraries and online events, Part 3: How online workshops encourage new ideas and cooperation
Birgit Fingerle holds a diploma in economics and business administration and works at ZBW, among others, in the fields innovation management, open innovation, open science and currently in particular with the “Open Economics Guide”. Birgit Fingerle can also be found on Twitter.
Portrait, photographer: Northerncards©
Wikimedia 2030: Mit Bibliotheken zur größten Wissensinfrastruktur der Welt
Das internationale Wikimedia-Movement, das vor allem für ihr Community-basiertes...