Since 2009, we have been showing companies how they can use agile management frameworks to develop their projects more reliably and quickly. That's what it has always been about, and that's exactly why my first book is called: Scrum – Developing Products Reliably and Quickly.

Whether they are clients from e-commerce, retail, automotive, finance, advertising, medical technology, or the NGO sector – many projects and teams have been established. We have helped develop mass spectrometers, vacuum valves, flight simulators, emergency call centers, e-commerce shops, web platforms, insurance products, and communication systems. Administrative and HR processes have been accelerated using agile methods, and large SAP implementations have been improved with the help of agile frameworks.

In the process, we have facilitated vision workshops, team-building measures, several hundred training sessions, certainly around 10,000 meetings, and hundreds of leadership teams. Thousands of people have been familiarized with agile methods through our training and introductory courses. Just imagine the number of task boards we have developed with our teams over the years – the sequence of the many physical and virtual boards would stretch for kilometers.

We have worked with large DAX corporations and small companies, with international medium-sized companies and medical technology start-ups in the UK. We worked with teams at home and abroad, with project teams spread over four levels, four buildings, but also four international locations, in projects with more than 250 people and with small teams of 3 people. With board members, teachers, scientists, and, of course, software developers.

To give you an idea of what these engagements involved – here are a few anonymized examples, as most companies prefer to keep things confidential. Where we have obtained permission and written case studies, you will find a reference to the case study.

Challenges and examples of our Engagement

The project manager of a large IT project called me and asked if it was possible to get 180 developers to deliver a product worth around 100 million euros within 9 months using Scrum. We made it happen: 3 months later, 180 developers were organized into 18 teams, delivering software every 4 weeks. 
 The Chief Marketing Officer was pleased, and the software went live after 10 four-week sprints.

The program manager of a development team working on one of the major international web portals for a client was at a loss. The coordination of his over 160 developers was failing. Communication with the client and among the team members was breaking down. Instead of delivering new features, they were spending more and more time fixing bugs.
One solution was one of the first Big Room Plannings ever done (it wasn't called that at the time – I called it Mass Sprint Planning). We had all the user stories on the wall, and I invented team synchronization during sprint planning. It was crazy – but it worked and later became the blueprint for all major implementations. We also supported the project with training and on-the-job coaching, improved the task boards, and coached the ScrumMasters . The key was: after just 4 weeks, the developers were delivering significantly more functionality again.  

A department head responsible for the support of a large SAP system which handled all customer data, contracts, and services – wanted greater transparency, better quality, and more reliable delivery. Six months later, 200 developers were working agile, delivering projects in a third of the time with fewer defects. Thanks to automated testing procedures, the quality improved dramatically.

Viva Con Agua hosts the Millentor Gallery every year.
They do a fantastic job, but the stress before the festival is immense, with everything depending on a few people. Afterward, everyone needs a long break. We supported the five-person team, developed new communication processes, and established a new management and delivery culture. The team, which grows to 150 people around the festival, was managed through clear processes and high transparency. The managing director was even unable to be present due to an accident in the last 10 days before the opening. It made a difference, but her team handled it so well that she could focus on her recovery. (Case Study in Progress)

In one production plant, it became clear that the production employees needed a way to communicate obvious errors during assembly. We worked with the IT team on-site, practically in the assembly hall, to develop a communication system iteratively and incrementally. We were able to prototype the solution in a few days and make it production-ready in a few weeks – a project that would normally take years.

A client wanted to know: How can we support IT companies in recruiting and integrating (female) foreign specialists? Specifically, from overseas, Africa, Asia, and South America.
We assembled a cross-functional team of young professionals from many countries in a remote working environment and moderated an innovation process with them. After 6 weeks, the team presented many tried and tested possibilities. This procedure was described in detail by our sister companies under the leadership of co-founder Andrea Kuhfuss in the book "Agile Innovation Sprint",  the result of this project can be read here. 
 

At KfW Development Bank, traditional working methods were reaching their limits. As a solution, we developed a new collaboration model (ZAM) called “Front-to-end” (FRED) with the implementation team, based on four clearly defined principles. We implemented it together with colleagues, trained employees in agile methods, and provided practical support to the teams. In 9 months, around 500 of the 800 employees participated in at least one training session, 40 team coaching sessions were conducted, and about 10 “Communities of Practice” meetings were organized. Additionally, FRED formed a transformation team with external consultants and the new innovation department to identify obstacles and drive the future direction of the transformation. Read more

In our project with the Raiffeisen Banking Group Austria, we supported the transition to a digital and customer-oriented banking structure. The goal was to digitally transform the bank, which has a traditional regional foundation, based on the vision “regional.digital.everywhere.” Through the implementation of a microservice architecture concept and intensive role coaching, we established agile processes. This included the shadowing concept for knowledge integration and regular review events for customer-oriented product developments. Within a year, we formed 15 Scrum teams  and trained internal Agile Coaches. The transformation culminated in the launch of the online banking solution “Mein ELBA” in 2017, a direct result of our agile methods. Read more

From April 2021 to May 2022, borisgloger supported the Webasto Group, an international automotive supplier with over 15,700 employees worldwide, in introducing an agile working model for product development. The goal was to improve the responsiveness and efficiency of the development sites. With our consultancy, Webasto iteratively developed a tailored and adaptable agile model called the “Webasto AHEAD Framework.” This framework was built on a theoretical foundation and continuously optimized during the pilot phase through practical experiences. The model allows Webasto to independently make future adjustments and continuously develop further. Read more

Back then, 65 developers at one of Germany's major start-ups were no longer delivering results. Everyone was working hard and was highly committed, but features were trickling out slowly, releases were unpredictable, and everyone was stressed. The CTO called me and asked what could be done. I asked him, "How brave are you? Should we switch everyone at once?" No one had done this before. Typically, you would proceed cautiously: start with one pilot team, then the next, and so on. We agreed to do the exact opposite: switch all teams at once. If we, as a consulting team, came in 14 days, the organization would be ready with the necessary infrastructure. And that's what happened: we trained the teams and all involved for one day and started. Three sprints later – after 6 weeks – everyone was convinced by Scrum. The testers were now part of the team, the marketing specialists were happy because their ideas were being implemented, and the best part: the features being delivered were of such high quality that no rework was needed. Shortly thereafter, the company was able to continue without our support.

A department of 150 people, responsible for developing software for a highly critical new infrastructure, couldn't complete their most important project. It was already several years overdue. Although parts of the product were already in use by customers, this added more stress because customers now wanted changes to the product. After several workshops, it became clear: we needed to completely reorganize the department. Here’s how we did it: in a 45-minute workshop, we asked the teams to self-organize into appropriate areas such as maintenance, new product development, and support. After 45 minutes, everyone had assigned themselves to the right areas, and we were ready to focus and get started. All I did was apply the Law of Two Feet principle from Open Space Technology.

Conclusion

These are just a handful of examples from hundreds of projects and thousands of problems we've solved as consultants.

Agile frameworks help us address the challenges our clients face, but they don't solve the problems on their own. It's the expertise of our consultant teams that helps clients focus, deliver the right solutions, and overcome the many obstacles that prevent them from working effectively. We've seen a lot and are eager to share our experience, going beyond simply teaching skills like how to conduct meetings.

We’re happy to discuss possibilities in person and work with you to find the solution to your challenge. There's usually no one-size-fits-all solution, but there are wonderful guiding principles that we've applied in the projects mentioned above.

The brief answer from consultants is often: It depends. Frequently, the issue is then reduced to the price of daily rates. This provides an initial guideline, but in truth, it says nothing about the costs an organization will face when they decide to have a team or department guided in an agile way.

The daily rate does not tell you what the project will ultimately cost, as it greatly depends on what is actually needed for this specific implementation.

Structure of services in an offer

Of course, this question can and must be answered and specified when creating an offer. To give an assessment, let’s look at the structure of the services in an offer:

1.     Clarification of the assignment: usually a workshop for larger projects

2.     Inventory: one or more workshops

3.     Training of all participants in the respective methodology: e.g., a ScrumMaster training or an agile intro training, 

4.     Support of a team over a period of 6 weeks

• This may quickly lead to 2 or 3 teams needing support.
• Many training elements might be added here.
• Additional skills may need to be procured.

5. Communication of the results to the company through a report or continuous communication support.

6. Working with the managers to achieve change here as well

• Training of managers/leaders
• Regular workshops or at least discussions during the project phase

7. Reporting/documentation of the measures

8. A Lessons-Learned and a Next Step Workshop at the end of the first 6 weeks.

9. Additional conversations and coordination meetings as needed

Anyone who reads through the above topics and briefly estimates the effort involved and considers the skills needed by the people who will carry out all this work will surely agree – it requires experience and training in more than just agile management.

This brings us to the answer why a qualitative agile implementation is indeed not available at a discount price.

Consultants who can carry out all this need:

1.     Skills & Experience in leading teams and large project organizations,

2.     The competence to conduct effective meetings, trainings, and workshops,

3.     The ability to build trustful collaboration within teams and with the rest of the organization,

4.     Knowledge on how to increase delivery capability and reduce technical debt, and

5.     A high level of problem-solving skills.

We employ staff who we have not only sent to internal training but also to external coaching and facilitation training. They are familiar with various agile management formats, can train them, and master collaboration tools like Slack, MS Teams, Zoom, Miro, Jira, Asana, and more. They also know how to visually prepare information for teams.

Therefore, to maintain our quality standard, we may need to charge between 40,000 and 50,000 Euros for supporting a single team over a period of 6 weeks. This does not place us at the top of the scale for consulting services of this scope, but we also do not offer our services at a discount price.

To get a bit more specific

Let's see how this number comes about.  In the initial phase of collaboration, the first 3 sprints (1 sprint =2 weeks), we provide full-time support to the team(s) by a ScrumMaster or Agile Coach, i.e. 4-5 days over a period of 6 weeks for a consultant.

This ensures the long-term and successful implementation of the agile working model at the operational level. In parallel, collaboration with the transformation team or management usually takes place at a strategic level to adapt and provide the organizational framework necessary for sustainable agile work. One of our transformation coaches works with the customer’s transformation team once or twice a week.

After this intensive initial phase, we assess: How far has the team come? Can we reduce the collaboration a bit? If so, support is reduced to about 2 days a week over the next 3 sprints.

For one of our clients, we worked with 8 leaders in many workshops for weeks to achieve a unified approach, and then worked with the 150 employees in further workshops. This process extended over several months.

Is it worth it for companies?

We believe so. In one of our client projects, within just 3 months, 3 of our consultants not only saved 400 person-days of planning effort per half-year but also reduced the project lead times of an organization with 200 employees by two-thirds, while simultaneously increasing quality and delivery reliability.

An investment in team performance can seem very high at first glance – which is why it is so important for our clients to know what to expect and for us to calculate the business case for the change.

We can only answer this question from our point of view, and therefore I apologize in advance that our perspective may not be entirely objective.

From Rigid Structures to Dynamic Flexibility: The Paradigm Shift in Management Consulting

Having experienced how traditional consultancies operated in the late 1990s and realizing that real change had to come from the people being advised – many concepts looked good on PowerPoint slides but missed the realities of the people in companies – I aimed to build a consultancy with borisgloger that not only conceptualizes but above all, implements.

We are doers. For us, this is still the core difference between classic consulting and our understanding of agile management consulting.

This difference is based on the deep insight that only customer systems can solve their own challenges, but their own processes, rooted in the industrial paradigm, stand in their way.

Over the course of many years of consulting, we’ve noticed that customer systemsdon't change because

1. There is no clear picture of where the journey is headed – there is still too little experience of what a modern organization can look like, and
2. secondly, there is a lack of know-how to break new ground. There is simply a lack of know-how to work with the new tools (Test Driven Development, Cloud, Microservice Architecture, MS Teams, Miro). This can be observed very well again in the fear of General AI. It's not because they know how ChatGPT and similar tools work, but because people in companies simply do not yet know how to use these new tools beneficially. A wonderful lecture on how AI becomes a colleague can be found here
   
   

We see the role of an agile management consultancy as combining these two aspects. On one hand, the change in the company must help make the organization functional again, and on the other hand, it must alleviate people's fear of embracing the change.

The traditional approach: A world of plans and forecasts

Traditional consulting has its roots in a world that values stability and predictability. Here, problems are identified through detailed analysis that leads to comprehensive solutions and long-term strategies. These solutions, often documented in extensive reports, follow a strict plan designed for efficiency and control.

Many companies pay consultants to gain insights about their competition – everyone knows the famous strategy of management consultancies that explain there is a so-called benchmark to follow. They pay well for these analyses.

Then, a strategy is created to explain exactly how what is to be achieved is to be achieved.

All of this follows the classic idea that an organization is clockwork that can be changed by using new gears and mobilizing people through new processes.

This follows the classic idea that an organization is like clockwork, which can be altered by using new gears and mobilizing people through new processes.

The process is hierarchical and top-down. After deciding how the organization should change, it is then demanded that others follow this new way. Success is measured by strict adherence to budgets and schedules, as well as the achievement of specific, predefined goals.

This approach has worked – if all companies are basically doing the same thing, you can orient yourself to the competition and try to do a little better what the others are doing.

The management consultancies that support this worldview operate internally just like their clients: hierarchical, with lower levels executing the plans of senior consultants.

The Agile Revolution: Flexibility and Iteration as the Key to Success

In contrast, agile consulting understands an organization as a system of communication where direct intervention is not feasible. Instead, the system must change itself through an iterative, incremental approach.

Of course, an analysis must first be conducted to understand the problem. But instead of comparing with others, we focus on whether the organization achieves its own goals and show how it can set and reach these new objectives.

This can be achieved by: 

• Proceeding with proven methods based on Design Thinking, involving as many people as possible to understand the problem (discovery) and engage everyone who will later shape the change.
• Conducting a Business Agility Vital Check, which is a quick and cost-effective survey for organizations to develop a sense of their issues. It’s structured similarly to a personality test.

After the analysis, however, the goal is not to develop comprehensive plans, but to solve the problems preventing the organization from achieving its own goals as quickly and effectively as possible.We rely on short-cycle sprints, enabling the organization to quickly respond to external influences and adapt its strategies accordingly. The focus is on adaptability and continuous improvement, not on following a comprehensive plan.

Collaboration and Change Management

This approach can only be successful with collaboration. Change and change management are integrated into the plan from the start. By iterating and incrementing, the organization also develops its products in this manner. Thus, the organization changes by delivering new results in a new way.

If the organization’s capabilities grow and align with this process, it transforms and the change is successful.

The role of employees: From Order Takers to Designers

In other words, the key difference in consulting lies in the involvement of employees. While classic consulting projects often have a clear separation between consultants and the client team, agile consulting forsters a collaborative culture during the change process.Everyone involved is actively engaged in decision-making, which increases acceptance of changes and improves the quality of outcomes.

Teams are empowered to act in a self-organized manner and participate directly in the development of solutions. The principle behind this is not theoretical persuasion, but active action & participation. Only those who have experienced how quickly projects can be delivered when focusing on fewer tasks at a time will understand. Nonaka called this implicit learning –new knowledge is created by doing instead of thinking and planning. We once called it: "Doing as a way of thinking" and we stand for exactly that with our slogan: Want.Do.Can

Dealing with Change: A Question of Perspective

Another fundamental difference is how we handle change. In traditional consulting, changes are often seen as a risk that needs to be minimized. Here, many managers are attracted to the blueprints offered by classic management consultants.
 
We are often asked what our standard model looks like, and when we respond, "There is no standard model because every company is different," many customers are dissatisfied. It’s challenging for us to deliver a blueprint because we tailor our approach to each unique organization

Our consultants have made an effort to show through their book  "Agile Transformations – Off the Happy Path" that companies seeking agile change must prepare for some turbulence. We've also developed our own scaling model, which is not a one-size-fits-all solution but shows where an organization could and should make changes.

However, this turbulence is the opportunity. After all, c Change without real integration of new practices misses the point. Agile consulting – including ours – views change as an opportunity. The iterative nature of the agile process means that we expect, embrace, and see change as part of the natural flow of projects.
 
Resistance is seen as valuable information indicating areas that need attention.
Resistance is therefore always information – to show the nature of the system: "Attention – there is something to consider here." This approach then allows you to design the next steps together. See also this text by our colleague  

Personal experiences and the art of agile consulting

From my personal experience, I see that the art of agile consulting goes far beyond the mere application of methods. Yes – of course new knowledge must be acquired and consolidated through practice. But the point is to establish a continuously learning organization. Observing the development of a culture of success, openness, continuous learning and shared responsibility is wonderful. It is wonderful to see how every individual in the company is not only part of the process, but actively participates in shaping the future and thus also ensures the future viability of their own profession.

Conclusion

The decision between classic and agile consulting should not be made lightly. While agile consulting – like ours – can facilitate the transition to new ways of working, the substantive skills for new technologies (e.g., 3D printing) may require traditional consulting.

However, every change in technology in companies always has a social component. New technologies only become effective when old ways of working or behaving also change. This can only happen with people, not against them or for them.

In personal discussions with our customers, we always explore which approach is the most suitable to master the specific challenges. There is no one-size-fits-all solution – but there are proven principles and a deep base of experience that we use to work with you not only to solve problems, but also to open up new opportunities.

"What does that do for us?" – This is not only a justified, but above all the crucial question before a company starts an agile project. Because one thing is obvious when you hire a consultant like us to help make a project or business unit agile and efficient: it costs money.

Training and workshops for employees, updates to the technical infrastructure to facilitate more efficient and seamless collaboration, and modularization of the product architecture – all of these require time and money. But what if these consulting services and the resulting infrastructure changes, along with the enhancement of employees' skills, could pay for themselves very quickly? Sometimes in a few weeks, or even in just 90 minutes.

Increase efficiency and reduce costs through agile transformation

We were once asked to work with a team on a real case during an agile training workshop. It was a project that had been ongoing for 3 years, missing the final report, with one million euros still outstanding.

After explaining the basic agile working methods in the morning, we spent 90 minutes tackling this project using flash working. Ninety minutes later, the team not only knew what needed to be done, but they had also done it. The money was recovered. Profitable investment – we think so.

But costs can also be reduced.
Agile working aims to design collaboration within and between teams in an organization to eliminate unnecessary process ballast – "waste".This step alone impacts costs. Waiting times are reduced and warehousing decreases as downtimes are eliminated.

All of this can be measured, and here comes the crucial point of any agile implementation project:

Identifying the Problem to Improve

For instance, the problem with StudiVZ was that the software was no longer deliverable. Unlike Facebook, which constantly offered new functionalities to stay attractive, StudiVZ's developers delivered less due to common software development issues. Within six weeks, this problem was resolved.

In 2005, Salesforce.com experienced exactly the same problem. More and more developers delivered in longer and longer periods of time. In 2006, one of the first agile transformations occurred – the result: an exponential increase in delivery capability, making it one of the fastest in the industry. See this slidedeck

Both companies quantified their problem: number of days until the next release.These increased without agile working and fell rapidly after implementing agile working.

We always recommend our customers to see their existing KPIs as a fiber curve. What is important right now? Sales, profitability, time-to-market, customer satisfaction: These KPIs must be improved by implementing agile working methods.

How to Identify Relevant KPIs?

With the experts of our customer’s system, we go through a series of questions aimed at both efficiency and effectiveness. These questions are deliberately kept simple: The goal is not to calculate precise amount but to understand the financial implications.

We once asked a managing director how much money they would lose if the product we were developing as a team was delayed by a month because of indecision over spending 100,000 or 140,000 euros. He said: Every month of delay means losing at least one customer for 10 years, equating to about 10 million euros in lost sales.
 

This assessment is often enough to justify taking actions in the company.

Similar questions include:

• What effects can we achieve if colleagues from the department can focus and work on one thing in a team?
• What additional costs can be avoided if misguided developments are detected earlier? How much less effort does it take to complete tasks if the cross-functionality in the team is increased for a fast and smooth exchange?
• What acceleration would be possible if the current obstacles were systematically removed and thus dismantled?
• How much time can be saved in management if reporting efforts are drastically reduced or abolished?
• How much faster can a team be if it makes decisions itself?
• How much more revenue could the company generate if it could place its products and services on the market earlier?
• How much can customer satisfaction increase if products and services are more in line with the expectations and needs of customers and users?

If you contrast the results of these savings estimates with the possible costs of agile implementation, you can at least see a first indicator of whether the investments are paying off.

Attention: Few KPIs – focus here too

Our recommendation is: Focus on a maximum of four topics to measure your improvements. Identify one to two values to measure – these should be easy to measure, preferably automatically.

Example 1: Large-scale project - more efficiency by reducing Time wasters

Initial situation

In a large project with more than 1,000 employees, there was considerable planning effort: constant coordination and re-planning. A gigantic time-waster. "We don't get to work anymore" are common quotes from such projects members. 

Solution

We developed a 3-month planning interval that brought together all lead and coordination functions (> 100) on site for 2 days to plan the next few months. This reduced the planning effort enormously. Although it's difficult to plan in advance, as planning efforts are rarely tracked, transforming "We don't get to work anymore!" into "Now we work more effectively and purposefully" was challenging but achievable.

Example 2: IT companies – faster product development

Initial Situation

The order situation was tricky because the customer wanted to see the product quickly and, due to initial delays, was very unsure if the development team could deliver what was promised.
 

Solution

We separated two development teams from the existing R&D organization (approx. 70 people), provided them with product owners and ScrumMasters, and started iterations. Our goal was to implement a first executable product increment within 8 iterations (16 weeks) and thus regain customer trust.

Everyone was amazed at the quick delivery. Besides introducing Scrum, generating focus and full management attention, a key success factor was avoiding a final architecture design and instead making rough assumptions, trying them out, and iteratively developing further. This saved weeks compared to the classic procedure.

Example 3: Deutsche Bahn - Efficiency in the generation of subsidies
 
Initial situation

The Rhine-Ruhr Express (RRX) is one of Deutsche Bahn's most important rail infrastructure projects. Additional capacity was needed on the Cologne-Düsseldorf-Duisburg-Dortmund route, requiring better connection of 6 "outer branches" by the end of 2019. For the conversion of 52 stations, DB Station&Service AG had to apply for funding. Clear processes had to be followed to receive grant notices, involving many interfaces internally and externally. Changes had to be notified to the funding agency, and original applications revised, restarting the process until updated grant notices were issued or queries were resolved, involving several departments.

Solution

To maintain an overview of all 52 sub-projects and speed up the process, the responsible team visualized the application process on a 4 by 2 meter project board, clustered according to the six outer branches. Each morning, the status of all projects was discussed in 15 focused minutes. For topics requiring multiple experts, cross-functional working meetings were conducted, where all necessary people worked together until all questions were solved. If there were open points, commitments for another appointment were made on the spot.

The result was impressive:

• The number of notices received rose from 3 in 2017 to 35 in 2018.  
• The overview of all projects also made it easier to reallocate capacities.
• Job satisfaction has increased significantly as the distribution of tasks became clearer and progress visible on the board.
• The concept of co-creating and contributing ideas attracted many young applicants.
• Agile working extended to other programs, such as the final proof of use for the funding agency (this was the example above: 1 million in 90 minutes).  

Example 4: Webasto – Custom orking model for product development

Initial situation

For decades, the original equipment manufacturer Webasto has been successfully producing solutions for the automotive industry. In view of increasing dynamics and new trends in the automotive market, the group of companies started its tailor-made agile transformation with the goal: away from project organization and towards customer-oriented product organization. An effective collaboration model for the development sites was to be identified to  mobilize Webasto's internal expertise more strongly and thus react more quickly to market dynamics.
 

Solution

Product managers were guided to build suitable teams and product teams were given maximum design freedom to work effectively. 4 key aspects for the framework were identified: aligning all activities with value creation, supporting organizational responsiveness, enabling self-responsible and self-organized collaboration, and focusing on solutions rather than processes.

Result

The first successes were evident in the cooperation: The new team composition allows team members to work more focused and contribute better. Staying focused means 
 

saving transaction costs because team members no longer have to constantly switch between different contexts.

Reporting required less preparation time, and compatibility issues were resolved early in development, minimizing obstacles during integration  

• Overall, cross-functional collaboration significantly reduced waiting times because questions were clarified faster and tasks were processed more quickly.

Read more

Example 5: Millentor Festival – event organisation with a small team and a big impact

Initial situtation 

Viva Con Agua Arts hosts the Millentor Festival annually, involving art and music in a stadium. Five employees and several hundred volunteers organize it. Each year, the team needed a few
 weeks off after this feat of strength due to the stress involved.

Solution

We offered our support for this charitable cause pro bono. Our consulting team helped the team for a few hours a week. The result was a completely relaxed event of the festival and even the omission of important key people before the event is not a real challenge. 

The Top 10 Improvements

When discussing the profitability of adopting agile ways of working, there's the challenge that customers are often reluctant to publish these details. The examples above are rare exceptions.

But from our experience, there are 10 aspects that come up again and again - whether in hardware development, software development, organizing festivals or working with students:

1. Effective communication between departments and that often means a drastic acceleration of processes.
2. Error processing and rework are dramatically reduced.
3. Faster project completion.
4. Significant reduction in stock levels in hardware and production sectors.
5.  Customer satisfaction increases.
6.  Employee satisfaction increases significantly.
7. The throughput of projects in companies is increasing by leaps and bounds
8. Employees accept leadership in a supportive way  and recognize how effective it can be.
9. Products are built closer to customer needs, meeting developed functionalities with the intended use.
10. Reliability  is perceived positively and mutual trust increases.

All in all, companies save high costs and achieve much higher productivity by introducing agile working methods - as we have been able to experience again and again.  

The answer to the question: "What is the point?" is always connected with the counter-question: What is it supposed to achieve? How do we measure this? We then get started and, after a short time, measure whether we have reached our goal.

The agile evangelists of the first hour, including myself, had the advantage and the disadvantage that we could not buy external consultants who would have shown us how agile working works. I brought Ken Schwaber to Vienna in 2004 to my first Scrum team and let him talk to my 5 developers, but that was not consulting in the sense that exists today.

Then, a few months later, the software development department of the former Web.de called me: Andreas Schliep, the then team leader of software development and today's co-founder of the consulting firm "Das Scrum Team". He asked me to help them  try Scrum

They had already started like I did, and together we began learning how to work agile.

Even today, there are people in organizations who experiment with Scrum and other management frameworks on their own. Some are fortunate enough to have gained substantial experience in other companies. I recently spoke with a Head of Innovation at a large company who acts as an in-house consultant and facilitator to introduce agile principles. So yes – it is possible to start an agile transformation on your own.

And – this approach is slower

Often, there is no conscious decision by management to advocate a change in the way of working. As a result, many activities occur in secret or are merely tolerated.

In one large corporation, 50 projects were experimenting with agile methodologies without the department heads knowing. It was only when we designed leadership workshops that included these projects that we began to understand why these initiatives were successful.

From our perspective, the clear advantages of hiring a consultant are:

Readiness for Change: 
Hiring external consultants usually indicates a willingness to change. However, this is often limited to the person placing the order. Consultants are needed to motivate teams and managers to try a new approach and determine its usefulness. In an IT transformation at an energy company, management's attention and expectations were clear from the outset, which was helpful in communicating the new working conditions to external service providers.

The know-how and experience that customers buy through external consulting.
Web.de had bought in because of my experience. This is still the case today – we are bought in because of our now very extensive experience. Our advisors have seen a lot, really a lot. Different industries, different challenges, different cultures and many different teams, software and hardware projects. One of our consultants even brings NGO know-how and can show how to do Agile in the Arts scenes. Yes – there can be a stroke of luck that an organization has hired someone who has also seen all this (and, for example, hired an ex-employee of consulting firms), but usually this is not the case. We are still making the experience that there is simply a lack of know-how – certification does not make a good coach or consultant.

Agile Hub/ Transfo Team Establishment
It is desirable to set up an agile hub (internal consultancy of 5 to 10 consultants) that look after the teams within the organization, but that takes time. 

A lot of time and energy is needed for this team to be able to start itself. (Some of our consulting assignments were to build these very teams, and that then slowed down the transformation in other areas). 

This is perhaps the decisive difficultyof trying to make the change internally.

Change is hard work, often started with a lot of passion, but always leads to frustration. If you try in vain to convince a team or a manager, or perhaps you have even had a heated argument with your own manager – where does this person go then? To a colleague? This poisons the atmosphere even more, to the next manager - a taboo in many organizations. The feeling of powerlessness is quickly overwhelming and the internal consultant leaves the company in frustration (I have seen this very often).

Objectivity and assertiveness.
One of the reasons I founded borisgloger was to offer a safe haven for our consultants. They should be able to express their opinions openly and honestly to customers. They should be able to point out what is the case and present the facts – without having to fear that these objectified findings could harm their careers. An external consultant still sees things as they are. The famous story of "The Emperor's New Clothes" illustrates this – a consultant is naïve, politically free and open enough to be able to address the parafunctionalities of an organization.

They don’t know what is done a certain way because “we always did it like that” or  what “would never work here”, and they just do it – and often this shows the internal colleagues what could work.  For example, a colleague once unscrewed a wall display case because he needed space for a whiteboard and task board. He didn't know that you needed permission from facility management, which he would never have gotten. When this became known, there was already an outcry, but as the team became more effective, it stopped and the organization could live with the fact that the missing piece of furniture was not needed.

Today, many organizations have some knowledge of agile methods. However, the true art of external consulting lies in collaborating effectively with external & internal consultants as well as employees.

This is not just about learning from each other. Internal employees can sometimes take more time or they can underpin the change with other arguments. For instance, an internal organizational development team at a bank began using agile methods themselves, inspired by our colleagues' experiences. This example set a precedent, convincing other teams. Sometimes, as in a large corporation, external consultants are heard more readily than internal ones, even when saying the same things.

Good consultants are not just guides but also Sherpas, akin to home tutors or personal trainers. They show how things work and support implementation. It's not just about knowing how to do it but about doing it and transferring these skills to the client organization.

Counsellors - like us - have often gone down this path

and know the pitfalls and possible potholes on the path to change. Christoph Schmiedinger and Carsten Rasche have compiled these for our customers in their book Agile Transformations off the Happy Path, and I myself show in Scrum Think BIG  what you all have to consider if you want to agilize more than one small project team.  

For more information on what to expect from agile implementations, I recommend the many case studies and white papers  – free and freely available on our website 

Clarification of the mandate and definition of objectives

The most important question we ask our customers at the beginning is why? What is the change supposed to be good for? Agility is not a goal in itself, but has to serve one. What is it supposed to solve? 
 
For instance, it could be:

1. Projects should be completed faster and delivered on budget –like one of our customers who had IT project lead times of over 2 years. We were able to reduce that to a few weeks.

2. Production runs are to be shorter. 
 For example, there was one customer who was able to reduce his production time from idea to sale at checkout from 18 months to 6 months with us.

3. The cooperation within teams and without teams doesn’t work well 
 One of our consultants managed to get a quarreling team to deliver in just a few days.

4. Employees are involved in too many projects at the same time and focus is lost.
 With agile portfolio management, a major automotive supplier succeeded in increasing profitability. More about this in our case study.

5. Strategies remain in a drawer, but cannot be implemented. 
 With our view of OKRs, top management across the organization was able to provide clarity on the next steps and motivate employees.

It would take too long to complete this list. But it isclear that it’s always about a business problem that is to be solved by change.

This clarification of the mandate is supplemented by the definition of objectives. How do we ultimately measure whether we have achieved the goal together with the customer? How does the customer find out whether the transformation has been successful? This is about hard facts: We want to reduce the throughput time, have fewer errors in the system or increase employee satisfaction. Find out more in our case study!

Stocktaking

Once this has been narrowed down, an inventory is usually taken. For larger projects, we take 3 to 5 days: Today, it is often the case that agile concepts are already being used in companies. Often there is not only initial experience, but even proven expertise.

Now it is a matter of working out a common picture of where the improvements should take place. For example, if we are "only" talking about a team in which agile working is to become the standard, the inventory can also be completed after 4 to 6 hours. After the workshop, everyone knows what needs to be done within the next 6 weeks to make this team work more effectively.

We usually like to work with our model of the 6 dimensions of change in this analysis.

We differentiate whether the measures contribute to:

1. Management of the company and leadership behavior: keyword agile leadership and agile strategy development

2. Managing projects, production processes or organizing a team or department: agile management frameworks

3. How to turn product ideas into products: How can the product or service be built in a customer-focused way that serves the customer's benefit?

4. Are there know-how topics: where does the customer organization need new know-how in state-of-the-art practices, which can vary greatly. For example, there is often a lack of knowledge on how to work with modern development tools. Current topics include AI and DevOps.

5. The topic of infrastructure: Do we have the right technology? Is our communication and infrastructure able to deliver quickly and cost-effectively?

6. How is our organization positioned, how well does our organizational structure fit the requirements of the customers and what implications does this have for our customers.
 ‍

Actions: the transition backlog

After this inventory, we discuss the resulting recommendations for action with our customers and create a kind of change roadmap, which we call the transition backlog. We then agree with the customer which of these measures should be carried out in which order. Only customers can determine this path, only they know what is conceivable and manageable for the organization with the change.

If the changes affect more than one team or project, a so-called transformation team is introduced for these now larger change projects and then we at borisgloger support this team.

But it may also be that the next step is to build exactly one pilot team, and this is where we support the team to deliver the project successfully. Here, our service often consists of either leading the existing project team ourselves by providing the manager for the project or enabling the manager of the customer system to lead this project to success using agile methods.

Further information on how a change can take place up to transformation and what challenges can arise can be found in the book "Agile Transformation" by Christoph Schmiedinger and Carsten Rasche.

Customers often ask us: What makes our advice special? Why might we be a better fit for you than our colleagues from other consultancies? And how can you tell if we're not the right fit for you?

Firstly, we are not a traditional management consultancy, nor do we come from a classic project management background. We are neither a conventional organizational consultancy nor systemic coaches.

Yet, we advise on the development and implementation of new strategies. We support your projects by enhancing your delivery reliability and improving the quality delivered. We might also transform your organization to better align your processes with customer needs. We do all this in collaboration with you – we walk the path with you instead of merely telling you what to do. This is precisely where our strength lies. It's not enough for us to diagnose the problem and issue a prescription – we're by your side every step of the way.

This is only possible because, in addition to solid & extensive theoretical knowledge, we know how to implement change and have trained our consultants in communication skills to help you carry out your initiatives. We use all our expertise to support people in organizations to succeed with agile methods.

Above all, however, we live by the principle of "Eat Your Own Dog Food": We use all agile management methods, coaching, and communication techniques to manage our own consulting practice.We are not a management consultancy that sells an agile mindset externally but remains hierarchical internally or one that used to advise on classic project management and has now jumped on the agile bandwagon.

We live what we advise

Unlike many other management consultancies, we do not see agile working as an add-on but live the agile principles as an essential attitude. We don't sell Scrum or other agile management frameworks as a method, instead, our consultants think agile and live agile in our own organization. We assemble our teams diversely, use OKRs and Scrum ourselves, conduct retrospectives , work with task boards, and have structured our organization as close to the organizational ideal as possible. There's always room for improvement, of course.

We take responsibility for success

The second crucial difference is that, although we view our customers' world through agile lenses, we aim to solve our customers' issues. We are committed to customer success, not merely to introducing Scrum, SAFe, or OKRs for the sake of using these methods.  

With these management frameworks, we strive to make employee collaboration more effective and provide managers with the tools to do their jobs faster and more efficiently. Our commitment does not mean we always achieve the customer's goals – there have been rare instances where we did not achieve the promised effect. However, our dedication to your success remains unwavering

We have built our organization ourselves in an agile way

And to be frank: Our consultants decide for themselves who they want to work with, and we have made our finances transparent to everyone. We live closeness and equality. This is why even consultants who may seem very young at first glance can confidently tell their clients after just a few weeks that they understand how new work functions – because they have experienced it firsthand. Their consulting skills are not just theoretical; they feel and understand how much more productive agile working methods are.

There are other consultancies that at first glance also provide ScrumMasters, but we often find that these colleagues often do not stand up for their teams. In challenging situations, they remain on the safe side because they are not allowed to honestly tell customers what is necessary due to their bosses.

Conversely, we encourage our advisors to do just that: We put the facts on the table – even at the risk of our clients then parting ways with us. Fortunately, this doesn't happen often, although we can be challenging for our customers.

Because yes – we also make mistakes...

...which have nothing to do with openly addressing dysfunctionalities. We had a wonderful customer whose internal culture was so different from ours that we stumbled into every conceivable faux pas at the beginning. In their eyes, we must have behaved like the proverbial elephant in a china shop.

We were actually embarrassed, and it was only when we sought an open conversation, managed to address our cultural differences, and openly admitted our lack of understanding that our true collaboration began. We saw diversity as a source of change, and the customer knew this better than we did – that's exactly why they chose us. This approach took several months, and we can only thank the customer for their patience with us.

As difficult as this path was and as grateful as we still are for the customer's understanding, the customer organization would not have been able to withstand us if we had not delivered added value from the beginning. Despite our mistakes, we received wonderful feedback because we were able to support the client's teams in their work productively and professionally.

We visualize - constantly

Everyone who has used Borisgloger's services so far has been amazed at the beginning by our constant drawing and painting of pictures. This worked very well before all the remote work when we had flipcharts in the room. Today, we have to resort to sketching with the iPad. Yes – we firmly believe that it is essential to show things instead of merely explaining them.

We live visual management and illustrate facts with sometimes not-so-nice strokes and simple boxes, as well as occasionally with beautiful graphics. No – we don't have the resources to commission a graphic designer overnight like the large management consultancies. Our consultants draw on the fly what they think in order to clarify ad-hoc facts to teams and managers.

We don't leave our consultants alone

Anyone who brings one of our consultants into their company gets the concentrated expertise of Borisgloger. We live by a principle known from the open-source movement: if someone doesn't know something, they consult the entire company and usually have the support they need within a few minutes. This benefits our customers, who thus gain from the creativity of many.

Content and community

In addition to everything they can expect from our consultants, our customers benefit from our continuous desire to support them with diverse and valuable content.

We offer webinars https://www.borisgloger.com/events , we write case studies and white papers , and we bring our customers into an exchange with other companies that have embarked on the agile journey.  

Can we do better? Sure. Are we often an imposition on customer organizations with our drive and motivation? Yes! But we stand for listening to our customers and going through thick and thin with them.

We are often asked whether companies should train all employees in agile methods? Our answer is always – yes everyone. Preferably from the board of directors to service employees. Safe – the training courses must be tailored to the respective areas of work and positions in the company. But everyone should know what agile working, new work and visual management are all about.

Resistance is a function of inability?

We believe that resistance to new behaviors and new forms of work is almost always related to the fact that people do not know what to expect. They are unfamiliar with the new. They do not know what is expected of them and feel uncomfortable because they cannot yet implement it themselves. And let's not kid ourselves: 

Companies are not "Safe spaces” where an employee can simply try something out or officially admit that you don't yet have the confidence to implement the new.

And de facto, most people do not have a profound knowledge of how agile working works. Almost all of us have been socialized in the classic way and so are our role models.

Almost no one has learned what agile management is at school, in kindergarten or during training. It is only now that consultants are working with a few elementary school students and teaching them how to learn in a self-organized way as a student with task boards. See Scrum4Schools.  

Most people in companies have never heard of Scrum and Kanban, SAFe and OKRs. In addition, if one or the other has already learned something about it from colleagues and friends, a wide variety of ideas exist – everyone currently understands New Work and agile thinking differently. All you have to do is do a little research on Linked:in. 
 

What should the training courses look like for all employees?

How do I find my way through the jungle of training offers? Do I do an agile training or a Scrum Master certification? Should I go to Product Owner Training or SAFe Training? What training courses for managers or teams should I buy for my company? 

The answer is not as easy today as it was 20 years ago, because there are so many different areas of application and specialization.

First of all, let's take a look at the various questions that I want to solve with a training.

1. General information – Every employee should know what agile management is and what the differences are.
2. A team or department wants to work with agile methods.
3. A project team is to work agilely.
4. A large, very large project is supposed to work agilely.
5. The managers of the organization should understand what agile management means and, if necessary, agile leadership.

General information

It is worthwhile to send every employee to an agile info training. These training formats are generally called Agile 101 or Agile Intro Workshops. They typically last between 3 and 6 hours. They provide information about the roles and the process model and often highlight important concepts such as the task board and the retrospective.  

The ScrumMaster trainings: a team wants to work with Scrum

These formats were intended for the people who wanted to bring Scrum into the company,  such as team leaders and project managers who want to carry out their project with Scrum.

In two days, participatns will gain a comprehensive picture of what Scrum truly entails and how to implement it: how to solve problems within a team, and how to understand  the individual meeting formats and terms.

The goal of this training is to be able to use Scrum effectively and to be able to explain it to your own team.

The same variant of the training is available for all common management frameworks, i.e. OKRs, Kanban, Design Thinking and Scrum.

There is a variant of this training for product owners,  where it is explained in detail how the role of the product owner works, which tools they can use to carry out stakeholder management and how to develop a vision for the team.

When an entire project team is to work with Scrum

The leadership of this team should have a ScrumMaster training and either train the team itself for one or two days or or arrange for this team training from a service provider. After 1 to 2 days, all members of the team should be able to understand why they are working this way.  Good didactics help, and this investment is essential – whether facilitated by an external or internal trainer is secondary. 

The large, very large project is to work in an agile way

Again, all managers and team leaders should be trained in the framework they are using, whether it's MyScaled Agile, LeSS, SAFe, or another scaling framework. The people with prominent roles must all have the same understanding of how & why they are working the way they are.In this case, we offer the My Scaled Agile training or the corresponding SAFe training.  

Then the rest of the project team must also be trained in the entire model for 1 to 2 days.

The organization's leaders, especially the board of directors or management, also need training

There are a wide variety of formats here:

1. It often starts with a presentation where managers get a first insight
2. It is more effective to intensively confront managers with agile leadership techniques for 1 to 2 days. This can be an Agile Leadership Training , or it  can be a Scrum Master or Product Owner Training .
3. But these trainings need to be complemented by 2 more trainings:

• Training in self-organization (developed by us) requires leadership training. This involves an intensive examination of oneself and the new possibilities of leadership from an agile perspective.
• Training that explains elements of lean management, such as Flow, Work in Progress Limits, and similar tools. This is necessary because managers need to understand that it is in their hands whether their organization becomes more productive or not.

In addition to these classic method trainings, it is then necessary to acquire skills in leadership, team coaching, facilitation, and change management.

Here, too, my recommendation is to use providers who come from the agile consulting environment. Agile leadership skills and agile change management, for example, differ from traditional approaches in terms of their basic attitude. It may only be a nuance at times, but in the end, it is decisive for the application and success

If you go to a conference like Agile 2025 in the USA, Manage Agile in Berlin or any other event today to find out which agile management consultancies should help him or her with the introduction of agile management frameworks such asScrum, Kanban, Design Thinking, agile scaling with SAFe, My Scaled Agile or LeSS, you'll find a wealth of options to consider.

The market becomes even more confusing because there are also numerous micro-enterprises with few employees, often even one-person companies that act together with colleagues from their network.  

At this point, it is not possible for us to give a complete overview of the market in the German-speaking world, but we will try to highlight the six most competent companies from our perspective and briefly introduce them.

You won't find on this list the large management consultancies that also offer agile transformation services. Cap Gemini, Accenture, PWC, Bearing Point and McKinsey, Bain, Boston Consulting Group - they all offer consulting services in this field, of course.

1. The Scrum Team

Let's start with a small, very specialized consultation. The Scrum Team. Founded by Andreas Schliep and Peter Beck. They would be my first recommendation when it comes to purchasing training courses to become a Certified ScrumMaster, Certified Product Owner or the other certification trainings  offered by the Scrum Alliance .

They are among the most experienced Scrum trainers from the very beginning. They are well integrated into the network of the agile scene and the Scrum Alliance and know many problems at companies. Their courses are highly up-to-date, and their customers are in Germany and Switzerland.

2. Wibas

No. 2 on the list would be Wibashttps://www.wibas.com/de. Wibas, founded a quarter of a century ago by Claudia Raak, Jörg Battenfeld and Malte Foegen, sees itself as an agile management consultancy. Unlike the Scrum Team, it is not specialized in Scrum, but methodically in SAFe – but uses this training to offer agile transformations. There is also a book by them on the subject. 

They also offer very good Scrum training, but in recent years they have specialized more in scaling frameworks, especially SAFe. They also offer the other agile management frameworks. They have a wonderful location in Darmstadt where they give their training sessions. Their consultations around SAFe and agile transformations are certainly among the best that the German market has to offer.

3. IT Agile

If you are looking for agile training on Scrum, Kanban or SAFe in northern Germany, you can't  get past IT Agile from Hamburg . They are only in third place because their offer has become confusing for my taste.

If you want to find out more about UNFIX or your own agile leadership offer, you will find it there just as much as someone who finds the certification of the Scrum Alliance or the Scrum.org . But that is their strength - because they have been in the agile market for more than 2 decades, they are among the most experienced consultants when it comes to advising teams and organizations in agile management and mindset.  

4. Kegon AG

Kegon AG in Wiesbaden was one of the first consultancies in Germany to specialize in the Scaled Agile Framework. They offer training and consulting around the SAFe framework. If you want to find out more about this variant of scaling business processes, you are certainly well advised to stop by KEGON. KEGON has a very large network, as they saw themselves as a network organization from the beginning.

5. Improuve

Another agile management consultancy from the very beginning is Improuve in Munich. In addition to the Certified Scrum trainings such as Certified ScrumMaster, they also offer the Professional Scrum Trainings of the Scrum.org and the Flight Level Training of the Flight Level Academy as well as Kanban and SAFe trainings. They see themselves as consulting at eye level and are certainly among the quieter management consultancies in the market, but you can meet them at many conferences.

6. Agile Heroes

Last but not least on this list are the Agile Heroes from Frankfurt. They have by far the best website and the best social media presence. Their strengths are the Scrum Professional Trainings of the Scrum.org, but also agile Prince or even Scrum in Formation.

But their absolute focus is online training, which they offer much more aggressively than the ones mentioned above – all of which also have online offers. Their second mainstay is consulting, from agile transformations to agile strategy consulting, you can also get the entire portfolio from them.  

To be continued

This list cannot take the work off your hands to find the right company for you. And as I said, it is far from complete. To make it exciting ... this list continues.  In another post, we will briefly introduce the HR Pioneers and others such as the Emendare. Let us know who absolutely needs to be mentioned.

To answer this question, I have to go a little further back. My first attempt to write a book about scaling Scrum was a disaster. I wrote myself into a writer's block. It didn't work! For months, I tried different approaches to the topic, wrote outlines, penned my first lines, and got stuck. Then I remembered it again. It was almost as if a film was playing inside me:
Recife, 2008. A large hall. A software development conference. Jan Bosch speaks on stage. A star in the software architecture scene. His thesis: Large projects do not scale through the process, but only through the architecture. Any attempt to keep a large project under control with the help of processes must ultimately fail because the coordination effort becomes too great, he continued. That matched my experience. By then, I had already switched to Scrum several times for large development projects with 60, 180, and 250 people. 

Yes, it was possible, but it was so extremely exhausting. There were a lot of coordination meetings and the task boards got longer and longer, the longest was 7 meters long.

Yes, it was possible, but it was extremely exhausting. There were many coordination meetings, and the task boards got longer and longer—the longest was 7 meters long.

Bosch explained what was happening in Silicon Valley at Amazon and Intuit. That was when the idea of microservice architecture was not only invented but implemented. His approach promised a solution because I had experienced it myself—it was possible to have 180 developers working on a project simultaneously and manage the many dependencies with the help of a task board. Sprint planning could be designed so that the 180 developers actually knew what they wanted to develop at the end of the day. I had the idea from Bas Vodde: take a large room and put all 180 people in it, implement it, and make it executable (today it's called Big Room Planning). But it was infinitely tedious, loud, and chaotic. In the long run, this was not a solution. It cost an insane amount of money. 180 developers at a daily rate of 800 euros... I always said, "And another Porsche 911 has just been burned." You first have to be able to afford this gigantic, far-too-expensive overhead.

I still hold the same opinion: clients hire our consultants to host these big room meetings, but it's not effective. While we can make these meetings effective, the approach itself is fundamentally flawed.

Why? There are two reasons for this:

1. The first is the idea, perpetuated by the old image of Ken Schwaber with the backlog on the left, the two circles in the middle, and the product increment on the right.T This promotes the notion that development teams are merely working through the requirements of a product owner or the customer.
   Especially large development organizations that do contract development use SAFe because they set themselves up in such a way – to serve exactly this idea. The release trains are discussed in these meetings – so that they can then be commissioned. Here, the justified criticism from the lean community that Scrum and SAFe work in batches instead of delivering in a continuous flow is completely ignored. If you plan 3 months ahead, you are no longer able to react ad hoc to customer needs.  
2. The second mistake is not developing the architecture of the product in such a way that teams can deliver End2End.

But I get lost in the details. So changing the architecture was the solution to the scaling problem. Each team is responsible for one or more services. However, a service always belongs to only one team. This led to the creation of an organization of independent teams and the first images were then explained by Spotify and the Spotify model was created.

At the same time, another problem must be solved: if different services have to interact together, all of which are cut off on their own, but know about each other, then these services have to communicate with each other. An infrastructure is needed that enables this communication. Our laptops all have an operating system that abstracts the hardware infrastructure (case, screen, keyboard, power supply, chips) in such a way that the applications and services can run on them. The scaled system of tens of thousands of services (Word, Excel, Safari, PowerPoint itself consists of 1000 services) works because independent units are enabled by the operating system to communicate with each other.  Architecture was therefore only one condition, the second prerequisite was also needed, a new type of infrastructure. Applied to product development, this meant that we don't just have to think in terms of microservices for large projects, we also need the tools and processes – the operating system, in the form of infrastructure, so that the teams can deliver together.  

Ideally, most of the process steps are also automated by the operating system. Here, Continuous Deployment and automated testing are just the beginning. Much more can be automated if you are familiar with it. By the way, this is, of course, the first decisive use case for GEN-AI; every knowledge worker is enabled to automate at least part of their job.

Anyone who accepts these facts and thus changes their premises can no longer believe that scaling models are the solution to the problems of large projects. Whether it's Nexus, SAFe, LeSS, or other scaling frameworks, they all have two main issues: 1. They start with the wrong scenario, and 2. They misjudge the fact that scaling via processes is far too expensive.

The third step was then a consequence of an observation. Most organizations haven't failed due to the idea of emergent architecture, microservices, test-driven development, or automation, nor because collaborative tools like Miro or MS Teams are not used to their full extent – there is a lack of skills. It's no use knowing the above if the organization, i.e., the people in the organization, can't think it because they lack the necessary skills.

So a model that aims to explain how to build a really big product has to take the skill factor into account. Incidentally, this fact is also not addressed in the well-known frameworks such as SAFe – and I am not talking about agile skills. It's about the ability to do one's work differently than in a classic context. The example of automation or AI today alone shows what is meant here.

Not to expand this article further: There were three other aspects:

1. If you want to invent a product, you have to do it in a user-centered way, i.e. use Design Thinking as an agile product development method.
2. You needs an agile management framework to lead teams and organizations Scrum 3.0 and OKRs and 
3. You need an agile understanding of leadership to implement a culture of success. (If you want to understand these 6 steps in more detail, let me know my Book Scrum Think B! G, our MyScaled Agile Framework, and our 6D assessment.)  

So much for the genesis of the considerations as to why scaling itself is something completely different from what is explained in the scaling frameworks. Only when all these factors are considered together can an organization actually deliver agile, i.e. user-centered and highly effective. Anything else leads to bureaucracy and gigantic costs.

If you absolutely want to do SAFe, you need to have a large organization and be able to spend a lot of money. The effort involved in managing SAFe, because it's all about processes, is very high – and you also have to pay a license fee if you want to use it. This is absurd – after all, in my book Scrum Think B!G, I described how scaling can be managed through processes.

This is not about badmouthing SAFe, but about showing that there is another way.
We ourselves have thought about how we can support organizations when they are not yet ideally positioned. If they don't yet have teams that can deliver End2End, if the architecture doesn't yet fit, if there is not yet sufficient automation and the user is not consulted enough – our solution for our customers is the MyScaled Agile approach.  

Based on the above six points and the corresponding 6D assessment – we develop a strategic implementation path with our customers. Yes – we also have our Blue Print in mind, but this can be reduced to four principles: 

1. Make it possible to take responsibility for Teams End2End – Loose Coupling of Teams and Microservices!
2. Automate as much as possible – e.g. DevOps automations!
3. Always think from the customer's point of view – user centricity!
4. Set up the organization as a network and shape leadership accordingly!

To get there, organizations often need intermediate stages and must first adopt one or another precursor to a network-like structure. That's perfectly fine – as long as it is possible to systematically align the organization with the customer and thus keep it fit for the future. If you want to know more about this, just take a look here: Agile scaling

So, are we doing SAFe? – We wouldn't recommend SAFe implementation ourselves, but if customers need our expertise in their SAFe project, we don't leave them alone. Our hope is that, with our expertise in the SAFe context, we will ultimately be able to make the principles underlying agility usable for our customers.

‍