Consulting for agile transformation and agile working
Bringing agile working to life
Further develop framework conditions in a targeted manner
We analyze and design the key levers for agility: leadership, collaboration, roles, and decision-making processes. This is how we enable agile working in your environment.
Fast-acting, long-lasting benefits
Bringing agile working to life
We clarify what agile working means in your company—at the technical, organizational, and cultural levels. This allows us to create clarity and promote a common understanding.
Further develop framework conditions in a targeted manner
We analyze and design the key levers for agility: leadership, collaboration, roles, and decision-making processes. This is how we enable agile working in your environment.
Fast-acting, long-lasting benefits
01 What you get from us
1. Agile Coaching & Consulting
Typical problems/symptoms in the customer context:
Teams or other organizational units are stuck, unable to achieve their goals and repeatedly encountering organizational
or individual obstacles. Dissatisfaction is spreading among the team and among managers.
1. Agile Coaching & Consulting
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.
Possible alternative solutions:
Our agile coaching and consulting activities aim to ensure performance. Depending on your needs, 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 what is needed most at the time.
2. Leadership development
Typical problems/symptoms in the customer context:
Employees are often promoted to management positions without adequate preparation for the challenges of leadership. This leads to employees feeling poorly managed and possibly leaving the organization.
2. Leadership development
Our interpretation/analysis:
Self-awareness is crucial for leading others effectively. Leadership development involves improving one's own thinking and actions as well as clarifying one's own role. In addition to technical skills, it is important to motivate employees to develop their potential and convey the right values.
Possible alternative solutions:
We offer individual coaching, consulting, and mentoring services for managers. These can be provided over a longer period of time to support the development of managers through dialogue and help them achieve their development goals. In addition, we develop customized learning programs and implement them for specific target groups.
3. Cultural development
Typical problems/symptoms in the customer context:
In change processes, cultural development is sometimes neglected and old traditions and habits often remain intact. For example, in hierarchical cultures, it may be common for every decision to first be approved by the boss. This can slow down processes and limit employee autonomy.
3. Cultural development
Our interpretation/analysis:
Culture is often difficult to grasp, change takes time, and rituals do not change overnight. Those affected must be supported to cushion any relapses into old patterns. Often, only behavioral changes are sought without addressing the underlying beliefs—thus, sustainable change does not occur.
Possible alternative solutions:
Implementation requires a tailored approach. Organizational and team cultures can be changed in a targeted manner through interventions and new methods. Change processes take place at various cultural levels. We use the dimensions of "system," "behavior," and "beliefs" to make culture visible and apply our "Micro Change Cycle."
4. Systemic coaching
Typical problems/symptoms in the customer context:
In many organizations, feedback meetings only take place every six months or once a year. However, this alone is often not enough to help employees reach their full potential. Inefficiencies and demotivation are often the result of personnel development that is not sufficiently strength-oriented.
4. Systemic coaching
Our interpretation/analysis:
Coaching is an effective form of support for employees who need to adapt to changing environments in order to unleash their energy, innovative power, and commitment. Unlike feedback, which evaluates past behavior and suggests adjustments, coaching takes a preparatory approach to solving challenges. Systemic coaching additionally incorporates the system and its areas of influence.
Possible alternative solutions:
Systemic coaching supports people in their self-determined goals and helps them move from a deficient situation to a resourceful target state. Our experienced coaches support employees in confidential 1:1 coaching sessions or as a team.
5. Team development
Typical problems/symptoms in the customer context:
Teams can face different challenges that cause dissatisfaction and reduced performance. For example, one team may be striving for rapid and disruptive development of a new product, while another team may be aiming to reduce costs and set new standardization requirements. This leads to uncertainty in prioritization and impairs collaboration between teams.
5. Team development
Our interpretation/analysis:
These symptoms are often caused by conflicting goals, rigid processes, lack of trust, false expectations, and a lack of communication and transparency.
Possible solutions:
First, we make the people pursuing these different goals aware of the conflict and offer them advice on possible solutions. As part of team development, we simultaneously strive to improve cooperation within and between teams. By regularly reflecting on cooperation with the teams, we can address challenges, derive appropriate measures, and proactively tackle future problems. We also promote communication and transparency as well as the setting of common goals through various formats such as workshops or retrospectives.
6. Adaptive organizational design
Typical problems/symptoms in the customer context:
In your organization, there is no clear distribution of tasks in product development. Decision-making processes are long, communication between departments is limited, and product changes are slow. Innovation development is a challenge. In contrast, competitors can react quickly and bring innovative products to market. These internal challenges lead to demotivation among employees, higher turnover, and lost revenue.
6. Adaptive organizational design
Our interpretation/analysis:
These symptoms are often caused by rigid processes and hierarchies, complex problems and requirements, insufficient prioritization, and conflicting goals between different organizational units.
Possible solutions:
Adaptive organizational design is an interplay of different areas of performance. Our goal is to create an organizational structure and working methods that enable rapid adaptation to change and achieve sustainable competitive advantages. By identifying value streams and using agile methods, we support our clients in mapping these value streams organizationally, establishing decentralized decision-making processes, and breaking down hierarchies. This enables them to better deal with the complexity of an issue while maintaining focus and transparency.
7. Beliefs & Patterns
Typical problems/symptoms in the customer context:
In agile transformations, we often see employees and managers falling back into old behavior patterns. For example, they have difficulty prioritizing, focusing, or delegating tasks. As a result, the advantages of agile working remain untapped and problems such as ignorance, confrontation, or frustration arise.
7. Beliefs & Patterns
Our interpretation/analysis:
When changes are made, the focus is often on behavior, while a systemic view of the organization and existing beliefs is neglected. Without the right leverage, the desired effect loses its power and employees and managers fall back into old patterns.
Possible alternative solutions:
In the first step, we create transparency and try to make culture visible across 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 website PatternBreakers. There, we provide inspiration on behavioral patterns, beliefs, and interventions that you can test directly in your environment.
8. Change management
Typical problems/symptoms in the customer context:
New strategies, structures, processes, working methods, IT systems, or even management principles are being introduced or adapted within the organization. Previous change projects may have already failed. The current change project is meeting with resistance and frustration is spreading.
8. Change management
Our interpretation/analysis:
Employees and managers are often not sufficiently informed or involved in change processes. The necessity remains unclear, the target vision unknown, and the individual contribution difficult to identify. In addition, measures often do not match the actual needs of employees.
Possible alternative solutions:
The success of change depends heavily on employee acceptance and development. With our change approach and low-threshold "micro changes," we accompany change in a needs-based and adaptive manner. Hypotheses and desired effects are defined and measured for each measure. The next cycle (micro change) is adjusted based on the results.
9. Purpose-driven work
Typical problems/symptoms in the customer context:
Employees or teams are unaware 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 manifests itself in dissatisfaction, demotivation, or high turnover.
9. Purpose-driven work
Our interpretation/analysis:
Poor communication, lack of transparency, and failure to focus on strengths are often the causes of ambiguity and an incomprehensible vision.
Possible alternative solutions:
To remedy this, we work with our clients to develop an overarching purpose and an easily understandable vision for employees. This provides a clear and simple answer to the question of "why" for everyone. To ensure that the purpose is successful in the long term, we review it after its introduction to see if it really fits the organizational structure and make changes if necessary.
10. Value stream analysis
Typical problems/symptoms in the customer context:
Customer satisfaction is low, cooperation between teams or organizational units is poor or non-existent, employees complain about long waiting times and delays, or dependencies are unclear.
10. Value stream analysis
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's request to the finished product or service. Employees do not feel responsible for the entire process.
Possible solutions:
With value stream mapping, we aim to make all the work and activities necessary to fulfill an order transparent. The value stream begins and ends with the customer—internal or external. This method is powerful in identifying waste or delays in the process. Our experience shows that the strength of value stream mapping lies in the derivation and implementation of incremental improvement potential, such as changing team structures or adjusting interfaces.
02 What working with us looks like
The AMPlifiers are the team within CPC that has been fully committed to Agile for many years. Our identity as AMPlifiers is shaped by our guiding principles of Autonomy, Mastery, and Purpose. We act independently, continuously develop ourselves, and strive to do something meaningful. These principles describe how we work with customers and what we want to achieve together.
Our promise for working with you and the compass for our team:
1. We at AMPlifier are passionate about passionate collaboration.
1. We at AMPlifier are passionate about passionate collaboration.
Together with you, we realize the advantages of agile principles, design organizational frameworks, empower employees, and break through behavioral patterns in a targeted manner—for sustainable success in corporate culture development.
2. We expose our customers to the wind
2. We expose our customers to the wind
We use honest questions and ideas to shake up stuck patterns of behavior. As AMPlifiers, we spot and develop existing talents and help you use them in a focused and effective way—always following the principle of "strengthening strengths."
3. We shape your corporate culture
3. We shape your corporate culture
Building on what already exists, we work with you to establish a performance culture, greater customer focus, or an agile culture. In doing so, we promote trust and, as coaches, develop sustainable tactics—before, during, and after the game.
4. We make an impact by setting specific courses of action
4. We make an impact by setting specific courses of action
We observe, develop hypotheses, implement solutions, and measure success. With focused interventions at the individual, team, and organizational levels, we overcome obstacles and solve even complex problems at the relevant points.
5. We move our customers and ourselves into the flow together.
5. We move our customers and ourselves into the flow together.
By "flow," we mean a state of focused, effortless goal pursuit. We achieve this through transparency, respectful communication, a focus on strengths, and clear accountability—for intrinsic motivation and effective teamwork.
6. Experience + hypotheses + experiments = valid results.
6. Experience + hypotheses + experiments = valid results.
We make assumptions based on observations and experience, validate them through experiments, and question existing beliefs. In short cycles, we make results measurable and iteratively adapt the system together with our customers.
The amplifiers at a glance
- 103 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 Collaborations with strategic partners
- More than 80% of our customers are repeat buyers.
- 10+ years of experience in corporate culture development
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 Collaborations with strategic partners
70% of our customers are repeat buyers
Average of 5.1 years of experience in Agile and Change
03 How we have solved customer problems in various industries
Reference Case 1 Automotive
- value stream analysis
- Adaptive organizational design
- Agile consulting
Reference Case 3 Information and Communication Technology
- leadership development
- cultural development
- Beliefs and patterns
Reference Case 4 Information and Communication Technology
- Adaptive organizational design
- Agile consulting
- value stream analysis
Reference Case 1 - Automotive
- value stream analysis
- Adaptive organizational design
- Agile consulting
Reference Case 3 Information and Communication Technology
- leadership development
- cultural development
- Beliefs and patterns
Reference Case 4 Information and Communication Technology
- Adaptive organizational design
- Agile consulting
- value stream analysis
What our customers say
"CPC quickly understood our challenges, provided many new ideas, and rapidly implemented them in experiments. Over 90% of respondents now understand our new vision and strategy."
Director of Corporate Strategy, Hanwha Q CELLS GmbH
"What sets you apart is that you are not afraid to disagree and do not just tell customers what they want to hear."
Agile Coach, Deutsche Telekom
"I am very satisfied with the result.
The approach was very structured and methodically sound."
Project Lead, Mercedes Benz
"It's remarkable that you approached me with suggestions for problems that I hadn't even noticed."
Agile Coach, Deutsche Telekom
"You pointed out tensions within my team that I had never noticed before. I've never experienced that in any other consultation."
Team Lead, T-Systems
Discuss
your project with us!
The first step is very simple—and don't worry: we don't send boring newsletters or annoying advertising emails. Instead, we focus on what's important: your desire for change and how we can help your business move forward.
Step 1
Call back or email.
We will contact you within 24 hours, record your requirements, and coordinate an appointment with one of our experts.
Step 2
Free initial consultation.
In a video conference, you explain your project and discuss possible solution scenarios with our expert.
Step 3
You decide how to proceed.
Offer, pitch, or project launch? You decide the next steps.
Questions and answers
What does agility mean to us?
Agility refers to the ability to respond quickly and appropriately to a complex and dynamic environment, often in the form of customer requirements. Agility therefore means flexibility, or—quite simply—vitality.
Agile companies have understood that they operate 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 believe agility is important?
Many companies are currently feeling the pressure of an increasingly dynamic market environment in which it is essential to remain competitive:
01. Digitalization enables disruption, which quickly displaces existing technologies, products, and services from the market. New players challenge established companies. When accumulated knowledge and company size do not create a lasting competitive advantage, innovation and agility become enormously important.
02. The increasing number of uncertainties in the market environment inevitably increases the pace at which companies must make decisions and adapt to changing conditions. Predictability is declining: whereas projects used to be planned and rolled out in a waterfall-like manner over several years, short, iterative cycles are now sufficient—the shorter, the better.
03. Recognizing one's own contribution to the company's value creation is increasingly becoming a key motivating factor for employees. External control and a lack of self-efficacy destroy motivation and drastically reduce agility and innovative strength.
What is the Agile Manifesto?
In 2001, 17 renowned software developers published the Agile Manifesto (Manifesto for Agile Software Development, Agile Manifesto). Among the first signatories were the two founders of Scrum, Jeff Sutherland and Ken Schwaber. To date, thousands more signatories have publicly committed themselves to the principles of the manifesto. The authors wanted to distill the core ideas of modern software development into a short, common denominator. The Agile Manifesto consists of four guiding principles that contrast agile values with traditional approaches. It reflects the spirit of agility and forms the foundation for agile methods such as Scrum:
1. Individuals and interactions are more important than processes and tools
2. Working product is more important than comprehensive documentation
3. Responding to change is more important than following and executing a plan
4. Collaboration with the customer is more important than contract negotiation
The four guiding principles are further specified by a total of twelve principles. They explain the values and principles for agile teams in more detail:
1. Satisfy the customer through early and continuous delivery of working and valuable products.
2. Welcome changing requirements, even in late development phases.
3. Deliver regular working products within a few weeks or months – the shorter the time span, the better.
4. Business and developers work closely together on a daily basis.
5. Build the project around motivated individuals who are given the environment, support, and trust they need.
6. Communicate and exchange information through personal communication.
7. Working products are the most important measure of progress.
8. Maintain a constant pace.
9. Continuously pursue technical excellence.
10. Simplicity is essential.
11. Teams are self-organizing.
12. Teams regularly review how they can improve and adjust their behavior accordingly.

What do we mean by agile transformation?
Definition and meaning of "agile transformations"
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 delivery in order to survive in the VUCA world. Agile transformation is a change process that companies do not undergo overnight. After all, for an organization to truly work in an agile manner, it takes much 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 behavior is appropriate when, what demands the organization places on its employees, and what boundaries must not be crossed.
Why do agile transformations fail?
It is often precisely these framework conditions that become critical success factors and cause many agile transformations to fail. Structural elements such as reporting and approval processes, control and planning mechanisms, or internal performance incentives and evaluations can either hinder agile value creation or make it truly possible. They are the biggest lever for specifically breaking down and reconnecting the fusion of value creation and the values and principles of an organization. To understand how this can be achieved, a fundamental insight is needed at the outset:
At the heart of an agile transformation are not methods or frameworks, but first and foremost values and principles that govern collaboration.
After all, each of the well-known, widely promoted agile methods was developed through the consistent application of these values and principles to a specific business case—be it SCRUM for project work, Kanban for the service sector, or Lean Startup for testing new business ideas. Visualization and estimation techniques such as burn-down charts and planning poker followed.
Unfortunately, agile transformations too often focus on these methods and techniques instead of starting with values and principles. However, no matter how popular a method may be, it can only be successfully applied by an organization if it follows the same agile values and principles on which the method is based. If it does not, the application will not only remain ineffective, but in the worst case, it will cause damage.An organization's guiding values and principles, in turn, are embedded in its culture, which invisibly determines behavior and guides decisions. When we talk about sustainable agile transformation, we automatically mean cultural transformation as well. Agility does not begin with Post-its, squads, sprints, and hackathons, but with values and principles and a critical look at one's own culture.

Step by step toward an agile organization Culture is the memory of the organization.
It is their immune system, which attempts to ensure the organization's survival in the future by replicating what has been successful in the past. Culture is reflected in the organization: in processes, organizational charts, and rules that have proven helpful over decades. To bring about lasting change in an organization's culture, it is not enough to simply proclaim new values and plaster the hallways with posters – just as it is of little help to try to inspire genuine enthusiasm in an audience at a concert with a bad atmosphere using a teleprompter. Even if every single employee is convinced of the effectiveness of agile values and principles, the organization's processes and structures often act as a layer of clay. Only by specifically questioning processes, decision-making rules, organizational charts, etc. can the existing framework conditions for collaboration be analyzed in small iterations, specifically changed, and the agility of the organization increased. Each iteration thus enables new experiences to be gained, which enter the cultural memory and lead to lasting change.
1. Recognizing patterns
An iteration begins with the question of the value creation mission and where the current organization is hindering it. In the first step, we observe the collaboration in order to recognize critical patterns and thus identify starting points. This can be illustrated using the example of a swing: in order to accelerate or decelerate a child who is already swinging with the desired effect, it is first necessary to observe the pattern in which the swing is swinging. Only then can the push be applied at the right place and at the right time to increase or reduce the momentum as desired. In the same way, we first observe and analyze the existing organization and its patterns. Example: A client's human resources department has two value-added tasks. On the one hand, it is responsible for administrative tasks such as contracts, references, the onboarding process, etc. On the other hand, it is responsible for designing individual personnel development measures. In the past, internal clients have repeatedly been dissatisfied with the latter. The department's employees are accustomed to leaving decisions of a certain magnitude to their formal manager. Our observations show 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 mission and formulate a hypothesis about the influence of the organization on value creation. We look for a reason why the work is not succeeding as intended. In our example, we recognize that employees are developing personnel development concepts that primarily correspond to the manager's ideas. As a result, the customer focus takes a back seat and the value creation 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 work together to find a suitable lever to break the recurring pattern. This involves an organizational intervention, a kind of experiment, in which new things are tried out and different experiences are gathered for a predefined period of time. This is the only way to change mindsets and beliefs – with a direct impact on the underlying culture. Targeted disruption of the existing organization is needed to enable sustainable change. In our example, we disrupt the existing organization of the department by almost completely eliminating the influence of management for the period of the next personnel development concept – from the clarification of the assignment to its completion. We limit reporting, transfer full budget responsibility to the team, and let them make all decisions on their own, without the manager being able to intervene. Their only task is to create the necessary safe space. We accompany both the team and the manager throughout the pilot to prevent a relapse into old behavior patterns.
4. Evaluate results
Once the experiment is complete, check what changes have occurred. Did the lever have the desired effect? What should we keep from what we tried, and what needs to be reconsidered or adjusted? Could this also be a lever for other areas? Or do we need to try something completely different? In our example, it worked. Despite initial uncertainties, the team reports 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 specific environment with this specific team. Transferability to other teams and areas always requires a separate hypothesis and a new experiment—even if previous experience accelerates the observation process and often significantly increases the accuracy of hypothesis formation.
Using the transformation loop to become an agile organization
As our customer's example shows, change presents organizations with complex challenges, and a well-thought-out approach is needed to meet these challenges. Transforming an organization into an agile organization therefore means uncertainty and must be done holistically in order to achieve 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 structured and iterative approach enables precisely this 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 consists of phases that build on each other 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
Structural groundwork is required to initiate agile transformation. The first step is to "identify patterns and form hypotheses" in order to analyze the existing organization and its patterns. These patterns are then related to the value creation mission, allowing us to derive hypotheses that in turn lay the foundation for the so-called transformation backlog. The transformation backlog can be thought of as a guiding list of points to be addressed on the path to agile transformation. In addition, a team is needed to drive the agile transformation within 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. This person is supported in particular by the Transformation Master, who provides procedural support to the team and, indirectly, to the transformation project. Together, they assist 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: Greater agility through networking and institutionalization
Our consulting projects typically focus on a specific area of a company. The best conditions for making this area more agile are in place when the request for change and the motivation for it come from the manager responsible for that area. Through coaching and operational support, we empower the managers in that area to effectively build an agile organization from the inside out and to implement lasting cultural changes. In addition, we contribute comprehensive expertise in identifying value creation levers and empower managers to independently drive cultural change forward step by step.
How can a department-specific, agile transformation be turned into a comprehensive transformation that results in the entire company becoming agile at its core?
The more seeds of agile organization are sown within the company and interconnected, the more experiences can be shared, lessons learned exchanged, and common patterns—both desirable and undesirable—identified. With our many years of experience in sustainable change management, we have the necessary expertise to promote the appropriate dynamics and develop a self-reinforcing effect.
Many individual agile transformations and open communication about them gradually reveal the "hidden rules" and "organizational patterns" and institutionalize an agile organization. This does not turn the company's culture upside down. Experience shows 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 specifically replaced. After all, agile transformation must never become an end in itself.
First and foremost, we must always ask ourselves what our value creation mission is and what structures and conditions are currently hindering it. Genuine value creation is therefore our top priority in every project. Because in the end, what counts is not how many Post-its are stuck to the wall or how many sprints you've run, but whether the customer is willing to pay for the product or service. We are convinced that well-organized value creation that satisfies genuine customer needs not only brings sustainable economic success, but also gives employees a sense of satisfaction, makes them proud, and inspires them. That's 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 proven approach to successfully tackling agile transformation. Our experiences have been extremely positive. Whether as a coach, consultant, trainer, co-thinker, or co-pilot, we will work with you to find out what is needed and have a whole range of tools at our disposal to achieve this.
What does agility mean for managing employees from our perspective?
Modern leaders create an environment in which 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 leadership 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 the right mindset
Lifelong learning and flexibility are paradise for curious people who don't want to commit themselves at the beginning of their professional lives. But what about those who have grown up for years in systems that rewarded people who achieved fixed levels of competence? That promoted those who fit perfectly into a mold? Or at least those who successfully pretended to? As a manager, where do I get my raison d'être if I don't know more than my employees?
The shift toward an agile corporate structure poses major challenges, particularly for managers—not least because agile methods usually do not provide for any explicit leadership roles. Embracing this change requires a strong sense of self-awareness—and appropriate change management. It is therefore essential to support managers in these areas and not simply try to "teach" them a new management style.
What changes for managers and how can they properly engage their employees?
Change management is often left out of agile transformations. The need for change seems so obvious—who wants to lead like the big manufacturers of the 19th century?
Moreover, 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 for for years? 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—will I have to relinquish some of my powers? What will my future role as a manager look like? Will my employees continue to respect me? Managers react to change with shock and sadness just like other employees.
Previous skill profiles provided a clear framework for the skills required for specific tasks. This certainty has now disappeared, but it also offers the opportunity to finally focus on one's own strengths instead of being forced into fixed templates. To do this, however, one must know who one is, what one can do, but also who one is not and what one cannot do. Admitting to your own strengths and weaknesses is a completely new behavior in many organizations, which can be very unsettling. How much weakness is allowed, and at what point do you violate the rules of the system in which you still work?
Only when managers have mastered this change for themselves can they guide their employees through the change and authentically explain what is meant by buzzwords such as "fail fast." In order to embrace 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 the lower management levels.
Among other things, this requires top management to present a common change story—and to truly 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 this 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 set aside for leadership?
4. How and how often do we give each other feedback?
5. How do we deal with the individual strengths/weaknesses profiles of employees?
6. Who is allowed to make decisions themselves? Who gets promoted and why?
8. What career paths do we offer our employees?
9. What is this agile leadership?
Of course, it is not enough to simply have a common understanding—the respective manager—including those in upper management—must lead by example, actively apply the new leadership behavior, and regularly seek feedback on their leadership style.
The path to becoming an agile organization thus becomes an exciting journey for everyone involved, offering a wealth of opportunities.
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 primarily consists of three core elements: 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 measure each objective. 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 set their focus several times a year and adapt to changing conditions at shorter intervals.

transparency
The company's objectives and key results are visible to all managers and employees. The OKRs of each team and each individual employee are then linked to those of the company. Ultimately, there is clarity about who contributes to the success of the company with their goals and in what capacity.
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. The framework was first used in the 1970s at Intel as an expanded Management by Objectives (MbO) concept by Intel CEO Andy Grove. Grove wanted to ensure that Intel focused on its most important goals by further developing MbO. John Doerr then brought the framework from Intel 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 with another cornerstone: the measurability of progress.
Why are OKRs important?
The corporate vision is typically a short, concise sentence that describes where the journey is headed. For many employees—and even managers—however, it is rather vague. The OKR framework offers companies the opportunity to make the vision more concrete and easier for all employees to understand. This creates transparency about what lies behind the vision and what goals and tasks result from it. It also answers the question of how each employee can deliver added value for the company.

The purpose describeswhywe get up in the morning and do what we do. The vision tells uswherewe want to go. Objectives describe the qualitative goals—in other words, what we want to achieve in detail. Key results quantify the respective objectives. They are drivers of success, make progress measurable, and describehowwe want to achieve our goals.
OKRs promote an agile mindset
The culture of every company can be described in terms of three layers: The top layer (behavioral culture) describes the outwardly 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 actually practiced. The bottom layer (organizational structure) is determined by the existing processes, organizational charts, and rules within the company.
Changes work their way up from the bottom layer. This means that in order to positively influence the value culture and ultimately the behavioral culture of an entire company, the organizational structure must be changed. The OKR framework for employee management has a major advantage over other agile methods such as SCRUM or design thinking: it starts at the organizational level and thus influences the understanding of values among all employees. Changes to the organizational structure allow agile values such as trust, self-organization, transparency, and approaches such as minimum viable product (MVP) to 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 principles.

Our OKR services: How we support you
OKRs form the foundation for establishing agile values throughout the corporate culture.
OKRs change company values and employee mindsets, and this change must be professionally supported. We support companies in all strategic and operational steps involved in implementing 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 work and become part of the culture. With our change expertise, we ensure that the OKR philosophy is positively received and embraced by the employees involved.

1. Analysis of the status quo
1.1 Analysis of the current situation in the company, departments, and teams
1.2 Coordination of the goals to be achieved with the introduction of OKRs
2. Define vision and OKRs
2.1 Develop an overarching vision and use creative workshop methods
2.2 Joint development of OKRs
3. Setting up the OKR cycle
3.1 Setting up a quarterly cycle with the necessary processes, roles, templates, and tools
4. Empowering employees for individual OKRs
4.1 Introducing employees to OKRs and creating understanding
4.2 Methodological empowerment and training
4.3 Personal coaching on demand
5. Focus employees on 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
6. Measure, manage, and document progress.
6.1 Support the OKR cycle as OKR Master and Office
6.2 Create transparency about status and progress
6.3 Moderate status updates and retrospectives
6.4 Documentation
OKR benefits that we achieve together with our customers:
Transparency:OKRsallowyoutosee what employees in the company are working on and what progress they are making. This transparency promotes collaboration and communication about successes and problems.
Focus:Limiting the number of objectives to a maximum of fivealsopromotes discussion about what employees will focus on in the coming weeks and the direction they want to take. Communication no longer takes place only at the management level, but together with all employees. This strengthens the "sense of unity."
Contribution to the company goal: Whilegoals are traditionally broken down and delegated top-down, OKRs help employees learn to identify their own contribution to the goal independently. Everyone considers the added value they can achieve with their work for the overall goal.
Contributing your own strengths: TheOKR framework offers employees the opportunity to support the company in areas 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:The short 3-month cycle and openness to adjustments to key resultsallowthe companytoremain flexible. At the beginning of each quarter, all employees re-examine which topics are relevant for the next cycle. Employees continuously engage with the successes and challenges of their company.
Ambitious goals: Goalsare set ambitiously and challengingly in the OKR framework – at the company, team, and employee levels. Employees learn to deal with ambitious goals. Even a 60-70% achievement rate is considered a success. If goals are not achieved, the teams examine the causes and learn from them for the next cycle.
What is Scrum?
The following information is based on the Scrum GuideTM, enriched with practical experience from 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 Moderator"
3. Development Team – "The Creators"
Artifacts
1. Product Backlog – All features 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 during the sprint
2. Daily Scrum – Keeping team members informed 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 more of a framework than a process or technique and is the most popular of many agile methods. People can tackle complex adaptive problems while delivering products with the greatest possible value in a productive and creative manner. Scrum uses an iterative, incremental approach to optimize predictability and risk control. 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. All participants can see and understand what is happening 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 a common goal.
REVIEWThe entire Scrum Team must regularly review all project variables such as processes, techniques, products, team attitudes, etc., in order to identify any undesirable deviations from the Sprint Goal.
ADJUSTMENTBased on the results of the inspections, all project variables are adjusted for continuous improvement. Adjustments must be made as quickly as possible in order to minimize further deviations and ultimately maximize the business value of the product.
Scrum values
Courageis a quality of the 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.
Opennessis characterized by an attitude of accessibility, without concealment or secrecy. Everyone should know everything about the work during a Scrum implementation.
Respectrefers both to a positive attitude toward a person or other entity and to authentic behavior in accordance with this appreciation. Without respect, there would be a high potential for miscommunication, low communication frequency, and hurt feelings.
Focusis the concentration of attention. People who are not focused do not pay attention in any meaningful way and cannot learn to a meaningful degree of depth.
Commitmentmeans committing oneself to a course of action. When people cannot commit themselves, they find themselves in a state of limbo, a state of inactivity.
Scrum Roles & Responsibilities
Product Owner
... is responsible for coordinating with the various stakeholders. The entire company must respect their 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 remains accountable.
Product Backlog
1. Creation, maintenance, and description of the product backlog
2. Prioritization of product backlog entries 3. Ensuring that the product backlog is transparent and visible.
4. Ensuring that the Development Team has the correct understanding of the Product Backlog Items
Sprint Planning
1. Discussing the goal that the Scrum Team should achieve in the Sprint
2. Assisting in understanding the selected items from the Product Backlog and making compromises.
Sprint Review
1. Inviting the Scrum Team to the Sprint Review Meeting
2. Explaining which Product Backlog items are done and which are not done
3. Presenting the current backlog status and predicting the expected target and delivery date
Scrum Master
… is a servant leader for the Scrum team.
… is responsible for removing obstacles to the progress of the development team.
… should work with the Scrum team and the organization to increase transparency.
Sprint Planning
↓
Daily Scrum
↓
Sprint Review
↓
Sprint Retrospective
1. Supporting the Scrum process
2. Ensuring that Scrum events take place and that the team understands their purpose
3. Coaching the Scrum team to adhere to the rules
4. Collaborating with other Scrum team members to understand the execution of the sprint and review the performance and progress of the sprint
Product Owner
1. Teaching techniques for managing the product backlog
2. Teaching an understanding of the need for clear and concise product backlog items in the Scrum team
3. Creating an understanding of product planning in an empirical environment
4. Ensuring that the product owner knows how to order the product backlog to maximize value.
5. Communicating an understanding of agility 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 developing high-quality products
3. Removing obstacles that prevent the team from making progress
4. Facilitating Scrum events as requested or needed
5. Coaching the team in an organizational environment where Scrum is not yet fully accepted 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. Initiating 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 function in a self-organized and interdisciplinary manner.
3. The team independently decides on the work tasks for the next sprint and the estimated effort for each task.
4. There are no titles in the team and no further subdivisions 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. Defining the tasks in the sprint backlog
2. Deciding how the sprint goal and sprint backlog can be converted into a finished ("done") product increment.
3. Self-organizing to complete the work in the sprint backlog.
Daily Scrum
1. Responsible for conducting the daily scrum
2. Review of progress towards the sprint goal
3. Frequent meeting after the Daily Scrum: detailed discussions, adjustments or rescheduling of 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, identified problems and solutions
Stakeholders
(Not an official Scrum role according to the Scrum GuideTM) Due to the individual nature of each project, there can be significant differences in the importance and influence of stakeholders. There are likely to be 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: Individuals/groups who make the financing decision for product development (typically managing directors or budget managers).
2. External: Individuals/groups/organizations who pay for the use of the product (only applies to externally sold products).
End user
1. Is the most important source of information when defining requirements.
2. Is the protagonist in most user stories; reviews the increments (passively, based on user stories).
3. Use of the end product
Manager
1. Provision of resources and guidelines within the organization
2. Resolution of issues escalated by the Scrum Master.
3. Is the final authority on issues.
Scrum artifacts
Productvision
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 highlight its unique value.
3. The product vision should be created before the product backlog.
4. The product owner is responsible for the product vision and its updating.
Template for creating a vision statement (according to Geoffrey A. Moore)
There are a number of aspects that should always be considered in a correct vision statement:
FOR "Target Customer"
THE "NEEDS"
THE "PRODUCT NAME"
IS A "PRODUCT CATEGORY"
THE "PRODUCT BENEFIT/ REASON TO BUY"
DIFFERENT FROM "COMPETITORS"
OUR PRODUCT "DIFFERENTIATION/ PROMISE"
Elevator Pitch
The best way to validate the product vision is to conduct an 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, compelling, 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 comply with the Scrum Team's Definition of Done.
2. If the development team has planned and estimated well, the product increment contains all items from 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 ofthedesiredfunctionality
.
1. User stories are written from the perspective of the person who benefits from the implementation of the user story.
2. The user story is written in the format:"As [WHO], I want [WHAT] so that [reason]."
Characteristics of a good user story
Independent
Negotiable
Valuable
Estimable
Small
Testable
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 to the entire Scrum team and is used to decide when a user story from the sprint backlog is complete.
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 in order to consider the user story 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.
2. While 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. "Home button is recognizable."
Story Points
Unit for estimating the total effort of a product backlog item.
1. The Scrum Team estimates the effort required to implement the user story, including everything that may influence the effort (workload / complexity of the work / risk or uncertainty in performing the work).
2. Instead of story points, user stories can also be estimated in other units, e.g., T-shirt sizes S/M/L/XL.
Planning Poker
Agile estimation and planning method used to estimate the effort or relative size of backlog items.In Planning Poker, group members make estimates by playing numbered cards 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 to the team or describes a feature.
2. The team discusses the feature and asks questions that the product owner must answer.
3. After the discussion, each team member places a card face down representing their estimate for the story.
4. All cards are revealed at the same time.
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 estimates.
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).
2. The 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 plan the next to-dos for the sprint.
1. Ideally, a task should be sized so that it can be completed by the next Scrum meeting.
2. Clear responsibilities are defined for each task.
3. Unlike user stories, tasks are defined by the people who do the work—the development team.
4. 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" the work when 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
One way to track Scrum sprints and the implementation progress of agile projects.
1. The team estimates the hours required to complete each task at the sprint planning meeting.
2. The Scrum Master calculates the outstanding work, displays it graphically, and compares it with the estimate.
3. The outstanding work (or backlog) is often plotted on the vertical axis, with 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 upcoming Sprint based on their capacity.
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 short 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.
3. The team reviews progress toward 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 prevent us from achieving the sprint goal?"
Backlog refinement
Supports the preparation and updating of the product backlog for the next sprint planning meeting.
Backlog refinement should take place continuously during each sprint. The goal 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. Defining acceptance criteria and story size
4. Updating the prioritization of user stories
Backlog refinement helps prepare the user stories so that the next Sprint Planning meeting can begin immediately with clear and well-defined items.
Sprint Review
The development team demonstrates the increment that was developed during the sprint, and this is evaluated against the sprint goal.
1. Only results that represent a "potentially deliverable product increment," such as coded, tested, and usable software, are presented.
2. In addition to the Scrum team, stakeholders should also participate in this informal meeting.
3. Stakeholders can provide feedback to the development team, which is then added to the product backlog as a new user story.
Sprint Retrospective
The meeting enables the Scrum team to continuously review and improve itself throughout 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 in terms of the people, relationships, processes, and tools involved.
2. identify the most important elements that went well
3. uncover potential for improvement, prioritize it, and create a plan for its implementation
Pitfalls
The role of the product owner is not well defined or is not being fulfilled.
Symptoms
1. Stories are often not completed ("done").
2. The product owner is not available to answer questions from the team.
3. The team receives conflicting messages from different sources.
Suggested measures
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 stakeholders.
The team does not invest enough time in refining the backlog.
Symptoms
1. The sprint planning meeting takes a very long time.
2. Stories are difficult to estimate.
3. Stories are not finished ("done") at the end of a sprint.
Suggested measures
1. The Scrum Master should organize regular backlog refinements to discuss upcoming user stories.
2. The Product Owner should coordinate with stakeholders in advance.
3. The Product Owner should participate in backlog refinement to discuss upcoming work with the team.
Stories are not sufficiently broken down or are 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 respond to stories immediately.
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 being managed by someone else
Symptoms
1. Stories are not completed or only started at 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 determine an average velocity.
2. Only the team estimates the work and specifies 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 arise around a single team member.
3. One person or group works overtime to keep up with demand in the allotted time.
Suggested actions
1. Encourage collaboration on stories to improve the quality of the final product.
2. Product owners should write stories that offer the opportunity to pair up.
3. Train the team in skills; subject matter experts work with one or two team members to acquire new skills.
Additional work interrupts the sprint
Symptoms
1. The team recognizes significant unplanned work or receives requests from stakeholders that must be completed immediately.
2. Planned stories are not completed.
3. The team feels that priorities are constantly changing.
Suggested actions
1. Include sprint buffer 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.