“Agilewashing”: An expensive way to achieve hardly anything

Let me start by introducing you to my new concept: “Agilewashing”. (At least I have not heard or seen anyone else use the concept yet). “Agilewashing” most likely does not happen consciously, but probably because the understanding of agile systems is lacking. To me it means the following:

Organizations work “Scrumish” or “SAFe-like”. They pick a few (easy) elements out and leave the rest. Often, they work in timeboxes (not always of the same length), and call them “Sprints or PIs”, they name a Product Owner, and maybe a Scrum Master, but they leave out the important stuff.
People use a (messy) task board and call it Kanban. They use none of the 6 Kanban practices, they don’t measure lead times to manage flow, they don’t work with upstream options and downstream commitments. Again, they leave out the important stuff.
Organizations and/or teams believe they are agile, although there is no evidence of agility. Nothing is being measured that can give proof of actual team or organizational performance, predictability, or improvements. Value creation often happens at random, and goals are rarely met.

If you pick and choose only the elements of a method or framework that are easy to implement in your organization, you will not get what you are after, i.e., higher agility. You will probably get a bit more transparency, but other than that you will get what you always got but call it new names.

However, working this way often makes organizations and teams feel agile. But feeling something is not the same as knowing. Feeling agile is not the same as being agile.

Why do agile initiatives often end like this, and what can you do about it?

To answer those questions let us look at why organizations want to become agile in the first place. When I talk to managers, they tell me that they want:

More deliverables completed quicker with the same people. I.e., faster time to market
To be able to see who is doing what. I.e., more transparency
Higher predictability. I.e., they want their teams to deliver what they commit to

That fits very nicely with the results presented in the State of Agile report from 2021. Below are the top 6 reasons for wanting higher agility:

Enhance ability to manage changing priorities (64%)
Accelerate software delivery (64%)
Increase team productivity (47%)
Improve business and IT alignment (47%)
Enhance software quality (42%)
Enhance delivery predictability (41%)

These reasons have not changed much compared to previous years’ reports, but they have sometimes changed places.

Having read the State of Agile report, I took a trip down memory lane to the days when I was working as a Project Manager (PM) at Digital and got my first PM certification (the PMP). That was back in 1999. Those days, more than 20 years ago, the goals were the same.

The message from Digital headquarters was: “We want you PMs to be more predictable when you deliver projects. We want fewer delays and failures, your projects must be delivered quicker, and in better quality. Therefore, you must all be certified”. In fact, that was an order. Digital wanted to streamline the way we project managers worked, they wanted more predictability and improved results. For good reasons.

Of course, these were and are goals worthwhile pursuing, but just like the classic PM methods were not the fail-safe success-booster that many hoped for, it does not look like 20-25 years of use of agile frameworks and methods has given the wanted results either. People are still pursuing the same goals.

Although the agile wave has rolled for more than 20 years (in 2021 Scrum celebrated its 25^th anniversary), and still more companies are working with Scrum or SAFe, (the latter has been on the market for + 10 years), the problems with unpredictability, failed projects, etc. have not been fixed.

At this point, I would like to mention, that it is of course better to have a shallow, but somewhat methodical approach instead of nothing.

‘Agile’ is supposed to be so efficient, so why do we not always see significantly improved results?

I have been involved in many agile initiatives as a consultant, trainer, and coach. I have worked with many agile teams and trained them in Scrum and SAFe, to optimize the way they worked.

I have concluded that unless you work with very disciplined and mature teams or organizations, these initiatives are likely to be only moderately successful. But before getting deeper into this, let us look at what the State of Agile 2021 says:

Top 6 challenges to reaching higher agility:

Inconsistencies in processes and practices (46%)
Cultural clashes (43%)
General organizational resistance to change (42%)
Lack of skills and experience (42%)
Absence of leadership participation (41%)
Inadequate management support and sponsorship (40%)

Again, this fits well with my own experiences. Working with Scrum or SAFe requires quite a bit of organizational and team maturity, and an appetite for change to make them work and be successful. Both frameworks are quite complex, and there is no magic button to press, and POW! everyone knows what Scrum and SAFe are all about. They are neither easy nor intuitive.

No method, framework, or standard can change (bad) behavior, culture, or low maturity, and they cannot fix a lack of skills and experience. Only strong leadership can facilitate such changes, and it takes time. There is no easy fix or a shortcut to agility.

As points, number 5 and 6 above indicate, strong leadership, which is a prerequisite for making the needed changes towards new ways of working, is often missing.

If teams are undisciplined and immature, you can coach Scrum and SAFe practices day and night, you may have all the good arguments, but many will still resist change because they are perfectly happy with the way things are. Many feel that they have more to lose than to gain.

Many like working as individuals in groups instead of in teams, and are not as excited about transparency as their managers may be. Managers, on the other hand, like to make decisions and are not always happy to delegate that power to others.

If you dig a little below the surface, you will see that both Scrum and SAFe are very complex. Particularly SAFe.

Sitting at your desk or being in a training session it’s easy enough to talk about team goals, cross-functional teams, T-shaped people, a lean-agile mindset, agile behavior, agile leadership, values, inspect and adapt, etc., but how to make it all work in real-life scenarios?

Businesses are full of specialists that like being just that. There are often many systems (including legacy). All the teams that I have met support more than one single product/system, so how can you organize them around one single product or value chain?

How can you have one single Product Owner for a team handling multiple systems for several organizational entities? And do you really want cross-functionality when it comes to legacy systems? Would it not be OK to have only one single specialist knowing a certain legacy system in and out?

And last but not least, how will you make Scrum or SAFe work in immature teams (there are more of those than you would expect), that do not really see the need for consistent processes and practices, that lack discipline, and maybe skills too? Teams, that become defensive if you suggest that there might be improvement opportunities to be found?

You may reorganize everything according to Scrum or SAFe guidelines, but reorganizing will not fix all the above obstacles to making Scrum or SAFe work as intended. It is more likely to create disruption and confusion, and you are also likely to have cut so many corners that Scrum and SAFe have become an illusion. I.e., “Scrumish” or “SAFe-like”.

I have now mentioned some of the main reasons why organizations will not get the improvements they were after when they decided to implement Scrum or SAFe. They will not see significant, measurable improvements even though they have gone through an expensive transformation, often led by external consultants and agile coaches.

Agilewashing in action

This is where it becomes difficult and where the agilewashing often begins. If you have spent millions on transforming your organization and reorganizing it in the hope of making it more agile, you are probably not very tempted to announce that you gained almost nothing from it. People may feel that it was a success, but they don’t measure success.

As mentioned, most organizations will get a higher level of transparency when they “go agile”, and sometimes also higher employee satisfaction, and that is good. But when it comes to predictable deliveries, and teams delivering what they commit to in the right quality, the results are not overwhelming. Most teams that I meet do not measure their results, and they prefer not to. Therefore, they don’t know if they are improving or not.

I have yet to meet an organization that can show data from “the before and after” their agile transformation and objectively knows if it has been worthwhile doing. I have seen no data showing what actual improvements have been made.

You may wonder why I, an agile consultant, coach, and trainer would point out this dark and well-hidden side of agility? I do that because I am ambitious on behalf of the organizations I work with and want them to get more than “feel-good-agility”. I want them to get real, evidence-based agility, and fortunately, that is not an impossible ambition.

How to get past “feel-good-agility” to evidence-based agility?

Well, there are several ways. I would never say that Scrum or SAFe cannot work – I just say that it is more difficult than people usually think. If you are lucky enough to work in a mature organization with mature teams, you will always find a way to make any framework or method work. If you don’t, you should lower your ambitions.

When working with immature teams, it pays off to be very clear about what you want them to achieve and be realistic about what you can expect them to achieve both short- and long-term. You must set a clear direction because they will not figure it out by themselves. Not always because they don’t want to but because they lack the skills and experience. (See point 4 above).

But independent of your teams’ maturity, you should measure their productivity and predictability, so you know where they are and what to improve. You need data to do that.

However, the best you could do instead of trying to fix the unfixable would be to look in a different direction and use the Kanban method instead. Kanban works independent of maturity level, it works for all kinds of knowledge work, and it scales.

The best part is that you do not have to reorganize or introduce new roles that are difficult to understand. You simply start with what you already do and improve from there. Therefore, it is so much simpler and cheaper to introduce Kanban as your path to agility.

David J. Anderson defines the Kanban Method this way:

“Kanban is pragmatic, actionable, evidence-based guidance”

The pragmatic part is important because it means that it is not “all or nothing”. Immature teams can start with a few of the simplest practices and make evolutionary improvements. More mature teams can go all-in and apply more or even all the Kanban practices and principles. Thus, you respect the organization and the teams for where they are, and you don’t expect the impossible.

With Kanban, you simply infuse realism into the agile equation, and you don’t need a bus full of consultants or hire a lot of coaches to make it work.

The evidence-based part is extremely important too. Out with vanity metrics and in with measuring lead times. Lead times tell you precisely what you have been able to achieve by looking at historic data. They are not guesswork or wishful thinking. Lead times are reality.

You may not like what you see, but even if your lead times prove to be inexplicably long, now at least you know, and you can analyze where in your system the obstacles to flow can be found. Then you can begin to fix the system.