Agile Is Dead, Long Live Agile! Interview with Kate Hobler, Agile Coach and Expert

Kate Hobler is an Agile coach and Scrum Master with over 15 years of experience in Lean management and Agile consulting. As one of the original members of Scrum.org, she has collaborated closely with Ken Schwaber, a co-creator of Scrum, and is a certified Scrum.org trainer. Kate founded Brass Willow, an Agile consulting agency, where she leverages her extensive expertise in Lean and Agile methodologies. Renowned for her charismatic mentorship and patience, Kate has trained over 13,000 individuals and often handles the most challenging cases in the industry. Beyond her professional endeavors, Kate is a devoted mom, stepmom, an enthusiast of board games, and a connoisseur of good coffee and tea. She was honored as the Wroclawian Woman of the Year in 2021.

Paweł Kański: A few weeks ago, I read a statement on your LinkedIn that said “Agile is Dead.” You have really impressive knowledge and experience in areas like Agile, Scrum, etc. So I would like to ask you about that post. What is the current status quo of the Agile approach in digital product development for you?

Kate Hobler: To answer that question, we need to separate the Agile phenomenon into the idea of Agile, which is about responding to the situation we find ourselves in, this state of constant change, and Agile with all these tools, frameworks like Scrum, Kanban, SAFe, and everything else associated with the Agile environment. In my opinion, the state of Agile as an idea is better than ever. It happens, yes, but it’s rather rare now. The fact that the market might be completely different in two years surprises no one, especially after the COVID pandemic, which took over the world in two months and either wiped out a huge number of businesses or forced them to completely change their direction of development.

So, the idea of this continual variability and the need to quickly adapt to what is happening around us is very much alive and well. However, if we talk about Agile as a set of tools and all the nice things that are sold along with the idea, there is a definite regression. And it is caused by a few things. All these Agile tools were the first to be thrown out when the market conditions worsened. There are companies that suddenly got rid of all their Scrum Masters. There are companies that, upon the onset of a crisis, decided, “Okay, we’re not finishing this project, goodbye.” There are also companies that dissolved their Agile centers or pushed them into an insignificant department where effectively nothing can be accomplished. This problem was caused by a series of unfortunate events, driven by the market situation and a certain “watering down” of Agile.

You might be also interested in the article:

Agile in practice #3 - What is Scrum in Agile development?

People introducing innovative Agile work methods in companies significantly increased their competitive edge, both in managing the organization and in product management. This caught the interest of other companies, which began to seek similar specialists, leading to a demand that exceeded supply. This resulted in a decline in quality and a lack of understanding of the term Agile, due to a lack of standardization. After the 2008 crisis, companies that employed such people coped better, which again increased the demand for specialists. However, the rapid development of the market led to the emergence of products labeled “Agile,” which had little in common with true Agile, diluting the market to the extent that it is difficult to return it to its pre-crisis state.

Paweł: Your observations remind me of my recent conversation with Piotr Majchrzak about how, in times of crisis, decision-makers often opt for more rigid models like Waterfall over Agile because they prefer to stick with something they perceive as simpler, more concrete, and more reliable. When Agile becomes too “soft,” they prefer to choose services based on Waterfall instead of those labeled as “Agile.”

Kate Hobler: That’s correct. Although Agile offers solid frameworks that work well in times of crisis, there is a phenomenon of fleeing to solutions that seem safer, which is quite natural. Therefore, during a crisis, Agile’s image suffers greatly. However, dilution occurs more after the crisis than during it. In contrast, during crises, Agile performs exceptionally well because only those who truly understand Agile are able to find work and indeed bring value to the companies they work for. After the crisis, when the individuals who added value become legends, other companies say, “We want that legend too,” and start looking for similar specialists in the market.

This then leads to “watering down” - the best specialists, who can provide the most value, are always scarce.

Similarly, in the 1980s, Lean and Six Sigma were adaptive approaches, though more focused on physical than technological production. Over time, these methods diminished in significance for businesses. Although they still exist as ideas and tools, they are no longer the standard. Currently, the standard is something else, which is based on the same idea but presented differently. Now, a new cycle with a new idea emerges, which seems to have a greater chance of success.

Paweł Kański: From your observation, what stage of the crisis are we in?

Kate Hobler: I believe we have just passed the worst moment, which was around the turn of 2023-2024. I think we are on an upward trend, and the indicators I’m observing nicely demonstrate this. One of the more interesting indicators, once pointed out by the CEO of Scrum.org, is a very cool measure of business sentiment. Specifically, the year-over-year cost of transatlantic flights. Because if this cost is rising, it indicates that companies are sending their employees to other departments and companies across continents. In other cases, budgets are cut, so companies do not have good forecasts at this moment. And the prices of transatlantic tickets have started to rebound, even considering the cost of fuel.

Paweł Kański: Let’s return to Agile and its imperfections - what do you think are the three biggest sins of Agile?

Kate Hobler: Excellent question, thank you! The first problem is that Agile unfortunately originated in the wrong place, namely in a technological environment rather than a business one. If we look at the signatories of the Agile Manifesto, out of 17 people, 16 are developers, people who work with technology or have worked with it closely or distantly, and only one person is non-technical.

The effect was that even though Agile as a concept in the form of these tools and frameworks, which are now popular, appeared in the 1980s and was formalized in the mid-1990s, the Agile Manifesto was signed in 2001. It was then that it really began to develop, but at that time business people had not heard of it because for them it was a purely technical term. Most people outside the Agile bubble had the attitude, “Okay, let the coders do their thing, it doesn’t concern us in business.“

Things began to change around 2007 when Steven Denning transplanted Agile into business by writing about Agile in “Forbes.” That was a game changer because suddenly, within just a few years, the business community said, “Oh! We want that too.“

Agile was mainly limited to IT and this was very damaging to the idea. Even though the process included a counterpart to today’s Scrum Master, there was a lack of a key person from the business side responsible for product management. Instead, there were business people with weak decision-making powers. As a result, only the existing state of affairs was copied without delving into the original intentions.

Few know Winston Royce, the creator of the Waterfall model, and most associate him only with the popular phase-transition diagram. Meanwhile, Waterfall included cycles and iterations, which is often overlooked. This misunderstanding and copying of the Waterfall model meant that later attempts at correction were costly and lengthy and never completely successful. It still happens that roles such as Scrum Masters are treated as overpaid secretaries, and those responsible for the product are seen only as business analysts with authority to manage the product backlog. Additionally, the SAFe framework has cemented these roles, not providing the expected help. That is the first sin of Agile.

The second sin is the sin of all kinds of Scrum Masters and Agile Coaches, and it is “hugging and petting trees.” I’ll start with a paradigm of reality perception that the market comes from, which is what companies try to achieve. It’s the capitalist paradigm, that is, the money I collect, the resources I gather, the skills I learn, all give me a competitive edge. This is the thinking that everyone is the master of their own fate. This is exactly the line of thinking that our parents’ generation instilled in us, namely “Learn and you decide who you are, everything depends on you.” But the problem is that this paradigm is a big problem for us. Because such a capitalist approach, accumulating things and skills, is an incredibly lonely approach. Because I am alone, it is mine, it is my property, not ours. That’s why we often talk about the “loneliness of the leader.” In this way, we escape from this poorly understood collectivity and flee into such a high level of loneliness and such a high level of alienation and enforcing a person by his ability or what he owns, that we terribly want to return to that collectivity, but a healthy one.

Only the problem is that since we flee very strongly from loneliness to collectivity, this healthy collectivity is not there because we lean too far the other way. And this is a huge problem for all kinds of Agile Coaches and Scrum Masters. They really want to take care of this collectivity, that we do things as a team. Only the problem is that we lost ourselves in this team and the purpose it has to achieve. It served a purpose. This team had something to achieve. It was called up for a reason.

In pursuit of team spirit and acceptance in the community, we have completely neglected the need to challenge our own opinions and the emergence of safe conflict. All this is necessary to produce good products, to be able to openly express criticism without fear of negative reactions, because it is well known that constructive disputes yield valuable solutions.

Steve Jobs could approach someone and say, “This part of your work is crap“ - it’s something absurdly aggressive and completely crossing any boundaries. But for Jobs’s close colleagues, this was not a problem. They knew he was serious and verified their work based on that. I certainly do not encourage anyone to call anyone’s work in such a way, but I want to show a contrast and the mechanism of honest feedback.

Scrum Masters, who led to everyone in the team feeling comfortable and nice, lost the ability to lead to productive disagreement.

Paweł Kański: Are there any indicators or metrics that support this thesis? As a leader working with Scrum Masters, how can you investigate whether a Scrum Master truly ensures that the team meets business objectives, rather than just making sure the team has a pleasant work experience?

Kate Hobler: The first thing you can check is the intensity of communication within the team. If the team is quiet and communicates little, you can start by stating that it is probably not a real team, but this is one of the indicators. Before the COVID-19 pandemic, this was easily noticeable, for example, in open spaces in offices - a team that communicated well often disturbed others at work. I remember, as a Scrum Master, I had to build partition walls around the teams I worked with because they disturbed others with their chattiness. Of course, it wasn’t our intention, but when the team fell silent, it stopped being effective and really focusing on what’s important.

But for example, the intensity of communication on Teams, Slack, Discord, or any such tool that we have. And that is the first thing. The second thing is the awareness of the product context among Scrum Masters, which is very weak. That is, Scrum Masters often have no idea what product their team is building. If that is the case, then how can this Scrum Master help them? It’s very easy to recognize this.

Paweł Kański: Are you referring to a business or technological understanding of the product?

Kate Hobler: More of a business understanding, but technological understanding is also something that a Scrum Master should have at a basic level.

Of course, a Scrum Master does not need to know how to code, but must have what’s called a “bullshit radar” to detect when the team tries to push something dubious or say, “Hey, listen, something doesn’t add up here. What’s really going on?”

They should also be able to ask tough questions. So, if a Scrum Master lacks this technical insight, they won’t ask these questions.

You might be also interested in the article:

Scrum Anti-Patterns: Red Flags in Agile Practices

Paweł Kański: And the third sin of Agile?

Kate Hobler: The third sin is greed - that’s how I would describe it. Here, it’s not about greed itself, because business is ultimately about creating very good products that ultimately generate profits. However, I am a trainer at Scrum.org, I earn from certifications, but I believe the number of certifications that have appeared is unnecessary. I understand that certifications and the organizations that issue them promote a correct understanding of the idea. I agree with that. However, I am certain that people are now creating certifications not for market needs but for profit, responding to the desire to have the certification itself.

I understand why Scrum.org and Scrum Alliance offer certifications after two-day training, even though it should not be so. It is a legacy from the early stages of the market, which needed this to spread basic knowledge, but this is something that should no longer be happening. But if organizations like Scrum.org or Scrum Alliance give up their certifications, people will go elsewhere where they won’t get as good knowledge. So, it’s a bit of a market stalemate. As if that were not enough, even David J. Anderson, a great opponent of certification and the creator of Kanban University, who personally spoke out and mocked certifications years ago, eventually organized Kanban and introduced certifications, which did a lot of good in the market. However, issuing a certification after a one or three-day training session is something that should not quite happen, because it gives the false impression that someone with such a certification is already a super specialist, which is not necessarily the case.

Tools like SAFe also appear. I am incredibly impressed by Dean Leffingwell, the creator of SAFe, who brilliantly responded to a real market need. The market need was: “I need nothing in my company to effectively change, I want minimal changes, and at the same time, I want to be able to call it Agile.” And that’s a phenomenal product for that! It perfectly meets the need. In terms of product creation skills, Dean, you’re my hero, but approaches like SAFe have destroyed the entire market! It led to a large part of what we call Agile being a façade, not a real possibility to respond to market problems. So, in my opinion, that is the third sin.

Paweł Kański: Is there an idea or trend that can improve or replace Agile?

Kate Hobler: Yes, there is such an idea, and it’s called the product approach. It’s the same idea as Agile, just presented in a place where it’s probably easier to adopt.

If we look at the first attempts to describe Scrum, which is built on Agile, those initial 170-page documents describing the methodology placed a huge emphasis on productivity. Not on projects, although every sprint in Scrum is a project, but on having consistent deliverables. The approach to the product was about what value we want to deliver to the user and by what means exactly? This question has been there from the very beginning.

Now, instead of the Agile approach, because Agile is now associated with very odd, soft changes within the culture and some HR contexts, productivity sounds more concrete, right?

So, when it’s concrete and there’s money involved, because there’s ROI in effective product execution. So we start from the market. We start from what is important to our customer, the user. What is important to that person? What emotions does it evoke? What reactions does it provoke? This interaction with whatever we are giving to someone. What will be the reaction if I give this person a cookie? What’s the difference if I give this person a bottle of water? What will be the difference if I give this person a phone? What will happen in this person? So, this is the product approach, thinking through the user’s needs, through whoever will interact with the product or benefit from it.

Paweł Kański: It sounds like a repetition or paraphrase of Agile Principles. A bit of a return to the roots, an attempt to reboot Agile again, only this time in a business environment. So where is the novelty?

Kate Hobler: If someone has a good Agile approach today, and a product approach tomorrow, nothing will change for them. Really! Because Agile at its core is purely about products, so if it was done well, indeed, you won’t change anything. But in the vast majority of those who claim to work in Agile, they aren’t doing it too well. So the change will be significant.

And the change will be that we finally start looking at our user, because the product will count, something that has the potential to make money. So, really, the main difference is in the vector of the approach, not the idea itself.

Agile culture at work is important, but culture alone does not generate revenue.

The money is in the products, for whose creation a suitable culture, sensible organizational structure, and people capable of doing the work are needed. It all starts at the point where there is money and the potential to earn even larger sums – that’s the point, right?

Paweł Kański: You’re now sweet-talking the decision-makers who distribute budgets. Because from what I understand, the product approach is an approach that prioritizes the product and the needs of the user, not just the Agile tools themselves (e.g., Scrum and its artifacts, Agile Coaches, Scrum Masters, etc.).

Kate Hobler: Yes, exactly. We start from these important goals, not from our team working in sprints and having dailies, but from our product being useful to recipients and actually solving their problems. We want to avoid what I call “enshittification“ – the moment when the product starts making a lot of money, and we stop taking care of it and its quality declines. Even though there isn’t a sufficiently good alternative that could replace it, the product is still used, becomes increasingly worse, and people get more frustrated. When a good alternative finally appears, people quickly switch to it, and the creators of the main product wonder, “Damn, what could have gone wrong?“

Paweł Kański: So where should one start a self-diagnosis of their Agile approach as a Product Owner, Scrum Master, or decision-maker?

Kate Hobler: Start with goals and cash flows. Let’s check what we really want to achieve. Is this truly our goal? It might be a product that directly delivers value to the user, for example, providing peace of mind, earning opportunities, or simplifying life. It could also be a product that does not provide direct value but offers indirect value, making the place where I am more pleasant. It could also be a product that indeed delivers value but does not directly bring in money, such as a marketing product where we invest our time and money but it benefits us by drawing people’s attention to other products we create.

The main focus is the goal, and secondly, whether the finances add up. Of course, there are ups and downs, it varies. I myself have been very close to bankruptcy three times in my own company, so it’s not about always having a lot of money, but rather paying attention to whether this product or these products—because it could be a whole suite—are something that can realistically sustain us. Is this something we really should be investing in? Is this something that can pay off the investment we put into it? Or is it something that will only live because we invest in it and never bring any return? This needs to be considered because a great product idea is one thing, but for that product to be sustainable and deliver value over a long time is another story.

So, whether we call it Agile or a product approach, these are two points that are essential to sustain our business.

Paweł Kański: The phrase “Agile is dead” has been circulating on the internet for about 2-3 years. So this crisis phenomenon has been around for some time, and I want to ask, are we at the stage of diagnosing and examining what’s happening with us, or are we at the stage of already reacting and implementing some changes?

Kate Hobler: I believe this should be the moment for reacting and implementing changes because the shift towards products is something we have been observing for years. It is not new, so one can reach for books that effectively talk about this, especially those by Marty Cagan, who really shakes up the system with his books, and I highly recommend reading them to anyone working with any product.