Agile Consulting: Guidance for Agile Transformation

Agility stands for the ability to respond quickly and at the same time appropriately to a complex and dynamic environment, often in the form of customer requirements. Agility therefore means nimbleness, or – quite simply: vitality.

Agile companies have understood that they operate in an increasingly complex environment and must therefore adapt to new conditions at an ever faster pace. In response, they mirror the dynamics of their environment in their own organization – and in some cases even manage to make the market itself more dynamic. Typical characteristics often include a strong customer focus, short, iterative planning and development cycles, flat hierarchies and a high degree of self-organization.

Why do we consider agility important?

Many companies are currently feeling the pressure of an increasingly dynamic market environment in which they need to stay competitive:

01. Digitalization enables disruption that pushes existing technologies, products and services out of the market in next to no time. New players are challenging established companies. When accumulated knowledge and company size no longer create a lasting competitive advantage, innovation and agility become enormously important.

02. The growing number of uncertainties in the market inevitably increases the pace at which companies have to make decisions and adapt to changing conditions. Predictability is declining: whereas projects used to be planned and rolled out waterfall-style over several years, short, iterative cycles are now what is needed – the shorter, the better.

03. Seeing how their own work contributes to the company's value creation is increasingly becoming a key motivating factor for employees. Being steered by others and lacking a sense of self-efficacy destroy motivation and drastically reduce agility and innovative strength.

In 2001, 17 renowned software developers published the Agile Manifesto (officially the Manifesto for Agile Software Development). Its original signatories included the two founders of Scrum, Jeff Sutherland and Ken Schwaber. Since then, thousands more signatories have joined them, publicly committing 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 statements 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. A working product is more important than comprehensive documentation
3. Responding to change is more important than following and working through a plan
4. Customer collaboration is more important than contract negotiation

The four guiding statements are made more concrete 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, valuable products.
2. Welcome changing requirements, even late in development.
3. Deliver work products regularly, within a few weeks or months – the shorter the timescale, the better.
4. Business people and developers work closely together every day
5. Build the project around motivated individuals who are given the environment, support and trust they need.
6. Convey and share information through face-to-face communication.
7. Working products are the primary measure of progress.
8. Maintain a constant pace.
9. Pay continuous attention to technical excellence.
10. Simplicity is essential.
11. Teams are self-organizing.
12. At regular intervals, teams reflect on how they can become better and adjust their behavior accordingly.

Definition and meaning of “agile transformations”

The term “agile transformation” describes the journey 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 hold its own in a VUCA world. Agile transformation is a change process that companies do not go through overnight. After all, for an organization to work in a truly agile way, it takes far more than methodological skills and shorter planning cycles. Much more decisive are the conditions under which value creation takes place in the company. They determine which behavior is opportune when, what the organization expects of its employees and which boundaries must not be crossed.

Why do agile transformations fail?
It is often precisely these conditions that become the critical success factor – and on which many agile transformations founder. Structural elements such as reporting and approval processes, steering and planning machinery, or internal performance incentives and appraisals can either hinder agile value creation or make it truly possible in the first place. They are the biggest lever for deliberately breaking up the fusion of value creation with an organization's values and principles and reconnecting them in a new way. Understanding how this can succeed starts with one fundamental insight:

At the heart of an agile transformation are not methods or frameworks, but first and foremost the values and principles that govern collaboration.

The reason: every single one of the well-known, widely promoted agile methods emerged from the consistent application of these values and principles to a specific business case – be it Scrum for project work, Kanban for service functions or Lean Startup for testing new business ideas. Visualization and estimation techniques such as burndown charts or Planning Poker followed.

Unfortunately, agile transformations all too often focus on precisely these methods and techniques instead of starting with the values and principles. However, any method – no matter how fashionable – can only be applied successfully by an organization if the organization follows the same agile values and principles on which the method is based. If it does not, the method will not only remain ineffective but, in the worst case, do damage. An organization's guiding values and principles, in turn, are laid down in its culture, which shapes behavior and steers decisions like an invisible hand. So anyone who talks about sustainable agile transformation is automatically always talking about cultural transformation as well. Agility therefore 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 its immune system, which tries to secure the organization's survival in the future by replicating what was successful in the past. Culture is reflected throughout the organization: in processes, organizational charts and rules that have proven helpful over decades. To change an organization's culture sustainably, it is not enough to proclaim new values and paper the corridors with posters – just as it does little good, at a concert where the mood is flat, to use a teleprompter to move the audience to genuine enthusiasm. Even when the very last employee is convinced of the effectiveness of agile values and principles, the organization's processes and structures often act like a layer of clay. Only by deliberately questioning processes, decision rules, organizational charts, etc. can the existing conditions for collaboration be analyzed in small iterations and changed in a targeted way, and the organization's agility increased. Each iteration thus makes it possible to gain new experiences that become part of the cultural memory and lead to lasting change.

1. Recognize patterns
An iteration begins with the question of the value-creation mandate and where the current organization is getting in its way. As a first step, we observe how people work together in order to recognize critical patterns and thereby identify starting points. A swing makes a good illustration: to speed up or slow down a child who is already swinging with the desired effect, you first have to observe the pattern in which the swing is moving. Only then can you give the push at the right point and at the right moment to increase or reduce the momentum as desired. In the same way, our first step is to observe and analyze the existing organization and its patterns. Example: A client's HR department has two value-creation mandates. On the one hand, it is responsible for administrative tasks such as contracts, employment references, the onboarding process, etc. On the other, it is supposed to design individual employee development measures. Internal customers have repeatedly been dissatisfied with the latter in the past. The department's employees are used to leaving decisions of a certain scope to their formal line manager. During our observation, we notice that, because of their formal decision-making authority, the manager has become a strong second point of reference in the employees' daily work, alongside the actual customer.

2. Form a hypothesis
In the next step, we relate the recognized pattern to the value-creation mandate and formulate a hypothesis about the influence the organization has on value creation. We look for a reason why the work is not succeeding as intended. In our example, we recognize that the employees are developing employee development concepts that primarily reflect the manager's ideas. As a result, customer focus takes a back seat and the value the concepts create suffers. We hypothesize that this part of value creation would be more customer-centric without formal power structures and would therefore produce better results.

3. Break the pattern
Based on this hypothesis, we work together to find a suitable lever for breaking the recurring pattern. What is needed is an organizational intervention – a kind of experiment in which new things are tried out and different experiences are gained over a predefined period. This is the only way mindsets and beliefs can change – with a direct impact on the underlying culture. Sustainable change requires targeted disruptions of the existing organization. In our example, we disrupt the department's existing organization by almost completely eliminating the manager's influence for the duration of the next employee development concept – from clarifying the assignment through to completion. We limit reporting, give the team full budget responsibility and let them make every decision on their own, with no way for the manager to intervene. The manager's only task is to create the safe space this requires. We accompany both the team and the manager throughout the pilot to prevent relapses into old patterns of behavior.

4. Evaluate results
Once the experiment is complete, we review what has changed. Did the lever have the desired effect? What of the things we tried do we keep, and what needs to be rethought or adjusted? Could this also be a lever for other areas? Or do we need to test something completely different after all? In our example, it worked. Despite initial uncertainty, the team reports powerful and effective collaboration in which they organized themselves autonomously and focused exclusively on the customers' wishes and needs. The result is a product that delights customers and delivers real added value. Important: there are no blueprints and no best practices for agile transformations. The successful experiment merely shows that the identified lever worked in this particular environment with this particular team. Transferring it to other teams and areas always first requires a hypothesis of its own and a new experiment – even if experience already gained speeds up the observation process and often decisively improves the accuracy of hypothesis formation.

Toward an agile organization with the Transformation Loop

As our client's example shows, change confronts organizations with complex challenges, and meeting them requires a well-thought-out approach. Converting an organization into an agile organization therefore means uncertainty, and it must be done holistically to achieve its full effect. Our iterative, experiment-based approach enables incremental improvement. Nevertheless, we need a structured approach to keep track of the big picture and recognize successes. The following approach, both structured and iterative, makes exactly this possible and is able to respond to evolving transformation conditions: the Agile Transformation Loop. The Agile Transformation Loop describes an approach modeled on Scrum and enriched with aspects from our many years of change management experience. It consists of successive phases that build on one another and is based on a continuous learning and development process that gives the iteration “recognize patterns – form hypotheses – break patterns – evaluate results” a structured framework.

Preparing the agile transformation approach

Getting an agile transformation off the ground requires structural groundwork. Its basis is formed first by the steps “recognize patterns and form hypotheses”, which analyze the existing organization and its patterns. These patterns are set in relation to the value-creation mandate so that we can derive hypotheses, which in turn lay the foundation for what we call the Transformation Backlog. You can think of the Transformation Backlog as a guiding list of items to be tackled on the path to an agile transformation. Beyond that, of course, you need a team to drive the agile transformation in the company. For this, we rely on a Transformation Team made up of different roles. The Main Sponsor acts as the Transformation Owner, the voice of the customer “organization”, and bears overall responsibility for the transformation. They are supported in particular by the Transformation Master, who guides the team and, indirectly, the transformation initiative in terms of process. Together, they support the Transformation Core Team in implementing the various steps on the way to an agile organization. Furthermore, the transformation approach is based on sprints, whose length must be agreed in advance. In our experience, an iteration of 4 weeks makes sense.

Our consulting approach: More agility through networking and institutionalization

Our consulting projects typically start in one specific area of a company. The best conditions for making that area more agile exist when the mandate and the motivation for change come from the manager responsible for the area. Through coaching and operational support, we enable the area's managers to build an agile organization effectively from the inside out and to implement cultural change sustainably. We also bring extensive expertise in identifying value-creation levers and enable managers to keep driving cultural change forward step by step on their own.

How can an agile transformation in one area turn into a company-wide transformation that makes the entire company agile at its core?

The more seeds of the agile organization are sown in the company and connected with one another, the more experiences can be shared, lessons learned exchanged and common patterns – desired and undesired – recognized. With our many years of experience in sustainable change management, we bring the expertise needed to foster these dynamics and let them take on a self-reinforcing effect.

Many individual agile transformations, and open exchange about them, gradually bring the “Hidden Rules” and “Organizational Patterns” to light and institutionalize an agile organization. The company's culture is not turned upside down in the process. In our experience, many “Hidden Rules” and “Organizational Patterns” remain stable, while key rules and organizational structures that stand in the way of change and value creation are replaced in a targeted way. After all, agile transformation must never become an end in itself.

The first question must always be the value-creation mandate and which structures and conditions are currently hindering it. For us, genuine value creation therefore has 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 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 lasting economic success but also gives employees a sense of satisfaction, makes them proud and inspires them. That is what we stand for.

That is exactly why we have no blueprint for “the agile organization”. What we can offer you, however, is a proven approach to tackling an agile transformation successfully. Our experience with it has been extremely positive. Whether as coach, consultant, trainer, sparring partner or co-pilot: together, we find out what is needed – and we bring plenty of tools with us.

Modern leaders create an environment in which precisely this innovative energy can flow – so that innovative ideas can emerge within their own company – by empowering employees, fostering a culture of experimentation and learning, and actively developing their own leadership team.

How leaders can best support employees
If you look at modern organizations – be they organizations run on holacracy or the companies Laloux describes in his bestseller “Reinventing Organizations” – as a leader you may well ask yourself where there is still room for leaders in these organizations. First of all, we would like to make a clear recommendation about what leaders should not do – and that is take on the role of Product Owner or Scrum Master. A common mistake in agile transformations is simply transferring the existing hierarchy 1:1 into the new organizational form. The Product Owner is still “the boss” who decides on the prioritization and content of each sprint. The Scrum Team is then merely the executing force. So the teams get more modern names – be it Scrum Team, squad or tribe – but nothing changes in terms of responsibility. Quite the opposite. Leaders' subject-matter responsibility often increases as a result; they become a bottleneck and, on top of their existing management topics (which often do not go away), cannot find the time they need for their subject-matter topics. Instead of the hoped-for increase in productivity, the new organization becomes slower and agility is tainted for many people. So what should leaders do instead? Management tasks still exist!
One major task for leaders is to redesign the organization together with their employees and to decide which tasks and topics actually need agility and which ones call for stability and process excellence.
This form of organization is often described as organizational ambidexterity or a dual operating system. In fact, it is entirely logical – not all employees have to spend all day solving complex tasks in a highly innovative way. Some processes simply have to run without being reinvented every day. Quite the opposite: the more smoothly these processes run, the more efficiency can be increased. Where it makes sense, these processes can then be digitalized step by step. First, however, they must be standardized and optimized – classic management, and a valuable task for people who like working in stable environments.
Enabling people to take on responsibility
Self-organization means above all taking responsibility for oneself, the team, decisions and results. Even when they are allowed to decide for themselves, many employees feel the need to cover themselves as well.
A key task of an Agile Leader is to enable their team to take on responsibility themselves. A common mistake here is to hand over all responsibility at once, from one day to the next – this usually fails, not least because employees are not even in a position to make all the decisions themselves. Usually they do not have all the information, as they do not sit on the same committees as their managers.
A good approach is to discuss with the respective employees, task by task, to what extent the leader still needs to be involved – and to change this step by step.
1. For example, the leader can first ask the employees for their opinion but still make the decision themselves in the end.
2. In the next step, this can be reversed – the leader shares their opinion with the employees but leaves the decision to them.
3. A further step is to be available only for employees' questions until they have built up the necessary decision-making competence themselves – including the necessary sources of information – and can now make the decision entirely on their own.
04. In the final step, the leader no longer even needs to be informed – the decision has become entirely the employees' business.
How this process unfolds and how long it takes to reach the last stage – and whether that stage is desirable and sensible at all – depends entirely on the task and the employees in question.
One foundation for this, of course, is to actively provide employees with all the information they need for efficient decision-making – even if this means leaders no longer have an information advantage over their employees. That can be hard for leaders who have so far derived part of their standing simply from having more or different information than their employees.
Creating a fear-free environment in which it is safe to admit mistakes
“You learn from your mistakes”, “Fail fast, fail cheap” – mistakes seem to be more fashionable than ever. But is that really the case? Isn't success the only thing that counts in the end? Someone who has spent years doing everything to make the numbers add up or keep the project “green”, and has been successful doing so, will now find it hard to admit mistakes – and indeed, not every mistake is cause for

Nothing works without the right mindset

Lifelong learning and flexibility are paradise for curious people who do not want to tie themselves down at the start of their careers. But what about those who grew up over many years in systems that rewarded meeting fixed competence levels? That promoted those who fit perfectly into a template? Or at least those who successfully pretended to? As a leader, where do I get my raison d'être if I no longer know more than my employees?

The shift to an agile corporate structure poses major challenges for leaders in particular – not least because agile methods usually do not provide for explicit leadership roles at all. Embracing this change takes strong self-confidence – and appropriate change management. That is why it is essential to support leaders in these areas as well, rather than simply trying to “teach” them a new leadership style.

What changes for leaders, and how do they bring their people along in the right way?

Change management is often left out of agile transformations. The need for change seems all too obvious – after all, who wants to lead like the great industrialists of the 19th

century? Besides, agile working sounds like a lot of fun – Planning Poker, Fuck-Up Nights and hackathons, accompanied by modern office design and flexible working. Isn't this the change we have all been waiting for for years? Why would you need change management for that? Or to put it another way: if it is that easy, why do so many agile transformations fail?

Leaders, too, 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 authority? What will my future role as a leader look like? Will my employees still respect me? Leaders react to change with shock and grief just like other employees.

Previous skill profiles provided a clear framework of which skills you needed for which activities. This certainty is now gone, but that also offers the opportunity to finally focus on your own strengths instead of squeezing yourself into fixed templates. To do so, however, you need to know who you are and what you can do – but also who you are not and what you cannot do. Owning up to your strengths and weaknesses is a completely new behavior in many organizations, and it can be deeply unsettling. How much weakness is allowed, and at what point do you break the rules of the system you are, after all, still working in?

Only once leaders have mastered this change for themselves can they guide their employees through it and explain authentically what supposed buzzwords such as “fail fast” actually mean. To embrace the change, they must be able to trust their own managers. It is not enough to demand and permit a new understanding of leadership only at the lower levels of management.

Among other things, this requires top management to champion a shared change story – and to genuinely stand behind it. Lip service is quickly seen through. Every member of top management must be able to explain credibly why a new leadership style is necessary, what advantages it brings, what exactly it means for the organization and how the organization will reach 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 employees' individual strengths and weaknesses profiles?

6. Who is allowed to decide what on their own? Who gets promoted, and why?

8. What career paths do we offer our employees?

9. What is this thing called agile leadership?

Of course, having a shared understanding is not enough – each leader, including those in top management, must lead by example, actively apply the new leadership behavior and regularly ask for feedback on their leadership style.

The path to an agile organization thus becomes an exciting journey for everyone involved, one that offers plenty of opportunities.

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 consists primarily of three core elements: measurability, flexibility and transparency. OKRs are not, however, a leadership method.

Measurability

The Objectives describe the company goals being pursued. 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. As a result, companies set their focus several times a year and can therefore 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 every team and every individual employee are then linked to those of the company. In the end, there is clarity about who contributes to the company's success with their goals, 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. The framework was originally applied for the first time at Intel in the 1970s by Intel CEO Andy Grove, as an extended Management by Objectives (MbO) concept. With his further development of MbO, Grove wanted to ensure that Intel's focus was on its most important goals. John Doerr then brought the framework from Intel to Google in 1999 in his role as an investor. Google founders Larry Page and Sergey Brin did not adopt the framework 1:1, but extended it with one more cornerstone: the measurability of progress.

Why are OKRs important?

The company vision is typically a short, concise sentence describing where the journey is heading. For many employees – and even managers – it is rather vague, however. The OKR framework gives companies the opportunity to make the vision concrete and easier for all employees to understand. This creates transparency about 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 for 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 exactly we want to achieve. The Key Results quantify the respective Objectives. They are success drivers, make progress measurable and describe how we want to achieve our goals.

OKRs foster an agile mindset

Every company's culture can be described in three layers: the top layer (behavioral culture) describes employees' outwardly visible behaviors. The middle layer (value culture) contains the collective values and norms in the company that lead to the behaviors people actually display. The bottom layer (organizational structure) results from the existing processes, organizational charts and rules in the company.

Change works from the bottom layer up. 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. Here, the OKR framework for leading employees has a major advantage over other agile methods such as Scrum or Design Thinking: it starts at the organizational level and thereby influences all employees' understanding of values. By changing the organizational structure, agile values such as trust, self-organization and transparency, and approaches such as the Minimum Viable Product (MVP), can be anchored in the company's value culture. In this way, OKRs help to establish agile ways of working such as Scrum sustainably: Scrum Teams can follow the method without restriction and do not have to justify their new understanding of values anew every day. Because the higher levels of the hierarchy and neighboring departments now work according to the same basic agile principles.

Our OKR services: How we support you

OKRs form the foundation for establishing agile values across the entire corporate culture.

OKRs change a company's values and its employees' mindsets, and this change needs to be guided professionally. We support companies in every strategic and operational step of implementing the OKR framework – from analyzing the status quo to accompanying the first OKR cycles. Our focus is on familiarizing employees with the OKR framework and getting them excited about it, so that agile thinking can be integrated into everyday work sustainably and become part of the culture. Our change expertise ensures 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, the departments and the teams
1.2 Alignment on the goals to be achieved by introducing OKRs

2. Defining the vision and OKRs
2.1 Developing the overarching vision using creative workshop methods
2.2 Developing the OKRs together

3. Setting up the OKR cycle
3.1 Setting up a quarterly cycle with the necessary processes, roles, templates and tools

4. Enabling employees to set individual OKRs
4.1 Introducing employees to OKRs and building understanding
4.2 Methodological enablement and training
4.3 Personal coaching on demand

5. Focusing employees on the OKRs
5.1 Creating regular anchor points
5.2 Supporting employees in defining their OKRs so that individual, team and company goals are consistently linked

6. Measuring, steering and documenting progress.
6.1 Accompanying the OKR cycle as OKR Master and OKR Office
6.2 Creating transparency about status and progress
6.3 Facilitating status updates and retrospectives
6.4 Documentation

OKR benefits we achieve together with our clients:
Transparency: With OKRs, you can see what employees in the company are working on and what progress they are making. The resulting transparency fosters collaboration as well as communication about successes and problems.
Focus: Limiting the number of Objectives to a maximum of 5 also encourages discussion about what employees will concentrate on over the coming weeks and which direction they want to pull in. Communication no longer takes place only at management level, but together with all employees. This strengthens the sense of “we”.
Contribution to the company goal: Whereas goals are traditionally broken down top-down and delegated, OKRs help employees learn to identify their own contribution to the goals. Everyone considers what added value their work can create for the overarching goal.
Bringing in your own strengths: The OKR framework gives employees the opportunity to contribute 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 cycle of 3 months and openness to adjusting the Key Results keep the company flexible. At the start of each quarter, all employees once again consider which topics are relevant for the next cycle. Employees engage continuously with their company's successes and challenges.
Ambitious goals: In the OKR framework, goals are set to be ambitious and challenging – at company, team and employee level. Employees learn how to handle ambitious goals. Even an achievement rate of 60–70% counts as a success. When goals are not achieved, teams look into the causes and learn from them for the next cycle.

The following information is based on the Scrum Guide™, enriched with our consultants' practical experience.

The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts and rules. Each component within the framework serves a specific purpose and is essential to Scrum's success and usage.

Scrum is
1. lightweight
2. simple to understand
3. difficult to master
Roles
1. Product Owner – “The Shaper”
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 built during the Sprint.
3. Increment – Potentially releasable part of the product
4. Definition of Done – When the product is ready for use.
Events
1. Sprint Planning – Prioritizing and defining the features to be built in the Sprint
2. Daily Scrum – Keeping team members continuously informed about progress
3. Sprint Review – Presenting the Sprint's work results
4. Sprint Retrospective – Reflecting on the team's way of working

Scrum theory
Scrum is a framework rather than a process or a technique, and it is the most popular of many agile methods. Within it, people can address complex adaptive problems while productively and creatively delivering products of the highest 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 comes from experience, and decisions are made based on what is known.

Scrum process

Scrum is built on three pillars:

TRANSPARENCY
Everything about the project is visible to everyone. All those involved truly see and understand what is happening during a Sprint and can predict what will happen in the next Sprint. More communication and mutual trust help the team work together toward the common goal.

INSPECTION
The entire Scrum Team must regularly inspect all project variables, such as processes, techniques, products, team settings, etc., to detect undesirable deviations from the Sprint Goal.

ADAPTATION
Based on the results of the inspections, all project variables are adjusted for continuous improvement. An adjustment must be made as quickly as possible to minimize further deviation 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 expose problems, recognize impediments, ask for help, accept help and offer help.

Openness is characterized by an attitude of accessibility, without hiding anything or being secretive. During a Scrum implementation, everyone should know everything about the work.

Respect denotes both a positive attitude toward a person or another entity and authentic behavior in keeping with that esteem. 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 do not pay attention in any meaningful way and cannot learn to any meaningful depth.

Commitment means binding yourself to a course of action. When people cannot commit, they remain in a state of limbo – a state of inaction.

Scrum roles & responsibilities
Product Owner
… is responsible for aligning with the various stakeholders. The entire organization must respect their decisions.
… should have full decision-making authority to reduce the risk of unnecessary delays.
… is the only person who places requirements on the Development Team.
… is the only person with the authority to cancel the Sprint.
… may delegate management of the Product Backlog to the Development Team but always remains accountable.
Product Backlog
1. Creating, maintaining and describing the Product Backlog
2. Prioritizing the Product Backlog items 3. Ensuring that the Product Backlog is transparent and visible.
4. Ensuring that the Development Team has the right understanding of the Product Backlog items
Sprint Planning
1. Discussing the goal the Scrum Team is to achieve in the Sprint
2. Helping the team understand the selected items from the Product Backlog and negotiating trade-offs.
Sprint Review
1. Inviting the Scrum Team to the Sprint Review meeting
2. Explaining which Product Backlog items are finished (“Done”) and which are not (“Not Done”)
3. Presenting the current state of the backlog and forecasting the likely target and delivery dates

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. Supporting the Scrum process
2. Ensuring that the Scrum events take place and that the team understands their purpose
3. Coaching the Scrum Team to follow the rules
4. Working with other Scrum Team members to understand how the Sprint is being executed and to review the Sprint's performance and progress

Product Owner
1. Teaching techniques for managing the Product Backlog
2. Helping the Scrum Team understand the need for clear and concise Product Backlog items
3. Building 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. Conveying 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. Helping the team create high-quality products
3. Removing impediments that stand in the way of the team's progress
4. Facilitating Scrum events as requested or needed
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 its adoption of Scrum
2. Planning Scrum implementations within the organization
3. Helping employees and stakeholders understand and enact Scrum and empirical product development.
4. Causing change that increases the Scrum Team's productivity.
5. Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.

Development Team
1. The Product Backlog is the single collection of requirements to be worked through and implemented.
2. It should work in a self-organizing and cross-functional way.
3. The team independently decides on the work items 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. Individual team members may, however, have specialized skills.
5. The team should have between 3 and 9 members.
Sprint Planning
1. Defining the tasks in the Sprint Backlog
2. Deciding how the Sprint Goal and the Sprint Backlog can be turned into a finished (“Done”) product Increment.
3. Self-organizing to get the work in the Sprint Backlog done.
Daily Scrum
1. Responsible for holding the Daily Scrum
2. Inspecting progress toward the Sprint Goal
3. Frequent meeting after the Daily Scrum: detailed discussions, adjustments or replanning of the work in the Sprint
Sprint Review
1. Demonstrating the completed work to Product Owners and stakeholders and answering questions about the Increment.
2. Presenting what went well during the Sprint, identifying problems and their solutions

Stakeholders
(Not an official Scrum role according to the Scrum Guide™) Because every project has its own individual character, there can be major differences in the importance and influence of stakeholders. There are probably even more stakeholders than those described here. A detailed stakeholder analysis at the start of and throughout the project is therefore crucial to success.
Customer
1. Internal: people/groups who make the funding decision for product development (typically managing directors or budget holders).
2. External: people/groups/organizations who pay to use the product (applies only to products sold externally).
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. Uses the end product
Manager
1. Provides resources and guidelines within the organization
2. Resolves problems escalated by the Scrum Master.
3. Is the final authority on decisions.

Scrum artifacts
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 relates to the most important product goals and the customer, how the product can meet the customer's 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 for keeping it up to date.
Template for creating a vision statement (after Geoffrey A. Moore)
There are a number of aspects that should always be covered in a proper vision statement:
FOR “target customer”
WHO “needs”
THE “product name”
IS A “product category”
THAT “product benefit / reason to buy”
UNLIKE “competitors”
OUR PRODUCT “differentiation / value proposition”
Elevator Pitch
The best way to validate the Product Vision is to do the elevator pitch: “Can you describe your product in the time it takes to ride up in an elevator?” Passing this test ensures that your Product Vision is clear, engaging and brief.

Product Increment
The results of all Product Backlog items completed during a Sprint and all previous Sprints.
1. At the end of every Sprint, the new Increment must be finished (“Done”), i.e. it must be in a usable condition 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 in the Sprint Backlog.

Product Backlog
The Product Backlog is a prioritized list of short descriptions of everything that is known to be needed in the product.
1. should always contain enough requirements (often in the form of User Stories) to cover at least one, and 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 constitute the 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 benefits from the User Story being implemented.
2. The User Story follows the format: “As a [WHO], I want [WHAT] so that [REASON].”
**Characteristics of a good User Story
I** ndependent
N egotiable
V aluable
E stimable
S mall
T estable

Definition of Done
Agreed activities required to deliver a finished (“Done”) product Increment at the end of a Sprint.
1. The Definition of Done (DoD) must be unambiguous for 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. What matters is that each team has a shared 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, written 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. “The Home button is easy to recognize.”
Story Points
Unit for estimating the total effort of a Product Backlog item.
1. The Scrum Team estimates the effort of implementing the User Story, including everything that may affect the effort (amount of work / complexity of the work / risk or uncertainty in doing 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 technique used to estimate the effort or relative size of backlog items. In Planning Poker, group members make estimates by playing numbered cards whose values represent 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, which the Product Owner has to 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, it becomes the estimate for the User Story.
6. If not, team members with high and low estimates get the chance to explain their reasoning.
7. The estimation process is repeated until 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 needed to complete each User Story.
4. The predefined tasks are completed during the Scrum cycle.
5. The team adjusts the Sprint Backlog throughout the Sprint

Tasks
Breaking Product Backlog items down into tasks helps the Development Team plan the Sprint's next to-dos.
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. 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 the work and workflow that enables the team to optimize the flow of work.
1. Work items 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 “pull” work when capacity allows, rather than having it “pushed” into the process on request.
3. The Task Board should be updated during the Daily Scrums.

Sprint Burndown Chart
A way of tracking Scrum Sprints and the implementation progress of agile projects.
1. The team estimates the hours needed to complete each task during the Sprint Planning meeting.
2. The Scrum Master calculates the remaining work, plots it and compares it with the estimate.
3. The remaining work (or backlog) is often shown on the vertical axis and time on the horizontal axis.
4. In addition to planning and tracking, the chart also serves as a tool for risk reduction and communication.

Scrum events
Sprint Planning
A meeting at which 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 to the team (work for two Sprints).
2. the Development Team decides how many items from the Product Backlog can be delivered in the upcoming Sprint based on its capacity.
3. the Development Team asks enough questions to turn a high-priority User Story from the Product Backlog into the more detailed tasks of the Sprint Backlog.
Two artifacts result from a Sprint Planning meeting:
1. Sprint Goal: a short description of what the Scrum Team intends to achieve during a Sprint.
2. Sprint Backlog: a set of Product Backlog items and corresponding tasks to be implemented in 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 inspects 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 impediments that prevent us from achieving the Sprint Goal?”
Backlog Refinement
Helps prepare and update the Product Backlog for the next Sprint Planning meeting.
Backlog Refinement should take place continuously during every 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 start right away with clear, well-defined items.
Sprint Review
The Development Team demonstrates the Increment developed during the Sprint, and it is assessed against the Sprint Goal.
1. Only results that represent a “potentially shippable product Increment” are presented, e.g. coded, tested and usable software.
2. In addition to the Scrum Team, stakeholders should also attend this informal meeting.
3. Stakeholders can give the Development Team feedback, which is then added to the Product Backlog as a new User Story.
Sprint Retrospective
The meeting enables the Scrum Team to inspect and improve itself continuously throughout the project.
Every member of the Scrum Team should have the opportunity to voice their opinion in an open, honest and constructive atmosphere.
The Scrum Team should:
1. inspect how the past Sprint went with regard to the people, relationships, processes and tools involved.
2. identify the most important things that went well
3. uncover potential improvements, put them in order and create a plan for implementing them

Pitfalls
The Product Owner function is not well defined or not lived
Symptoms
1. Stories are often not finished (“Done”)
2. The Product Owner is not available to answer the team's questions.
3. The team receives different messages from different sources.
Suggested measures
1. Every team should have its own Product Owner.
2. All backlog items and tasks should be communicated to the team only through 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 in refining the backlog
Symptoms
1. The Sprint Planning meeting takes a very long time.
2. Stories are hard to estimate.
3. Stories are not finished (“Done”) at the end of a Sprint.
Suggested measures
1. The Scrum Master should organize regular Backlog Refinement sessions to discuss upcoming User Stories.
2. The Product Owner should align with the stakeholders in advance.
3. The Product Owner should take part in Backlog Refinement to discuss upcoming work together with the team.

Stories are not broken down sufficiently 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 right away.
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 length.
2. User Stories should follow the “INVEST” rule of thumb (independent, negotiable, valuable, estimable, small, testable).

The team is being steered by someone else
Symptoms
1. Stories are not finished, or are only started at the end of the Sprint.
2. The team works at an unsustainable pace to complete each Sprint and is under great pressure.
Suggested measures
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 states how much work / how many stories it can complete during a Sprint.
3. Align expectations of self-organizing teams with management and stakeholders.

The team works on the backlog individually
Symptoms
1. The team believes that each backlog item is worked on by only one person.
2. Bottlenecks form around a single team member.
3. One person or group works overtime to keep up with demand in the time available.
Suggested measures
1. Encourage collaboration on stories to increase the quality of the end product.
2. Product Owners should write stories that offer opportunities for pairing.
3. Train the team in new skills; subject-matter experts work with one or two team members so they can acquire new skills.

Additional work interrupts the Sprint
Symptoms
1. The team identifies significant unplanned work or receives requests from stakeholders that have to be dealt with immediately.
2. Planned stories are not completed.
3. The team feels that priorities are constantly changing.
Suggested measures
1. Include a Sprint buffer for ‘additional/discovered work’.
2. Use retrospectives to identify ways to better anticipate additional work.
3. Confront leadership with the impact of interruptions.
4. Empower the Product Owner in their role and protect the team from interruptions.