Switching to agile ways of working is a huge deal – It’s like changing the very culture of how things get done.
Key roles, like Scrum Masters and Product Owners, need skills and experience to lead this change. But here’s the catch: many don’t realize how tough this change can be and end up underestimating it massively.
So what are the most common agile transformation challenges and mistakes? And what strategies can we use to navigate this shift effectively?
Product development is usually not a science but rather depends on good craftsmanship. The same applies to agile transformation within product development organizations.
And that is in no way meant to be disrespectful, but quite the opposite.
Agile transformation is hands-on work and requires a number of both skills and experience of the protagonists, first and foremost Scrum Masters, Product Owners, and Agile Coaches.
In the previous articles of this series, we have seen that an agile transformation is nothing less than a comprehensive culture change, i.e. much more than just a slight reorganization of roles, events, and processes. And even these would not be so easy to accomplish in an organization.
In short, an agile transformation is an extremely complex matter.
Unfortunately, organizations often tend to underestimate this enormous complexity and its impact on the corporate culture.
Regrettably, this often leads to employees, who are not adequately prepared for these roles, being entrusted with the agile transformation.
Other than the frequent underestimation of complexity, the lack of qualified resources is another reason for that.
In part, however, it is also a homemade problem of the agile industry, which, with its training models “Scrum Master in 3 days”, or “SAFe SPC in 5 days”, suggest to organizations that one can become an expert in this field within a few days, and lead an organization through the depths of a complex culture change process after reading a book and passing an exam.
Let’s not kid ourselves, the agile industry has built a business model here, and a course that says “Scrum Master in 6 months followed by a two-year internship” doesn’t sell well and no one wants to invest. Although an agile transformation gone wrong will be many times more expensive.
Since these are not protected job titles, anyone can call themselves an “agile coach“.
And since a lot of money is currently being paid for these roles, many people are doing it.
I don’t want to offend anyone here, but I would rather compare agile roles to doctors, who have to do a residency for a few more years – I think it’s 5 – after their training before they are allowed to practice. I’m sure this would be very good for agile transformations and the organizations that do them as well.
Agile-by–the-book does not work in most cases, even if the book is not very thick, which is the case with Scrum.
To illustrate this point, I like to compare agile methods with a chess game:
You can teach a ten-year-old the rules of chess in about three hours. He would then be able to execute every move correctly – i.e. in accordance with the rules. But he won’t become a world champion with that.
Of course, the correct execution of the moves is a basic requirement to play chess at all and this is learned quite quickly because there are only a few pieces and each has a clear move pattern.
In that aspect, the complexity of an agile transformation is comparable to that of a chess game.
There are a number of alternative courses of action in each of many situations and it often takes experienced coaches to be able to assess the impact of each of these alternatives in the near future and to be able to see the context within the overall construct of the organization.
This requires knowledge and experience in equal measure and the ability to combine the two. Wrong decisions can generate a large negative impact at high speed, becoming quite expensive very quickly.
Here are a few examples of technical errors in dealing with the agile machine:
Mistake 1 – Disregarding Sprint Accuracy:
Agile methodology introduces a different time model:
While in classic project management, the length of the phases is based on the content, in the agile context everything is timeboxed.
In the typical waterfall, the specification phase is complete when the spec is ready, the implementation phase is complete when everything in the spec is implemented, etc.
In the agile world, however, everything gets a content-independent timebox, sprints get a timebox, e.g. 2 weeks, Dailies are 15 min, Plannings are 1h, etc.
This gives the KPI Sprint Accuracy enormous importance because teams should learn to plan content according to the timebox, otherwise, the whole thing makes no sense at all.
However, this KPI is not even referred to in many teams, Scrum Masters very rarely work explicitly on bringing the Sprint Accuracy to over 90% with their teams.
Mistake 2 – Scrum Master as Facilitator:
Scrum Masters very often see themselves as agile facilitators, i.e. as organizers and moderators of agile events.
They should actually develop the agile mindset of the team as a team coach, designing a strategy for that mindset and training the teams using agile techniques and best practices.
I always compare this to a soccer team coach who only accompanies his team to the games, but doesn’t really develop a strategy with the team or intensively work with them to ensure that this strategy is also implemented by everyone on the field in every game (sprint).
Often you see this in the Daily Scrums, where the Scrum Master asks everyone individually for their contribution – like a teacher asking the students for their homework in school.
In the process, the team breaks down into its individual components again and the daily scrum is reduced to a status meeting.
Mistake 3 – Custom agile Frameworks:
Organizations adapt agile frameworks only as far as they like, but not necessarily as far as they need to. Typical agile framework cherry-picking.
Often, they design their own frameworks and tell themselves that the frameworks do not fit them completely because their company is very special.
In reality, however, they shy away from an agile transformation in the final analysis and want to keep a back door open, i.e. they take some agile practices that they find quite nice and that do not hurt them and often leave out those that would promote a true agile mindset, but where management would also have to go along completely.
Sometimes it’s the other way around, that management wants exactly that, but can’t get it through in the departments at all.
Either way, in all the large organizations (eCommerce, transportation, banking, insurance, energy, manufacturing, automotive) where I have worked as an agile coach, I have not seen one that could not work with SAFe, but each one had some excuse not to do it at the beginning.
Mistake 4 – Not using agile techniques:
Besides the agile frameworks, there are a lot of agile techniques that support agile transformation and which are almost indispensable for the big goal of bringing “business agility” into the organization.
However, at the same time, I have not seen many organizations and also not many agile coaches that have consistently made use of this or have integrated this into the daily operations of the organizations.
Most organizations stick to the small set consisting of a few roles, artifacts, and events and celebrate themselves when they get Jira to support PI planning and perform a few health checks with the teams on a fairly regular basis.
To avoid such mistakes and to meet the agile transformation challenges, a good agile transformation strategy is needed.
This looks at an agile transformation not as a natural evolutionary process, but as a conscious, strategic decision for a top-down initiated and controlled culture change process.
Unfortunately, this does not sound very romantic, but rather somewhat harsh and prosaic but this is exactly how one should approach the matter and look reality in the eye.
The roadmap for the development and implementation of such an agile transformation strategy could look something like this. SAFe, for example, has published such a roadmap, which makes perfect sense and could be adapted. Here is a somewhat simplified form as another example or from a slightly different perspective. The goal of our proposal is to avoid the agile transformation failures discussed in this series of articles or, to put it more positively, to address the agile transformation challenges from the outset:
Answer the question of which part of your organization should be transformed and why, and which part should remain “lean” and traditionally hierarchical. As a reminder, the units that should become agile are those that directly produce business value, i.e., those that create value. These are essentially all areas that are directly involved in product development. HR, administration, strategic management do not necessarily have to. But of course they are involved and have to take this into account in their processes (e.g. agile funding, agile HR, etc.). (see SAFe Dual Operation System)
Do value stream mapping. Value Streams are the sequence of activities that ultimately bring business value to your customers. Do this for Operational Value Streams (business) and Development Value Streams (the systems they need to do the business). This way, they get to know your organization from a value creation perspective in a new or better way, and they introduce the value creation perspective into your basic way of looking at things right away. After that, it becomes easier to argue what it takes to do better value creation.
Set clear goals for agile transformation that they also back up with KPIs. OKRs, for example, have become quite popular and they are not a contradiction to agile transformation but can be quite helpful. They just should not lead to teams having a double agenda – OKRs and the features/epics they are supposed to develop. Clear goals serve to keep the frame of reference transparent for everyone, they should not create pressure but provide orientation. And don’t forget that agile transformations are a big investment. Provide sufficient funding and resources.
Then prepare the people in your organization for the transformation. First you need agile leaders, SAFe calls this a LACE team. Remember, an agile transformation is top-down, so you need people to initiate and drive it. They need to be extremely well trained. Then, all the people in your organization who will be impacted by the transformation should be well prepared. In doing so, make sure that they don’t make people feel that the transformation is necessary because they haven’t done anything well before. People have done a great job so far, they are ready to take it to the next level and contribute even more to the success of the company.
Start the transformation quickly and in selected areas first. In doing so, use targeted agile techniques according to your agile transformation strategy. Not just Scrum or Kanban, but also techniques like Design Thinking, Agile Funding, WSJF prioritization, PI planning, CI/CD for a BizDevOps culture up to Release on Demand, etc. You don’t have to make it big, but as complete as possible. You need to just try some things in the process. Stay persistent, not everything will work out well right away, a lot just takes some time to get used to. If you want to lose weight and change your diet plan, you also need at least 6 weeks for your body to get used to it. For individual agile practices, you should give yourself at least the same amount of time, preferably a little more.
Learn from successes during this phase. I.e. make small and simple steps. You need to give people a sense of achievement. Celebrate the successes extensively. This is the only way to gradually create an agile mindset. Don’t be discouraged by failures, but don’t sugarcoat them either. Perhaps simply change the strategy once in a while in order to celebrate successes again in even smaller steps. An agile transformation is detailed work.
Agile transformations are very complex and lengthy affairs, far more than merely reorganizing a matrix organization into end-to-end feature teams.
It takes a lot of knowledge and experience to introduce agile methodology into an organization.
Organizations often underestimate the complexity and the degree of difficulty of such a transformation.
As a result, the participants are often not optimally prepared for their roles and this leads to technical errors that freeze an agile transformation somewhere on the surface of an organization but do not have a sustainable deep impact in the sense of a genuine cultural change.
Often, there is also far too much theorizing and the level of technicality of the transformation, i.e., the quality with which participants in the organization work hands-on, is too often too low.
Please don’t misunderstand, mistakes happen everywhere. But if too little expertise is available across the board, and too many participants do not even know the techniques of agile practice or do not know how to deal with them, then it is very difficult for an agile transformation to achieve the effect that an organization hopes for.
The best thing to do is to create an agile transformation strategy together with experts and address clearly and transparently all the points that are important to you and necessary for a successful transformation.
With the WSJF technique, prioritization and PI Plannings become damn easy, highly effective and even fun! Step-by-step guide and free WSJF Excel template
To avoid your agile transformation from failing, it’s most important to define goals and KPI’s – but above all measuring them! How and which you’ll learn here…
This article sheds light on the challenges and common mistakes in agile transformations. We’ll also explore smart strategies to help you navigate this shift effectively.
For scaled agile organizations it is frustrating when their project management tools don’t support their processes.
That’s why we developed scagile as an app which actively supports agile best-practices with features you haven’t even thought about and with which you’ll be able to create value flow across your entire organization.
