Author: Dorota Mleczko

“ Agile is not dead – Agile has won!” This powerful sentence was spoken by Diana Larsen during the closing panel of the XP2024 in Bolzano. It was so eye-opening to me, that I wrote a post on LinkedIn about it. The post went viral and triggered many interesting discussions (which is great!). There were also some misunderstandings regarding my statement. I wrote this article to rephrase a bit and make it more clear what I meant with this statement. What do I mean by stating that Agile has won? Over 20 years ago, when the Manifesto for Agile Software Development was published, the concept of agility was fairly new. Crucial elements needed to be explained, taught and even fought for: People needed to be convinced that these concepts will: Today the advantages of being agile are generally clear. Almost everyone wants to deliver software in small, valuable increments and have a close customer collaboration. This way of working has become so basic and obvious, that it is often not even called “agile” anymore. Instead, it is just called “modern” or “best practices”. Furthermore, due to many unfortunate experiences with “Agile Transformations”, many people avoid using this word at all. I often read posts by Agile Coaches, who recommend to stop using the word “agile” (oh irony!). And there are good reasons for this. We should never recommend practices just because they are “agile” – and I think this has happened a lot in the past. Instead, they should be implemented and used because (and only if) they solve a specific problem for the organization or the team. Here is a dialog I once had with a manager during a workshop on future improvements: Manager: We should put the “why?” first and work towards common goals. We should deliver value in iterations and create short feedback loops, so that we can adjust fast. How do we sum this cluster up? Me: Increase agility? Manager (disgusted): Oh no, let’s not use this word… And it went on like this for a while… His mindset, ideas and proposed concepts were well aligned with agile principles, but he seemed allergic to the word itself. For me there is no problem in dropping the word – call it whatever you like, as long as it is helpful and effective. So, to sum up – the word might be dead or heading towards retirement. But the concepts are very much alive and have melted into our everyday work.   What do I NOT mean by that? I am not saying that agile methods are implemented and working well everywhere, far from that! Many transformations have failed. Some have only officially been a success – under the surface, it’s a different story. Teams may still struggle with old habits, resistance to change, or misinterpretations of Agile principles. However, there has been a significant cultural shift where the values of flexibility, collaboration, and responsiveness are recognized as essential for success in software development. We’re seeing a clear movement away from rigid, waterfall processes towards a more iterative, customer-focused approach. Of course, there are still discussions whether one framework is better than the other, whether to use Story Points for effort estimation or not, whether a Product Owner is also a Product Manager… and hundreds of other details. But does anyone ever discuss whether to go back to While the journey to Agile adoption is ongoing, the consensus to avoid these outdated practices is a testament to Agile’s impact on the industry. And that is all I’m saying.   What’s next? Does that mean that Agile Coaches are not needed anymore? Yes and no. We might soon see less demand for: What will be needed more and more? The focus is shifting towards a more tailored, context-driven approach and away from specific frameworks. Oh yes, and we might have to change our titles (to Business Flexibility Expert? Or Delivery Improvement Coach?) to avoid allergic reactions.   Summing up, what we witness today is not the flawless execution of Agile everywhere but the universal acknowledgment of its importance. And that is a significant victory.

What is Business Value and why is it so important? As Agile Coaches, Delivery Managers and even Product Owners, we sometimes focus too much on how to deliver fast. We set up and maintain high-performing teams with great, high-quality outputs and a workflow as smooth as silk. Our framework (Scrum, SAFe, LeSS, you name it) is like a well-oiled machine: Ok, ok, I got carried away with the last one. But doesn’t it sound wonderful? Isn’t that the dream? Well, not really. At least not if you forget to ask “Why?”: And finally What is Business Value? Let’s approach the answer from different perspectives, so that our picture is as complete as possible. Stakeholder perspective Whatever you are building, someone is interested in it: At any point in time, you need to be aware of who that is. And understand the diverse needs and expectations of each stakeholder group towards your product. Your answer to their problems is the value you create for them. Financial perspective Unless you are a charity, your product is supposed to bring in money: so-called financial benefits. These can be direct or indirect: Direct financial benefits: Indirect financial benefits: Operational perspective Your product serves another product? That’s fine! You might be producing improvements that will In the context of software development, Business Value means delivering benefits that drive the organization forward. Those can be straightforward and easily measurable (like revenue increase), but there might also be less quantifiable impacts. Tangible Elements: Include measurable outcomes such as Intangible Elements: Those are harder to grasp but can be equally important. They include Why is Business Value focus important? All this might seem obvious (especially to Product Managers). So, why am I constantly speaking about it, writing posts and articles, and even recording funny videos to attract attention to this topic? Because from my experience the importance of the Business Value we intend to deliver through our products often gets lost in complex processes, sophisticated frameworks or just day-to-day habits. Especially as Agile Coaches, Scrum Masters, Delivery Managers or Team Leaders we sometimes lose sight of why we are actually here: to deliver value to the business. Don’t get me wrong: The picture of the dream product team I painted above is definitely worth pursuing! A smooth workflow and lean processes are the best way to deliver fast and effective. But whatever you are driving, never lose track of the “why?”. Otherwise, you will end up focusing on features that no one needs and processes that are good for nothing. Any of the below sound familiar? All of these might indicate that you lost track of the purpose behind your work. If that happens, it may lead to How can an Agile Coach help to get back on track? Now the most important part: How do we avoid stepping into that trap? How to refocus on what really matters? Here are some tips from me: Keep asking Whenever you have the opportunity, ask about the purpose of whatever is happening: Yes, Agile Coaches can be very annoying… Support and coach your Product Owner in value maximization techniques: Align on goals Maximizing value lies within the accountability of a Product Owner or Product Manager. So why bother with a Scrum Master or Agile Coach? A Product Manager might not work with all teams within her value stream daily, so she might not notice when the focus shifts away from the business. Having Scrum Masters or Agile Leads on all development teams will help notice the symptoms early on and react. Also, while a Product Owner is busy working with stakeholders and management on the “Why?”, the Agile Coach can support with exploring the “How?” – A good Scrum Master will have an extensive toolbox and can facilitate many value maximization techniques. So, the best way forward is a tight collaboration between the PO and the SM. Delivering fast and efficiently is important, but never lose sight of the ultimate goal: creating value for the business and its customers. Let’s keep asking the right questions and supporting each other to build products that truly matter.