Discuss your project with us:
01 What you get from us
Our service areas at various levels:
Whether for you individually, your team or your organization - we get involved with you, get a picture of the situation together with you and jointly derive the appropriate goals and measures for you and your situation. The following overview should give you an idea of the direction this can take.
Individual
Team
Organization
- AGILE COACHING & CONSULTING
1. typical problems/symptoms in the customer context:
Teams or other organizational units are stuck, do not achieve their goals and repeatedly encounter organizational or individual obstacles. Dissatisfaction spreads within the team and among managers.
2. our interpretation/analysis:
The causes of these problems often lie in insufficient communication and transparency, a lack of trust, false expectations, complex requirements, inadequate prioritization and conflicting goals.
3. possible alternative solutions:
Our agile coaching and consulting activities are aimed at ensuring performance. Depending on requirements, we focus on individuals, individual teams or the entire organization. In this context, we see ourselves as a mixture of trainer, consultant and coach, depending on which is needed more.
- MANAGEMENT DEVELOPMENT
- CULTURAL DEVELOPMENT
1. typical problems/symptoms in the customer context:
Employees are often promoted to managers without adequate preparation for the challenges of leadership. This leads to employees feeling poorly led and possibly leaving the organization.
2. our interpretation/analysis:
Self-knowledge is crucial in order to lead others effectively. Leadership development involves improving one's own thinking and actions as well as clarifying one's own role. In addition to professional skills, it is important to motivate employees to develop their potential and convey the right values.
3. possible alternative solutions:
We offer individual coaching, consulting and mentoring measures for managers. These can take place over a longer period of time in order to accompany the development of managers through dialog and achieve their development goals. In addition, we develop tailor-made learning programs and implement them for specific target groups.
1. typical problems/symptoms in the customer context:
In change processes, cultural development is sometimes neglected and old traditions and habits are often retained. In hierarchical cultures, for example, it can be common for every decision to be approved by the boss first. This can slow down processes and restrict the autonomy of employees.
2. our interpretation/analysis:
Culture is often difficult to grasp and changes in culture take time. Rituals do not change overnight and those affected must be accompanied on this path of change in order to cushion relapses into old cultural practices. Often only behavioral changes are sought without addressing the underlying beliefs. This approach does not enable sustainable change.
3. possible alternative solutions:
Putting this into practice requires an adapted approach. Organizational and team cultures can be changed in a targeted manner through interventions and the introduction of new methods. Change processes are implemented at various levels of the culture in order to promote the desired development. We use the dimensions of "system", "behavior" and "beliefs" to make culture visible and apply our "Micro Change Cycle" approach to bring about the desired changes. Further information can be found on our PatternBreakers website.
- SYSTEMIC COACHING
- TEAM DEVELOPMENT
- ADAPTIVE ORGANIZATIONAL DESIGN
1. typical problems/symptoms in the customer context:
TIn many organizations, feedback meetings only take place every six months or annually. However, this alone is often not enough to help employees reach their full potential. Inefficiencies and demotivation are often the result of insufficiently strength-oriented personnel development.
2. our interpretation/analysis:
Coaching is an effective support for employees who frequently need to adapt to changing environments in order to fully develop their energy, innovation and commitment. Unlike feedback, which provides information about past behavior and performance and suggests possible adjustments, coaching has a preparatory approach to solving challenges. In addition, systemic coaching also includes the system and its fields of action in the reflection.
3. possible alternative solutions:
Systemic coaching is a problem- and solution-oriented method for supporting people with a self-determined issue and moving them from a deficient situation to a resourceful target state. Our experienced coaches support employees using selected methods in confidential 1:1 coaching sessions or as a team.
1. typical problems/symptoms in the customer context:
Teams can face different challenges that cause dissatisfaction and performance degradation. For example, one team aims to develop a new product quickly and disruptively, while another team aims to reduce costs and set new standardization requirements. This leads to uncertainty in prioritization and impairs collaboration between the teams.
2. our interpretation/analysis:
These symptoms are often caused by conflicting goals, rigid processes, a lack of trust, false expectations and a lack of communication and transparency.
3. possible alternative solutions:
Initially, we sensitize the people pursuing these different goals to the conflict and offer them advice on possible solutions. As part of team development, we also aim to improve cooperation within and between the teams. By regularly reflecting on cooperation with the teams, we can tackle challenges, derive suitable measures and anticipate future problems. We also promote communication and transparency as well as the definition of common goals through various formats such as workshops and retrospectives.
1. typical problems/symptoms in the customer context:
In your organization, there is no clear allocation of tasks in the development of products. Decision-making processes are long, communication between departments is limited and product changes are slow. Innovation development is a challenge. The competition, on the other hand, can react quickly and bring innovative products to market. These internal challenges lead to demotivation among employees, higher staff turnover and loss of sales.
2. our interpretation/analysis:
The causes of these symptoms are often rigid processes and hierarchies, complex problems and requirements as well as inadequate prioritization and conflicting goals between the various organizational units.
3. possible alternative solutions:
Adaptive organizational design is an interplay of different performance areas. Our aim is to create an organizational structure and working methods that allow us to adapt quickly to changes and achieve sustainable competitive advantages. By identifying value streams and using agile methods, we support our clients in the organizational mapping of these value streams, the establishment of decentralized decision-making processes and the breaking down of hierarchies. This enables them to better deal with the complexity of an issue while maintaining focus and transparency.
- BELIEFS & PATTERNS
1. typical problems/symptoms in the customer context:
During agile transformations, we often see that employees and managers fall back into old patterns of behavior. For example, they have difficulties prioritizing, focusing or delegating tasks. As a result, the benefits of agile working remain untapped and problems such as ignorance, confrontation or frustration arise.
2. our interpretation/analysis:
When it comes to change, leverage is often applied primarily to behaviour and the systemic view of the organization and existing convictions are neglected. Without the right leverage, the desired effect loses its power and employees and managers fall back into old patterns.
3. possible alternative solutions:
In the first step, we create transparency and try to make culture visible through the dimensions of "system", "behavior" and "beliefs". In the second step, we identify the right levers to bring about change and implement it sustainably using our "Micro Change Cycle" approach. We share our experiences on our PatternBreakers website. There we provide inspiration for behavioral patterns, beliefs and interventions that you can test directly in your environment.
- CHANGE MANAGEMENT
1. typical problems/symptoms in the customer context:
New strategies, structures, processes, working methods, IT systems or management principles are being introduced or adapted within the organization. Previous change projects may have already failed. The current change project is encountering resistance and frustration is spreading.
2. our interpretation/analysis:
Employees and managers are often not sufficiently informed and involved in upcoming changes. They do not understand the need for change. The target image is unknown, making it difficult for them to recognize their individual value contribution. In addition, implemented measures often do not meet the actual needs of employees.
3. possible alternative solutions:
The success of change depends largely on the acceptance and development of employees. With the help of our Change Management approach and low-threshold "micro changes", we support organizational change in a needs-based and adaptive manner. For the individual engagement and enablement measures, hypotheses and the desired effects in the organization are defined in advance and then measured. Based on the measurement, we learn and adapt for the next cycle (micro change).
- PURPOSE-DRIVEN WORK
1. typical problems/symptoms in the customer context:
Employees or teams are not aware of why they perform their tasks in the organization and what their work results contribute to. They lack a sense of purpose and direction in their work, which results in dissatisfaction, demotivation or high staff turnover.
2. our interpretation/analysis:
Poor communication, a lack of transparency and a lack of focus on strengths are often the causes of ambiguity and an incomprehensible target image.
3. possible alternative solutions:
To remedy this, we work with our customers to develop an overarching purpose and an easily understandable target image for employees. In this way, the question of "why" is answered clearly and simply for everyone. To ensure that the purpose is successful in the long term, we check after the introduction whether it really fits the organizational structure and make changes if necessary.
- VALUE STREAM MAPPING
1. typical problems/symptoms in the customer context:
Customer satisfaction is low, the interaction between teams or organizational units does not work or only works poorly, employees complain about long waiting times and delays or dependencies are unclear.
2. our interpretation/analysis:
These symptoms are often caused by a lack of product or service orientation and transparency regarding the flow of activities, information and materials from the customer request to the finished product or service. Employees do not feel responsible end-to-end.
3. possible alternative solutions:
With a value stream mapping, we pursue the goal of making all work and activities that are necessary to fulfill an order transparent. The value stream begins and ends with the customer - internally or externally. This method is powerful in identifying waste or delays in the process. Our experience shows that the strength of value stream mapping lies in deriving and implementing incremental improvement potential, such as changing team cuts or adapting interfaces.
Discuss your project with us:
02 What working with us looks like
We are passionate about working together.
We bring the wind to our customers at
.
We design adaptive
organizations.
We create impact by finding and setting the right course.
We move our customers and ourselves into the flow together.
Experience + hypotheses + experiments = valid results. Repeat!
The AMPlifier at a glance since 2021
79 projects in various industries since the AMPlifier team was founded
12 different certifications in the areas of agile and change
12,847 Lego bricks used during customer workshops
3 Cooperation with strategic partners
70% of our customers are repeat customers
On average 5.1 years of experience in the areas of agile and change
03 How we have solved customer problems in different industries
Reference Case 1 - Automotive
- Value stream mapping - Adaptive organizational design - Agile consulting
Reference Case 2 - Telecommunications
- Leadership development - Team development - Agile coaching
Reference Case 3 - Information and communication technology
- Leadership development - Beliefs and patterns - Cultural development
Reference Case 4 - Information and communication technology
- Adaptive organizational design - Value stream mapping - Agile consulting
Reference Case 5 - Energy industry
- Cultural development - beliefs and patterns - Change Management
Reference Case 6 - Telecommunications
- Change Management - Cultural development
Voices of our customers
customers."
The procedure was very structured and methodically sound."
which I hadn't even seen."
I've never experienced that in consulting before."
Discuss your project with us:
04 How we come into contact
Do you have a problem to solve? We are the right contact for you for problems such as
PURPOSE-DRIVEN WORK & TEAM DEVELOPMENT
Problem area 1:
"What are we doing all this for anyway?"
Do you have questions about purpose-driven work & team development?
VALUE STREAM ANALYSIS & ADAPTIVE ORGANIZATIONAL DESIGN
Problem area 2:
"Conflicting objectives"
Collaboration between teams is hindered by rigid processes and conflicting goals. Team 1, for example, is pursuing the goal of disruptively developing a new product. Team 2 wants to save costs and sets new requirements to achieve this.
Do you have questions about value stream mapping & adaptive organizational design?
MANAGEMENT DEVELOPMENT
Problem area 3:
"Decision shyness"
Employees too rarely make decisions themselves. This is because mistakes are career killers. In addition, new topics are constantly being initiated without previous ones being completed. When things are prioritized, "everything has priority 1".
Do you have questions about leadership development?
BELIEFS & PATTERNS
Problem area 4:
"How can I break through old patterns of behavior?"
Do you have questions about beliefs and patterns?
We look forward to getting to know you and your situation!
05 FAQ
01 What does agility mean for us?
Agility stands for the ability to react quickly and appropriately to a complex and dynamic environment, often in the form of customer requirements. Agility therefore means flexibility, or - quite simply: liveliness.
Agile companies have understood that they are operating in an increasingly complex environment and therefore have to adapt to new conditions at an ever faster pace. In response, they reflect the dynamics of their environment in their own organization - and in some cases even manage to make the market itself more dynamic. This is often characterized by a strong customer focus, short, iterative planning and development cycles, flat hierarchies and a high degree of self-organization.
Why do we think agility is important?
Many companies are currently feeling the pressure of an increasingly dynamic market environment in which it is important to remain competitive:
01. Digitalization enables disruption, which displaces existing technologies, products and services from the market in a very short space of time. New players are challenging established companies. If accumulated knowledge and company size do not create a lasting competitive advantage, innovation and agility gain enormous importance.
02. The increasing number of uncertainties in the market environment inevitably increases the speed at which companies have to make decisions and adapt to changing conditions. The ability to plan is decreasing: in the past, projects could be planned and rolled out in a waterfall-like manner over several years, but now short, iterative cycles are sufficient - the shorter the better.
03. The perception of one's own contribution to the company's value creation is increasingly becoming a key motivational factor for employees. External control and a lack of self-efficacy destroy motivation and drastically reduce agility and innovative strength.
02 What is the Agile Manifesto?
03 What do we mean by agile transformation?
Definition and meaning of "agile transformation"
The term "agile transformation" describes the path from a traditional organization to an agile organization, i.e. an organization that follows a whole range of agile principles in product development and service provision in order to survive in the VUCA world. The agile transformation is a change process that companies do not go through overnight. This is because working in a truly agile way as an organization requires far more than just methodological expertise and shorter planning cycles. Much more decisive are the framework conditions under which value creation takes place in the company. They determine what behaviour is opportune and when, what demands the organization has on its employees and what limits must not be exceeded.
Why do agile transformations fail?
It is often precisely these framework conditions that become a critical success factor and cause many agile transformations to fail. Structural elements such as reporting and approval processes, control and planning apparatuses or internal performance incentives and evaluations can either hinder agile value creation or make it possible in the first place. They are the greatest lever for breaking up and reconnecting the fusion of value creation and the values and principles of an organization. In order to understand how this can be achieved, a fundamental realization must be made first:
At the heart of an agile transformation are not methods or frameworks, but first and foremost values and principles that govern collaboration.
This is because every single one of the well-known, much-publicized agile methods was created by consistently applying these values and principles to a specific business case - be it SCRUM for project work, Kanban for the service sector, Lean Startup for testing new business ideas. Visualization and estimation techniques such as burn-down charts or planning poker followed.
Unfortunately, agile transformations too often focus on these methods and techniques instead of starting with the values and principles. However, any method - no matter how popular - can only be successfully applied by an organization if it follows the same agile values and principles on which the method is based. If this is not the case, the application will not only be ineffective, but in the worst-case scenario, it will cause damage. The values and principles that guide an organization's actions are in turn enshrined in its culture, which determines behaviour and guides decisions with an invisible hand. When we talk about sustainable agile transformation, we automatically mean cultural transformation. Agility therefore does not start with post-its, squads, sprints and hackathons, but with values and principles and a critical look at the organization's own culture.
Step by step to an agile organization Culture is the memory of the organization.
It is their immune system that tries to ensure the survival of the organization in the future by replicating what was successful in the past. Culture is reflected in the organization: in processes, organizational charts and rules that have emerged as helpful over decades. It is not enough to proclaim new values and wallpaper the corridors with posters to bring about lasting change in an organization's culture - just as it is of little help to use a teleprompter to get the audience to show authentic enthusiasm at a concert with a bad atmosphere. Even if even the last employee is convinced of the effectiveness of agile values and principles, the processes and structures of the organization often act like a layer of clay. Only by specifically questioning processes, decision-making rules, organizational charts, etc. can the previous framework conditions for collaboration be analysed in small iterations, changed in a targeted manner and the agility of the organization increased. Each iteration makes it possible to gather new experiences that become part of the cultural memory and lead to lasting change.
1. identify patterns
An iteration begins with the question of the value creation mission and where the current organization is hindering this. In the first step, we observe the collaboration in order to recognize critical patterns and thus identify starting points. This can be illustrated using a swing: In order to speed up or slow down a child that is already swinging with the desired effect, the first step is to observe the pattern in which the swing swings. Only then can the push be applied in the right place and at the right time to increase or reduce the swing as desired. In the same way, we first observe and analyse the existing organization and its patterns. Example: A client's HR department has two value-adding tasks. Firstly, it is responsible for administrative tasks such as contracts, certificates, the onboarding process, etc. On the other hand, individual personnel development measures are to be designed. Internal customers have repeatedly been dissatisfied with the latter in the past. The employees in the department are used to leaving decisions to their formal manager once they reach a certain level of importance. In our observations, it is noticeable that, due to their formal decision-making authority, managers have become a strong second point of reference in the daily work of employees alongside the actual customer.
In the next step, we relate the identified pattern to the value creation task and form a hypothesis as to what influence the organization has on value creation. We look for a reason why the work does not succeed as intended. In our example, we recognize that the employees develop personnel development concepts that primarily correspond to the manager's vision. As a result, the customer focus fades into the background and the added value of the concepts suffers. We hypothesize that without formal power structures, this part of value creation would be more customer-centric and thus produce better results.
3. breaking patterns
Based on the hypothesis, we look together for a suitable lever to break the recurring pattern. This involves an organizational intervention, a kind of experiment in which new things are tried out for a predefined period of time and different experiences are gathered. This is the only way to change mindsets and convictions - with a direct impact on the underlying culture. Targeted irritation of the existing organization is needed to enable sustainable change. In our example, we irritate the existing organization of the department by almost completely eliminating the influence of the manager for the period of the next conception of a personnel development concept - from order clarification to completion. We limit reporting, give the team full budget responsibility and allow them to make all decisions on their own, without the manager being able to intervene. Their only task is to create the necessary safe space. Both the team and the manager are accompanied by us along the pilot in order to avoid relapses into old patterns of behavior.
4. evaluate the results
Once the experiment has been completed, check what changes have occurred. Did the lever have the desired effect? What of what we tried out do we keep, what needs to be reconsidered or adapted? Could this also be a lever for other areas? Or do we need to test something completely different? In our example, it worked. Despite initial uncertainties, the team reports an effective and efficient collaboration in which they organized themselves independently and focused exclusively on the wishes and needs of the customers. The result is a product that inspires customers and delivers real added value. Important: There are no blueprints or best practices for agile transformations. The successful experiment only shows that the identified lever worked in this particular environment with this particular team. Transferability to other teams and areas always requires a separate hypothesis and a new experiment first - even if experience already gained accelerates the observation process and often significantly increases the accuracy of the hypothesis.
With the Transformation Loop to an agile organization
As the example of our client shows, change presents organizations with complex challenges and it takes a well thought-out approach to meet this challenge. Converting an organization to an agile organization therefore means uncertainty and must be done holistically in order to generate the full effect. Our iterative approach, based on experimentation, enables incremental improvement. Nevertheless, we need a structured approach to maintain an overview and recognize successes. The following both structured and iterative approach allows us to do just that and is able to respond to evolving transformation conditions: The Agile Transformation Loop. The Agile Transformation Loop describes an approach based on Scrum, enriched with aspects from our many years of Change Management experience. This approach is made up of successive phases and is based on a continuous learning and development process that provides a structured framework for the iteration "recognize patterns - form hypotheses - break patterns - evaluate results".
Preparation of the agile transformation process
In order to initiate the agile transformation, structural groundwork is required. The basis for this is initially formed by the steps "Identify patterns and form hypotheses" in order to analyse the existing organization and its patterns. These patterns are set in relation to the value creation mission so that we can derive hypotheses, which in turn lay the foundation for the transformation backlog. The transformation backlog can be thought of as an indicative list of points to be addressed on the way to an agile transformation. In addition, of course, a team is needed to drive the agile transformation in the company. We rely on a transformation team consisting of different roles. The main sponsor acts as the transformation owner, the voice of the customer "organization", and is overall responsible for the transformation. He is supported in particular by the Transformation Master, who accompanies the team and indirectly the transformation project in terms of process. Together, they support the Transformation Core Team in implementing the various steps on the path to an agile organization. Furthermore, the transformation process is based on sprints, the duration of which must be clarified in advance. Experience has shown that an iteration of 4 weeks makes sense.
Our consulting approach: More agility through networking and institutionalization
Our consulting projects typically start in a specific area of a company. The best conditions for making the division more agile are given when the assignment and the motivation for change come from the manager responsible for the division itself. Through coaching and operational support, we enable the division's managers to effectively build an agile organization from the inside out and to implement cultural changes sustainably. We also provide comprehensive expertise in identifying value creation levers and enable managers to independently drive cultural change forward step by step.
How can an area-specific, agile transformation become a comprehensive transformation that leads to the entire company becoming agile at its core?
The more seed cells of the agile organization are sown in the company and networked with each other, the more experiences can be shared, lessons learned can be exchanged and common patterns - both desired and undesired - can be identified. With our many years of experience in sustainable Change Management , we have the necessary expertise to promote the corresponding dynamics and develop a self-reinforcing effect.
Many individual agile transformations and the open exchange about them lead to the "hidden rules" and "organizational patterns" gradually being revealed and an agile organization being institutionalized. The culture of the company is not turned upside down in the process. Experience has shown that many "hidden rules" and "organizational patterns" remain stable, while central rules and organizational structures that stand in the way of change and value creation are systematically replaced. After all, agile transformation must never become an end in itself.
First and foremost, there must always be the question of the value creation mandate and which structures and framework conditions are currently hindering this. Genuine value creation is therefore our top priority in every project. After all, what counts in the end is not how many Post-Its are stuck to the wall and how many sprints you have run, but whether the customer pays for the product or service. We are convinced that well-organized value creation that satisfies real customer needs not only brings sustainable economic success, but also gives employees a sense of satisfaction, makes them proud and inspires them. This is what we stand for.
This is precisely why we do not have a blueprint for "the agile organization". What we can offer you, however, is a tried-and-tested approach on how to successfully tackle an agile transformation. Our experience is extremely positive. Whether as a coach, consultant, trainer, co-thinker or co-pilot, we work together to find out what is needed and have all the tools we need to do so.
04 In our view, what does agility mean for managing employees?
Modern managers create an environment in which precisely this innovative energy can flow - so that innovative ideas can emerge within their own company - by empowering employees, promoting a culture of experimentation and learning and actively developing their own management team.
Wie Führungskräfte Mitarbeiter am besten unterstützen
Schaut man sich moderne Organisationen an – seien es holokratisch organisierte oder die von Laloux in seinem Bestseller „Reinventing Organizations“ beschriebenen Unternehmen, kann man sich als Führungskraft durchaus die Frage stellen, wo in diesen Organisationen denn noch Platz für Führungskräfte ist.Zunächst einmal möchten wir eine klare Empfehlung aussprechen, was Führungskräfte nicht tun sollten – und das ist, die Rolle des Product Owners oder des Scrum Masters zu übernehmen. Ein häufiger Fehler bei agilen Transformationen ist, die bestehende Hierarchie einfach 1:1 in die neue Organisationsform zu überführen. Der Product Owner ist weiterhin „der Chef“, der über Priorisierung und Inhalt der jeweiligen Sprints bestimmt. Das Scrum Team ist dann nur ausführende Kraft. So bekommen die Teams modernere Namen – sei es Scrum Team, Squad oder Tribe, nur an der Verantwortung ändert sich nichts. Ganz im Gegenteil. Häufig nimmt die fachliche Verantwortung der Führungskräfte dadurch zu, sie werden zum Flaschenhals und kommen nicht dazu, zusätzlich zu ihren bisherigen Management-Themen (die häufig nicht wegfallen) auch noch die notwendige Zeit für ihre fachlichen Themen aufzubringen. Statt der erhofften Produktivitätssteigerung wird die neue Organisation langsamer und das Thema Agilität ist für viele Menschen verbrannt. Was sollten Führungskräfte also stattdessen tun? Es gibt sie noch, die Management-Aufgaben!
Eine große Aufgabe für Führungskräfte ist, gemeinsam mit ihren Mitarbeitern die Organisation neu zu gestalten und zu entscheiden, welche Aufgaben und Themengebiete überhaupt Agilität benötigen und bei welchen Aufgaben und Themengebieten Stabilität und Prozessexzellenz gefragt sind.
Diese Form der Organisation wird häufig als Organisationale Ambidextrie oder Duales Betriebssystem beschrieben. Tatsächlich ist das ganz logisch – nicht alle Mitarbeiter müssen den ganzen Tag hochinnovativ komplexe Aufgaben lösen. Manche Prozesse müssen auch einfach laufen, ohne dass man sie jeden Tag neu erfindet. Ganz im Gegenteil: Je eingespielter diese Prozesse laufen, umso stärker lässt sich die Effizienz steigern. Diese Prozesse lassen sich dann, wenn sinnvoll, schrittweise digitalisieren. Zunächst müssen sie aber standardisiert und optimiert werden – klassisches Management und eine wertvolle Aufgabe für Menschen, die gerne in stabilen Umfeldern arbeiten.
Befähigung zur Verantwortungsübernahme
Selbstorganisation bedeutet vor allem, Verantwortung für sich selbst, das Team, Entscheidungen und Ergebnisse zu übernehmen. Auch wenn man selbst entscheiden darf, verspüren viele Mitarbeiter das Bedürfnis, sich zusätzlich abzusichern.
Es ist eine zentrale Aufgabe eines Agile Leaders, sein Team zu befähigen, selbst Verantwortung zu übernehmen. Ein häufiger Fehler hierbei ist, von einem Tag auf den anderen die gesamte Verantwortung auf einmal abzugeben – das scheitert meistens, auch weil die Mitarbeiter gar nicht in der Lage sind, alle Entscheidungen selbst zu treffen. Meistens liegen ihnen gar nicht alle Informationen vor, da sie nicht in denselben Gremien sitzen, wie die Führungskräfte.
Eine gute Maßnahme besteht darin, Task für Task mit den jeweiligen Mitarbeitern zu besprechen, inwieweit die Führungskraft noch zu involvieren ist und dies schrittweise zu verändern.
1. So kann die Führungskraft die Mitarbeiter zum Beispiel zuerst nach ihrer Meinung fragen, die Entscheidung am Ende aber selbst treffen.
2. Im nächsten Schritt kann man das umkehren – die Führungskraft teilt den Mitarbeitern ihre Meinung mit, überlässt ihnen aber die Entscheidung.
3. Ein weiterer Schritt ist, nur noch für Fragen der Mitarbeiter zur Verfügung zu stehen, bis diese sich die notwendige Entscheidungskompetenz selbst erarbeitet haben – inklusive der notwendigen Informationsquellen und die Entscheidung nun selbst komplett treffen können.
04. Die Führungskraft ist im letzten Schritt nicht einmal mehr zu informieren – die Entscheidung ist komplett zur Sache der Mitarbeiter geworden.
Wie dieser Prozess von statten geht und wie lange es dauert, die letzte Stufe zu erreichen – und ob diese überhaupt erwünscht und sinnvoll ist – hängt ganz vom jeweiligen Task und den jeweiligen Mitarbeitern ab.
Eine Grundlage hierfür ist natürlich, den Mitarbeitern aktiv alle Informationen zur Verfügung zu stellen, die sie für eine effiziente Entscheidungsfindung benötigen – auch wenn Führungskräfte dadurch keinen Informationsvorsprung mehr gegenüber ihren Mitarbeitern haben. Das kann für diejenigen Führungskräfte hart sein, die bisher einen Teil ihrer Kompetenz daraus abgeleitet haben, einfach über mehr oder andere Informationen zu verfügen als ihre Mitarbeiter.
Schaffen einer angstfreien Umgebung, in der es sicher ist, Fehler zuzugeben
„Aus Fehlern lernt man“, „Fail Fast, Fail Cheap“ – Fehler sind scheinbar modern wie nie. Ist das wirklich so? Zählt am Ende nicht doch nur der Erfolg? Jemand, der jahrelang alles getan hat, damit die Zahlen stimmen oder das Projekt auf „grün“ ist und damit Erfolg hatte, wird nun Fehler nur schwer zugeben – und tatsächlich ist auch nicht jeder Fehler ein Grund zu
Nothing works without a mindset
Lifelong learning and flexibility are paradise for curious people who don't want to be tied down at the start of their careers. But what about those who have grown up for years in systems that rewarded meeting fixed levels of competence? Who promoted those who fitted perfectly into a template? Or at least those who successfully pretended to? Where do I get my raison d'être as a manager if I don't know more than my employees?
The change to an agile corporate structure poses major challenges for managers in particular - not least because agile methods usually do not provide for any explicit management roles. It requires strong self-confidence to embrace this change - and the corresponding Change Management. It is therefore essential to support managers in these areas and not simply try to "teach" them a new management style.
What is changing for managers and how can they get employees on board?
The Change Management is often left out of agile transformations. The need for change seems too clear - who wants to lead like the large manufacturers of the 19th century?
The 21st century? What's more, agile working sounds like a lot of fun - planning poker, fuck-up nights and hackathons are accompanied by modern office design and flexible working. Isn't this the change we've all been waiting years for? Why do we need Change Management? In other words: if it's so easy, why do so many agile transformations fail?
Managers also go through the familiar change curve and react to change with uncertainty. Do I have the necessary skills? What about my area of responsibility, do I have to give up skills? What will my future role as a manager look like? Will my employees continue to respect me? Managers react to change with the same shock and sadness as other employees.
Previous skill profiles provided a clear framework of which skills you had to have for which activities. This certainty is now no longer there, but it also offers the opportunity to finally focus on your own strengths instead of being forced into fixed templates. To do this, however, you need to know who you are, what you can do, but also who you are not and what you cannot do. In many organizations, admitting your own strengths and weaknesses is a completely new way of behaving that can be very unsettling. How much weakness is allowed, at what point do you break the rules of the system in which you still work?
Only when managers have mastered this change for themselves can they accompany their employees through the change and authentically explain what is meant by supposed buzzwords such as "fail fast". In order to embrace the change, they must be able to trust their own managers. It is not enough to simply demand and allow a new understanding of leadership at lower management levels.
Among other things, this requires top management to represent a common change story - and to really stand behind it. Lip service is quickly seen through. Every member of top management must be able to credibly explain why a new management style is necessary, what advantages it brings, what exactly it means for the organization and how the organization will achieve its goal.
1. what does "fail fast, fail cheap" mean for us?
2 What do we mean by innovation?
3. how much time do we take for leadership?
4. how and how often do we give ourselves feedback?
5. how do we deal with the individual strengths/weaknesses profiles of employees?
6 Who is allowed to decide what? Who is promoted and why?
8. what career paths do we offer our employees?
9 What is this agile leadership?
Of course, it is not enough just to have a common understanding - the respective manager - also in upper management - must set a good example, actively apply the new management behavior and receive regular feedback on their management style.
The path to an agile organization thus becomes an exciting journey for everyone involved that offers a lot of opportunities.
05 What are OKRs?
The term OKR stands for "Objectives and Key Results". OKR is a method that creates a link between strategy and day-to-day business. It is primarily made up of the three core elements of measurability, flexibility and transparency. However, OKRs are not a management method.
Measurability
The objectives describe the desired corporate goals. The key results make it possible to make each objective measurable. They describe how an objective is to be achieved.
Flexibility
Objectives and key results are typically formulated on a quarterly basis. This allows companies to define their focus several times a year and adapt to changing conditions at shorter intervals.
Transparency
The company's objectives and key results can be viewed by all managers and employees. The OKRs of each team and each individual employee are then linked to those of the company. Finally, there is clarity about who contributes to the company's success with their objectives and where.
Who came up with OKR? The term OKR is closely associated with Silicon Valley and the success stories of Google, Facebook, LinkedIn and Dropbox. However, the approach is older than most of these companies. Originally, the framework was first applied at Intel in the 1970s as an extended Management by Objectives (MbO) concept by Intel CEO Andy Grove. Grove wanted to ensure that the focus at Intel was on the most important objectives by further developing MbO. John Doerr then brought Intel's framework to Google in 1999 in his position as an investor. Google founders Larry Page and Sergey Brin did not adopt the framework 1:1, but expanded it once again to include another cornerstone: the measurability of progress.
Why are OKRs important?
The corporate vision is typically a short, concise sentence that describes where the company is heading. However, for many employees - and even managers - it is rather vague. The OKR framework offers companies the opportunity to concretize the vision and make it more understandable for all employees. This creates transparency as to what lies behind the vision and which goals and tasks result from it. It also answers the question of how each employee can add value to the company.
The purpose describes why we get up in the morning and do what we do. The vision tells us where we want to go. Objectives describe the qualitative goals - in other words, what we want to achieve in detail. The key results quantify the respective objectives. They drive success, make progress measurable and describe how we want to achieve our goals.
OKRs promote the agile mindset
The culture of every company can be described by three layers: The top layer (behavioral culture) describes the externally visible behaviors of employees. The middle layer (value culture) contains the collective values and norms within the company that lead to the behaviors that are practiced. The bottom layer (organizational structure) results from the existing processes, organizational charts and rules in the company.
Changes work from the bottom up. This means that in order to positively influence the value culture and ultimately the behavioural culture of an entire company, the organizational structure must be changed. The OKR framework for employee management has a major advantage here compared to other agile methods such as SCRUM or design thinking: it starts at the organizational level and thus influences the understanding of values of all employees. By changing the organizational structure, agile values such as trust, self-organization, transparency and approaches such as Minimal Viable Product (MVP) can be anchored in the company's value culture. OKRs thus help to establish agile working methods such as SCRUM in the long term: SCRUM teams can follow the method without restriction and do not have to justify their new understanding of values on a daily basis. This is because the higher hierarchical levels and neighboring departments now work according to the same agile basic principles.
Our OKR services: How we support you
OKRs form the foundation for establishing agile values in the entire corporate culture.
OKRs change the values of the company and the mindsets of employees, and this change needs to be accompanied professionally. We support companies in all strategic and operational steps in the implementation of the OKR framework - from analyzing the status quo to supporting the first OKR cycles. Our focus is on familiarizing employees with the OKR framework and getting them excited about it so that agile thinking structures can be sustainably integrated into everyday working life and become part of the culture. With our change know-how, we ensure that the OKR philosophy is positively received and lived by the employees involved.
1. analysis of the status quo
1.1 Analysis of the current situation in the company, in the departments and in the teams
1.2 Coordination of the objectives pursued with the introduction of the OKRs
2. defining the vision and OKRs
2.1 Developing the overarching vision and using creative workshop methods
2.2 Jointly developing the OKRs
3. set up the OKR cycle
3.1 Set up a quarterly cycle with the necessary processes, roles, templates and tools
4. empowering employees for individual OKRs
4.1 Introducing employees to the topic of OKR and creating understanding
4.2 Methodological empowerment and training
4.3 Personal coaching on demand
5. focus employees on the OKRs
5.1 Create regular anchor points
5.2 Support employees in defining OKRs so that individual goals, team goals and company goals are consistently linked with each other
6. measuring, controlling and documenting progress
6.1 Supporting the OKR cycle as OKR master and office
6.2 Creating transparency about status and progress
6.3 Moderating status updates and retrospectives
6.4 Documentation
OKR benefits that we achieve together with our customers:
Transparency: OKRs allow you to see what employees are working on in the company and what progress they are making. The transparency gained promotes collaboration and communication about successes and problems.
Focus: Limiting the number of objectives to a maximum of 5 also encourages employees to share what they want to focus on in the coming weeks and in which direction they want to move. Communication no longer only takes place at management level, but together with all employees. This strengthens the "WE feeling".
Contribution to the company goal: While goals are traditionally broken down top-down and delegated, employees learn to identify their own contribution to the goal with the help of OKRs. Everyone deals with the added value they can achieve with their work for the overarching goal.
Contributing their own strengths: The OKR framework offers employees the opportunity to provide support where their strengths and interests lie. This increases intrinsic motivation and identification with the company. Employees no longer follow orders, but mobilize their personal strengths.
Quarterly adjustments: Thanks to the short cycle of 3 months and the openness for adjustments to the key results, the company remains flexible. At the beginning of each quarter, all employees revisit the question of which topics are relevant in the next cycle. The employees continuously deal with the successes and challenges of their company.
Ambitious goals: Goals are set ambitiously and challengingly in the OKR framework - at company, team and employee level. Employees learn how to deal with ambitious targets. Even a degree of achievement of 60-70% is considered a success. If targets are not achieved, the teams deal with the causes and learn from them for the next cycle.
06 What is Scrum?
The following information is based on the Scrum GuideTM, enriched with the practical experience of our consultants.
The Scrum framework consists of Scrum teams and the associated roles, events, artifacts and rules. Each component within the framework has a specific purpose and is crucial to the success of Scrum and its use.
Scrum is
1. lightweight
2. easy to understand
3. difficult to master
Roles
1. Product Owner - "The Designer"
2. Scrum Master - "The Facilitator"
3. Development Team - "The Creators"
Artifacts
1. Product Backlog - All functions of the target product
2. Sprint Backlog - All product features to be created during the sprint.
3. Increment - Potentially releasable product part
4. Definition of Done - When the product is ready for use.
Events
1. Sprint Planning - Prioritizing and defining features to be created in the sprint
2. Daily Scrum - Continuously informing team members about progress
3. Sprint Review - Presenting the results of the sprint
4. Sprint Retrospective - Reflecting on the team's working style
Scrum theory
SCRUM is a framework rather than a process or technique and is the most popular of many agile methods. People can tackle complex adaptive problems while productively and creatively delivering products with the greatest possible value. Scrum uses an iterative, incremental approach to optimize predictability and control risk. It is based on empirical process control or "empiricism" for short - knowledge is based on experience and decisions are made based on what is known.
Scrum process
SCRUM is supported by three pillars:
TRANSPARENCY
Everything about the project is visible to everyone. Everyone involved really sees and understands what happens during a sprint and can predict what will happen in the next sprint. Increased communication and mutual trust help the team to work together towards the common goal.
REVIEW
The entire Scrum team must regularly review all project variables such as processes, techniques, products, team settings, etc. in order to identify undesirable deviations from the sprint goal.
ADJUSTMENT
Based on the results of the inspections, all project variables are adjusted for continuous improvement. An adjustment must be made as soon as possible to minimize further deviations and ultimately maximize the business value of the product.
Scrum values
Courage is a quality of mind that enables you to face danger or pain without showing fear. It takes courage to uncover problems, recognize obstacles, ask for help, receive help and offer help.
Openness is characterized by an attitude of accessibility without concealment or secrecy. Everyone should know everything about the work during a Scrum implementation.
Respect refers to both a positive attitude towards a person or another entity and authentic behavior in line with this appreciation. Without respect, there would be a high potential for miscommunication, low communication frequency and hurt feelings.
Focus is the concentration of attention. People who are not focused are not paying attention in any meaningful way and cannot learn to any meaningful level of depth.
Commitment means committing to a course of action. If people cannot commit, they will find themselves in the limbo of doing nothing, a state of inaction.
Scrum Roles & Responsibilities
Product Owner
... is responsible for coordinating with the various stakeholders. The entire organization must respect his or her decisions.
... should have full decision-making authority to reduce the risk of unnecessary delays.
... is the only person who makes requests to the Development Team.
... is the only person who has the authority to cancel the sprint.
... could delegate the management of the Product Backlog to the Development Team, but always remains accountable.
Product Backlog
1. Creation, maintenance and description of the product backlog
2. Prioritize the Product Backlog items 3. Ensure that the Product Backlog is transparent and visible.
4. Ensure that the Development Team has the right understanding of the Product Backlog Items
Sprint Planning
1. Discuss the goal that the Scrum Team should achieve in the Sprint
2. Support in understanding the selected items from the Product Backlog and making trade-offs.
Sprint Review
1. Invite the Scrum team to the Sprint Review meeting
2. Explanation of which Product Backlog items are finished ("Done") and which are not ("Not Done")
3. Presentation of the current backlog status and prediction of the expected target and delivery date
Scrum Master
... is a Servant Leader for the Scrum Team.
... is responsible for removing impediments to the Development Team's progress.
... should work with the Scrum Team and the organization to increase transparency.
Sprint Planning
↓
Daily Scrum
↓
Sprint Review
↓
Sprint Retrospective
1. Support the Scrum process
2. Ensuring that the Scrum events take place and the team understands the purpose
3. Coaching the Scrum team to follow the rules
4. Collaborate with other Scrum team members to understand the execution of the Sprint and review the performance and progress of the Sprint
Product Owner
1. Teach techniques for managing the Product Backlog
2. Provide an understanding of the need for clear and concise product backlog items in the Scrum team
3. Create an understanding of product planning in an empirical environment
4. Ensure that the Product Owner knows how to arrange the Product Backlog to maximize value.
5. Provide an understanding of Agile and its practical application
6. Supporting Scrum events as needed or requested
Development Team
1. Coaching the team in self-organization and cross-functional teamwork
2. Supporting the team in the development of high-quality products
3. Removing obstacles that prevent the team from progressing
4. Facilitating Scrum events as requested or required
5. Coaching the team in an organizational environment where Scrum is not yet fully adopted and understood
Organization
1. Leading and coaching the organization in the introduction of Scrum
2. Planning Scrum implementations within the organization
3. Supporting employees and stakeholders in understanding and implementing Scrum and empirical product development.
4. Triggering changes that increase the productivity of the Scrum team.
5. Collaborating with other Scrum Masters to increase the effectiveness of Scrum implementation in the organization.
Development Team
1. The product backlog is the only collection of requirements for processing and implementation.
2. It should be self-organized and interdisciplinary.
3. The team decides independently on the work tasks for the next sprint and the estimated effort for each task.
4. There is no title in the team and no further subdivision within the team. However, individual team members may have specialized skills.
5. The number of team members should be between 3 and 9 people.
Sprint Planning
1. Define the tasks of the sprint backlog
2. Making decisions about how to translate the Sprint Goal and Sprint Backlog into a finished ("Done") product increment.
3. Self-organized to complete the work in the Sprint Backlog.
Daily Scrum
1. Responsible for the execution of the Daily Scrum
2. Review progress towards the Sprint Goal
3. Frequent meeting after the Daily Scrum: detailed discussions, adjustments or rescheduling of the work in the Sprint
Sprint Review
1. Demonstration of the completed work to product owners and stakeholders and answering questions about the increment.
2. Presentation of what went well during the sprint, identification of problems and problem solutions
Stakeholders
(Not an official Scrum role according to the Scrum GuideTM) Due to the individual nature of each project, there can be major differences in terms of the importance and influence of stakeholders. There are probably even more stakeholders than those described here. Therefore, a detailed stakeholder analysis at the beginning and during the project is crucial for success.
Customer
1. Internal: Persons/groups who make the funding decision for product development (typically managing directors or budget managers).
2. External: Persons/groups/organizations who pay for the use of the product (only applies to products sold externally).
End user
1. Is the most important source of information when defining the requirements.
2. Is the protagonist in most user stories; checks the increments (passive, based on user stories).
3. Use of the end product
Manager
1. Providing resources and guidelines within the organization
2. Resolves issues escalated by the Scrum Master.
3. Is the final authority that decides on issues.
Scrum artefacts
Product vision
The product vision is a short statement that describes the goals and benefits of the product.
1. The product vision explains how the product supports the goals and strategies of the company or organization.
2. The product vision refers to the most important product goals, the customer, how it can meet their needs and should emphasize the unique value.
3. The product vision should be created before the product backlog.
4.The product owner isresponsible for the product vision and updating it.
Template for creating a vision statement (according to Geoffrey A. Moore) Moore)
There are a number of aspects that should always be considered in a correct vision statement:
FOR "Target Customer"
THE "Need( s)"
THE "Product Name"
IS A "Product Category"
THE "Product Benefit / Reason to Buy"
OTHER THAN "Competitors"
OUR PRODUCT "Differentiation / Value Proposition"
ElevatorPitch
The best way to validate the product vision is to perform the elevator pitch: "Can you describe your product in the time it takes to ride up in an elevator?" Completing this test ensures that your product vision is clear, engaging and concise.
Product Increment
The results of all Product Backlog items completed during a Sprint and all previous Sprints.
1. At the end of each Sprint, the new Increment must be "Done", i.e. it must be in a usable state and meet the Scrum Team's Definition of Done.
2. If the Development Team has planned and estimated well, the Product Increment contains all items of the Sprint Backlog.
Product backlog
The product backlog is a prioritized list with short descriptions of everything that is known to be included in the product.
1. should always contain enough requirements (often in the form of user stories) to cover at least one, preferably two, sprints.
2. is a living artifact; it is allowed to grow and change as more is learned about the product and its customers.
3. is dynamic; it changes constantly as new circumstances arise (e.g. new requirements, changes in market trends). 4. lists all features, functions, requirements, enhancements and fixes that represent changes to be made to the product in future releases.
Backlog prioritization
User stories are prioritized by the product owner according to importance, effort and value.
User stories
User stories are short, simple descriptions of the desired
functionality.
1. User stories are written from the perspective of the person who will benefit from the implementation of the user story.
2The user story is written in the format of: "As [WHO] I want [WHAT] so that [reason]."
Characteristics of a good user story
I ndependent (Independent)
N egotiable (Transferable)
V aluable (Valuable)
E stimable (Estimable)
S mall (Small)
T estable (Verifiable)
Definition of Done
Coordinated activities that are required to deliver a finished ("Done") product increment at the end of a sprint.
1. The Definition of Done (DoD) must be clear for the entire Scrum team and is used to decide when a user story from the sprint backlog is completed.
2. Each Scrum team has its own DoD. It is important that each team has a common definition that everyone understands.
Example:
1. All tasks completed
2. All acceptance criteria met
3. Code complete
4. Fully tested
5. No known defects
6. Documentation updated
Acceptance criteria
A list of requirements that must be met for the user story to be considered complete.
1. The acceptance criteria created by the product owner define the boundaries of a user story and determine when a user story is implemented.
2While the DoD is generic and applies to all user stories, the acceptance criteria are different for each user story.
Example:
1. "The home button is visible on all pages."
2. "Clicking the home button returns the user to the home page."
3. "The home button is recognizable."
Story Points
Unit for estimating the total effort of a product backlog item.
1The Scrum Team estimates the effort required to implement the user story, including everything that can influence the effort (workload / complexity of the work / risk or uncertainty in carrying out the work).
2. Instead of story points, user stories can also be estimated in other units, e.g. T-shirt sizes S/M/L/L/XL.
Planning Poker
Agile estimation and planning method used to estimate the effort or relative size of backlog items. In Planning Poker, the members of the group estimate by playing numbered cards with values representing the number of story points (0, 1, 2, 3, 5, 8, 13, 20, 40 and 100).
The following rules apply to the game:
1. The product owner or customer reads a user story or describes a function to the team.
2. The team discusses the function and asks questions that the product owner must answer.
3.After the discussion, each team member lays down a face-down card representing their estimate for the story.
4. All cards are revealed simultaneously.
5. If all team members have the same value, this becomes the estimate for the user story.
6. If not, team members with high and low estimates are given the opportunity to justify their estimate.
7. The estimation process is repeated until a consensus is reached.
Sprint Backlog
Product Backlog items identified by the Development Team to be completed during the upcoming Sprint.
1. During the Sprint Planning Meeting, the team selects a set of Product Backlog items (user stories).
2The selected Product Backlog items are summarized in the Sprint Goal.
3. The team identifies the tasks necessary to complete each User Story.
4. During the Scrum cycle, the predefined tasks are completed.
5. The team adjusts the Sprint Backlog throughout the Sprint
Tasks
Dividing the Product Backlog items into tasks helps the Development Team to plan the next To Dos of the sprint.
1. Ideally, a task is sized so that it can be completed by the next Scrum meeting.
2. Clear responsibilities are defined for each task.
3. In contrast to user stories, the tasks are defined by the people who do the work - the Development Team.
4. The tasks can be broken down into smaller pieces if necessary.
Task Board
Visualization tool for work and workflow that enables the team to optimize the work process.
1. Work tasks are visualized to give participants an overview of progress and process, from task definition (Sprint Backlog) to delivery to the customer ("Done").
2. Team members "take" work as capacity allows, rather than "pushing" it into the process on demand.
3. The Task Board should be updated in the Daily Scrums.
Sprint Down Burn Chart
A way to track Scrum sprints and the implementation progress of agile projects.
1. The team estimates the hours needed to complete each task at the sprint planning meeting.
2The Scrum Master calculates the outstanding work, displays it graphically and compares it with the estimate.
3. The outstanding work (or backlog) is often on the vertical axis, the time on the horizontal axis.
4. In addition to planning and tracking, the chart also serves as a tool for risk minimization and communication.
Scrum Events
Sprint Planning
A meeting where the Development Team plans the work for the next Sprint. During the Sprint Planning meeting:
1. the Product Owner describes the goal of the Sprint and explains the highest priority features (work for two Sprints) to the team.
2. the Development Team decides how many items from the Product Backlog can be realized in the next Sprint based on their capacities.
3. the Development Team asks enough questions to transform a high-priority user story from the Product Backlog into the more detailed tasks of the Sprint Backlog.
There are two artifacts that result from a Sprint Planning meeting:
1. Sprint Goal: a brief description of what the Scrum Team wants to achieve during a Sprint.
2. Sprint Backlog: Collection of product backlog items and corresponding tasks to be implemented within the next sprint.
Daily Scrum Meeting
The Development Team meets every day to coordinate activities and plan the next 24 hours.
1. 15-minute time box for the Development Team.
2. The meeting should take place at the same time and place every day, ideally in the morning.
3The team reviews progress towards the sprint goal using the following questions:
4. "What did I do yesterday that helped the team achieve the sprint goal?"
5. "What will I do today to help the team achieve the sprint goal?"
6. "Do I see any obstacles that will prevent us from achieving the sprint goal?"
Backlog refinement
Helps to prepare and update the product backlog for the next sprint planning meeting.
Backlog refinement should take place continuously during each sprint. The aim is to update the product backlog and prepare the user stories for the next sprint planning meeting:
1. Adding or removing user stories
2. Detailing user stories
3. Define acceptance criteria and story size
4. Update prioritization of user stories
The backlog refinement helps to prepare the user stories so that the next Sprint Planning meeting starts immediately with clear and well-defined items.
Sprint Review
The Development Team demonstrates the increment that was developed during the Sprint and this is assessed against the Sprint Goal.
1Only the results that represent a "potentially deliverable product increment" are presented, e.g. coded, tested and usable software.
2. In addition to the Scrum team, the stakeholders should also participate in this informal meeting.
3Stakeholders can provide feedback to the Development Team, which is then included as a new user story in the Product Backlog.
Sprint Retrospective
The meeting enables the Scrum Team to continuously review and improve throughout the duration of the project.
Every member of the Scrum Team should have the opportunity to express their opinion in an open, honest and constructive atmosphere.
The Scrum Team should:
1. review how the past Sprint went for the people, relationships, processes and tools involved.
2. identify the most important elements that went well
3. Uncover and prioritize potential improvements and create a plan for their implementation
Pitfalls
The Product Owner function is not well defined or is not practiced
Symptoms
1. Stories are often not finished ("Done")
2. The Product Owner is not available to answer questions from the team.
3. The team receives different messages from different sources.
Suggested actions
1. Each team should have its own Product Owner.
2. All backlog items and tasks should only be communicated to the team via the Product Owner.
3. The Product Owner should adjust the Product Backlog and its prioritization through regular communication with the stakeholders
The team does not invest enough time to refine the backlog
Symptoms
1. The sprint planning meeting takes a long time.
2. Stories are difficult to assess.
3. Stories are not finished ("Done") at the end of a sprint.
Suggested actions
1. The Scrum Master should organize regular backlog refinements to discuss upcoming user stories.
2. The Product Owner should coordinate with the stakeholders in advance.
3. The Product Owner should participate in the backlog refinement to discuss upcoming work together with the team.
Stories are not sufficiently broken down or not independent
Symptoms
1. User stories are not finished ("Done") at the end of a sprint.
2. The actual effort is often much greater than estimated.
3. It is difficult for the team to react immediately to stories.
Suggested measures
1. Rule of thumb to apply when writing user stories: A user story should not take longer than 1/2 or (ideally 1/3) of the total sprint duration.
2. User stories should follow the "INVEST" rule of thumb (independent, negotiable, valuable, estimable, small, testable).
The team is managed by someone else
Symptoms
1. Stories are not finished or not started until the end of the sprint.
2. The team is working without a sustainable pace to complete each sprint and is under a lot of pressure.
Suggested actions
1. The team should start tracking progress (e.g. how many story points can be achieved in a sprint) to establish an average velocity.
2. Only the team estimates the work and indicates how much work / how many stories they can complete during a sprint.
3. Align expectations of self-organized teams with management and stakeholders.
The team works individually on the backlog
Symptoms
1. The team believes that each backlog item is handled by only one person.
2. Bottlenecks occur around a single team member.
3. One person or group works overtime to keep up with demand in the given time.
Suggested actions
1. Encourage collaboration on stories to increase the quality of the final product.
2. Product Owners should write stories that allow for pairing.
3. Train the team on skills, subject matter experts work with one or two team members to acquire new skills.
Additional work interrupts the sprint
Symptoms
1. The team identifies significant unplanned work or receives requests from stakeholders that need to be completed immediately.
2. Planned stories are not completed.
3. The team feels that priorities are constantly changing.
Suggested actions
1. Include sprint buffers for 'additional/found work'.
2. Use retrospectives to identify ways to better anticipate additional work.
3. Confront leadership with the impact of interruptions.
4. Encourage the Product Owner in their role and protect the team from interruptions.