Hi, welcome to this lesson where we will look at the basics of Scrum.
What content does this lesson describe?
We’ll talk about in the next few minutes:
- the definition of technical terms that are important for understanding this lesson,
- the history of its origin,
- the Knowledge Spiral or the SECI Model,
- we look together at how the method has evolved over time,
- and which foundation underlies this development,
- we will very briefly go into the basic values and principles,
- consider a nice overview called Scrum 3-5-3,
- then recognize the core of Scrum,
- and the goals derived from them,
- we talk about implementation techniques,
- and – please don’t laugh – how we eat an elephant,
- we go into the 3 supporting pillars of Scrum,
- look together at the Scrum Boards for the Product Backlog and the Sprint Backlog,
- and, at the very end, address our conclusion from the content of this lesson.
In advance, again the definitions for a whole range of technical terms in this lesson. Almost all of these terms will be discussed in detail in later lessons, so here is just a brief explanation to help you understand the basics from this lesson without any problems:
What is a framework?
In contrast to a method, a framework only provides a manageable framework, which is then individually supplemented with suitable implementation techniques. In addition, a framework is usually built on a method.
What is Lean Management?
Lean management aims to eliminate and harmonize all work steps that are not absolutely necessary and to reduce inventory and thus “dead capital” in order to be able to operate more flexibly, faster and more cost-effectively.
What is an interdisciplinary team?
An interdisciplinary team includes team members with many different skills and experiences necessary to achieve goals. In the area of software development, for example, these would be team members from programming, project management, delegates from the specialist departments or contact persons for machines, systems and IT infrastructure. The team members from an interdisciplinary team often come from different companies.
What is a product owner?
The product owner is responsible for the product to be developed and usually comes from the department for which the solution is being developed.
What is a Scrum Master?
The Scrum Master is the caretaker and advisor in the project team when working agilely according to Scrum. His role includes meeting timelines and functional objectives. He discovers optimization potentials and obstacles in the project process and implements solutions with suitable measures – often also with budget and personnel responsibility.
What is a Daily?
The Daily – also called Daily Standup or Daily Scrum Meeting – describes a daily short meeting of the whole project team, where each team member briefly describes what they have done since the last Daily, what they plan to do until the next Daily, which unsolved problems still exist and how problems could be solved in the last period.
What is a Product Backlog Refinement?
During product backlog refinement, it is checked whether pending requirements are complete and coherent, which skills and tools are necessary for implementation, whether and which dependencies exist with other requirements, and what effort is associated with each individual requirement. Requirements are also broken down into tasks.
What is a Sprint?
A sprint describes the firmly defined time frame in which a solution is actually implemented. In the field of software development, this is the programming or implementation of the requested functionality. The time frame is between 1 week and 4 weeks and is always the same over the course of a project.
What is a Sprint Review?
In a sprint review, the implemented solution is presented to the client and ideally accepted by the client. Sometimes the acceptance is delayed or the solution is not accepted and has to be improved.
What is a Retrospective?
The retrospective – or retro for short – is an important means of self-organization in the team and takes place after each sprint. During the retro, all team members openly name the good and bad events from the past sprint and ideally propose solution options for them. Retro has the goal of constantly optimizing the project process.
What is a Product Backlog?
The product backlog includes all requirements that are not yet being implemented and have not yet been implemented. The product backlog is managed by the product owner.
What is a Sprint Backlog?
The sprint backlog includes all requirements that are currently being implemented. The Sprint Backlog is managed by the Scrum Master in collaboration with the Implementation Team.
What is a Product Increment?
A product increment contains the result from one or more sprints. One or more product increments are delivered to the customer in one release.
What is iterative?
Iterative means approaching the solution step by step in repetitive loops.
What is incremental?
Incremental means to revise intermediate solutions building on each other until the solution result meets the expectation of the requirement.
What is a Defect or Bug?
A defect is a bug or functionality that has been requested but not yet fulfilled.
What is a Burn Down Chart?
The Burn Down Chart is a diagram that shows how far a team is within the target corridor within a sprint, whether it is behind schedule or even ahead of schedule and can therefore pull more requirements into the sprint.
What is a Ceremony?
In Scrum, a ceremony describes a firmly scheduled and recurring activity in the team. In English, they are also called events.
But now to the topic – Scrum:
Why is Scrum called “Scrum”?
Unlike the Kanban method discussed in the last lesson, Scrum originated in software development. The word “Scrum” describes in English the term “scrum” in rugby and thus excellently illustrates the complexity common in software development, the scramble between time, budget, quality and functionality as well as the networked collaboration and unpredictable challenges. In addition to organizing complex and unpredictable tasks, the Scrum framework has integrated basic lean management so that work results are achieved in an efficient manner. Scrum is therefore also used beyond software development in other industries as an organizational framework.
When and how did Scrum come into being?
Scrum first emerged in the early 1990s and is based on fundamentals of the knowledge spiral, the SECI model, developed by Professor Hirotaka Takeuchi and Professor Ikujiro Nonaka. In this context, the SECI Model is the “counter-design” to the unidirectional command and control concept common in Japan as the most common form of organization, in which there are clear instructions but no expectation of feedback, no self-responsibility and also no creativity. In contrast, Scrum relies on highly qualified, interdisciplinary teams that are given a clear goal but have to find their own way to reach it. Only then do the teams have the creative scope to create something completely new and better – and also to constantly optimize their own team organization.
Who developed Scrum?
Jeff Sutherland took up this suggestion and implemented it accordingly in his role as project manager, so that he henceforth assumed a moderating role rather than that of a manager. He has delegated much of his responsibility to his team members. He formulated his practical experiences together with Ken Schwaber starting in 1993. In 1995, the first conference paper on Scrum was published. Scrum, by the way, is a term that was already coined by Hirotaka and Nonaka. The first book about Scrum was written by Schwaber and Mike Beedle in 2002. Beedle was also a practical user and was thus able to contribute his practical experience to the further development of the Scrum framework.
While Scrum only covered software development in 2002 (book title: Agile Software Development with Scrum), the method was extended to general project management in 2004 (Agile Project Management with Scrum) and to enterprise management in 2007 (The Enterprise and Scrum). Already since 2006 Scrum is the most common agile organization form according to the annual VersionOne survey.
What are the basics of Scrum?
The foundation of Scrum is the novel form of knowledge management. While until today it is usually assumed that knowledge is formulated, written and thus made teachable, the SECI model and also Scrum assume that this written and orally transmitted knowledge is only the tip of the iceberg. The majority of the knowledge is imparted and passed on in accordance with the SECI Model and Scrum during personal interaction in the team and learning-by-doing – quite apart from books, instructional films and lectures. Scrum shares the 4 core values with the Agile Manifesto, which has been around since 2001 and was co-authored by Ken Schwaber, Jeff Sutherland and others, and which we have already covered in a previous lesson, like the 12 principles.
What is the Scrum 3-5-3?
The core of Scrum based on agility can be defined with a few rules. We have
- 3 basic roles (namely the Product Owner, the Scrum Master and the Team).
- 5-6 basic events (namely the Daily, (a Backlog Refinemnet if necessary), the Sprint Planning, Sprint, Sprint Review and the Retrospective).
- and 3 so-called base artifacts (the Product Backlog, the Sprint Backlog and the Product Increment)
This is why this core is often called the 3-5-3 of Scrum.
Attached to this lesson you will find a PDF in A3 format with the Scrum 3-5-3. Feel free to print it out and hang it on the wall in your project room as an overview for the team.
What is the advantage of Scrum 3-5-3?
This core is fixed and can be found in every Scrum project. This fixed core guarantees that new team members quickly find their way around and that the wording as well as the basic organization are uniform and thus unambiguous. This core brings something else to light: With Scrum, it is impossible for any team member to hide their own weaknesses. The Scrum tools expose everything and therefore transparency and openness are not just theory with this form of organization. The goal of Scrum is that knowledge is shared within the team and therefore each team member grows with their tasks.
In addition, there are extensive implementation techniques. These implementation techniques can be used flexibly, depending on the need and challenge. Scrum techniques are field-tested, they avoid problems and show working ways to solve them.
What does iterative work with Scrum look like?
In Scrum, all participants are aware that the development project is too complex and too unpredictable to plan. This challenge can be solved by dividing the overall project into many small intermediate steps. On the basis of the resulting intermediate results, new intermediate goals as well as solutions for them can be found. Not only is the product developed iteratively and incrementally in the long-term “Product Backlog”, but the detailed planning of the “Sprint Backlog” is also defined only for the next cycle in each case. Thus, the project remains flexible and grants the freedom for constant optimization and solution finding. One or more sprints then lead to a “product increment” – the work result. The goal of Scrum is also to deliver a subsequently improving usable work result to the customer as quickly as possible – in contrast to waterfall models, where the work result is often made available to the user late in the course of the project, because the entire agreed functionality and quality should be available in it.
What are the 3 pillars of Scrum?
We can also describe the 3 pillars of the solution for too much complexity and unpredictability as follows:
- Transparency: Progress and obstacles are recorded regularly and visible to all – e.g. in the Dailies and on Scrum Boards
- Review: Project results are delivered and evaluated regularly – e.g. with the help of Sprints, Sprint Reviews and new releases based on one or more Product Increments
- Customization: Requirements are captured but are subject to constant re-evaluation by the customer and the Scrum team. Now pay attention please: The same applies to project organization and planning for time and budget.
What is a Scrum Board?
Key point Scrum Boards: we have learned fundamentally in the previous lesson how Kanban Boards look like as an organizational tool and how to use them. In Scrum, there are Scrum Boards for the same purpose, but they are fundamentally different.
What does the Scrum Board for the Product Backlog look like?
The Scrum Board for the Product Backlog focuses on prioritization and maturity of a task. In this example, immature operations accumulate in the light boxes with high numbering, maturing operations move to the darker regions, and the number of a box indicates the order in which the operations are drawn for processing.
The Scrum Board shown here is mainly used for organizing the Product Backlog, but depending on the project, it can also be expanded to include other boards, e.g. for the Customer Backlog, if the product owner is based outside the company. However, the Scrum Board for the Product Backlog can also be divided according to requirement types, so that customer requirements, infrastructure requirements, defects and additional requirements for standard software used are handled in separate Scrum Boards. Depending on the challenge in the project, the organizational tools can be selected and also subsequently adapted in such a way that the real workflow is mapped transparently and in a quality-assuring manner.
What does the Scrum Board for the Sprint Backlog look like?
For the organization of the sprint, Scrum uses the Scrum Board shown here – where the columns can be adapted to the real workflow. Personally, I like to include the internal Sprint Review – and where necessary also the documentation, before a process can be set to Done. If a manual Burn Down Chart is maintained, then it even makes sense to add a burned column after the done column – this makes it easier to maintain the Burn Down Chart. You see: the implementation techniques are defined, but flexibly adaptable to the needs.
How are tasks passed from one Scrum Board to the next?
By the way, the step from one board to the next takes place within fixed ceremonies, such as Backlog Refinement and Sprint Planning, where at least the respective Backlog Owners must always be present.
We could now continue at this point with the individual core elements and the implementation techniques, and thus gain a broad understanding of Scrum. However, since Scrum is the backbone, so to speak, of an agile software development project in large companies and almost all Scrum components are indispensable in it, I would like to go into it only after all the basics have been taught – but then also take it apart comprehensively, critically and situationally.
Can Scrum reduce complexity?
I would like to conclude this lesson with the insight that Scrum is “not” able to reduce the complexity or the unpredictability of a project. But Scrum is able to structure these challenges into smaller increments in such a way that they become manageable and solvable – and with astonishingly high efficiency.
Now let’s summarize what we have covered in this lesson:
- we got to know a whole latte of new technical terms,
- as well as where and how Scrum originated,
- you now know what is behind the Knowledge Spiral or the SECI Model,
- and how Scrum has evolved over time,
- what foundation this development has,
- we now also know that Scrum shares core values and principles with Agile,
- we have basically learned all the components of Scrum 3-5-3,
- and can therefore already recognize the core and the derived goals of Scrum quite well,
- we now know that there are implementation techniques, even if we will only go into more detail about them in the course of the course series,
- and of course we now know how to eat an elephant, or how to divide up unmanageably large tasks so that they become feasible,
- we have also become aware of the 3 pillars without which Scrum cannot work,
- we have learned the differences between Kanban boards and Scrum boards,
- and hopefully it is clear to us by now that Scrum cannot work miracles, but it can make seemingly insurmountable work much easier.
In the next but one lesson, we will start with the Scaled Agile Framework, a somewhat more extensive topic that will be spread out over a few lessons in a well-structured manner. But before that, there is a small, but also a big surprise for you:
The following lesson includes a short quiz that allows you to check for yourself what content from this lesson has stuck with you. In the lesson following the quiz, you will take the first practice test, in which we will review the learning content from all the lessons covered so far. In contrast to the quiz, several to all answers can be correct in the practice test. You always have more than enough time for the practice tests, so there is no time pressure. You can also repeat the test as many times as you like until you reach the required minimum goal of 80%. Exactly this intensive occupation with the learning content consolidates your newly acquired knowledge. I wish you a lot of fun with it, see you again after the practice test!
