Dorota Mleczko

Category: News

Why I recommend the Professional Scrum Product Owner Level 2 (PSPO II) – also for Scrum Masters

By Dorota Mleczko

The Professional Scrum Product Owner Level 2 (PSPO II) certification turned out to be much more than another credential to add to my resume—it’s a powerful tool for deepening your understanding of value creation in product management. While it’s designed for Product Owners, I believe it holds significant value for Scrum Masters as well. Here’s why: 1. Focus on Measuring the Right Things One of the key takeaways from the PSPO II exam is the emphasis on measuring what truly matters—metrics that are directly linked to value creation. The exam draws heavily from the Evidence-Based Management (EBM) Guide, a framework that encourages data-driven decision-making and continuous improvement. 2. Knowledge Beyond the Scrum Framework The PSPO II exam doesn’t just test your knowledge of the Scrum framework; it is about broader product management concepts, like crafting a compelling product vision, and understanding how product strategy aligns with business strategy. How to Prepare for the PSPO II Exam Preparing for the PSPO II exam requires more than just a surface-level understanding of Scrum. Here’s a step-by-step guide to help you get ready: 1. Read the Scrum Guide. Then read it again. Start by thoroughly reading the 2020 version of the Scrum Guide. Even if you’re familiar with it, revisiting the material is crucial. The exam covers not just the Product Owner role, but the entire Scrum framework, so you need a comprehensive understanding. 2. Study the Evidence-Based Management (EBM) Guide. Next, download and read the EBM Guide available on Scrum.org. This guide is essential for understanding the different value areas and the metrics associated with them. 3. Follow the Product Owner Learning Path Scrum.org offers a detailed learning path for advanced Product Owners, which includes the areas Managing Product with Agility and Evolving the Agile Organization. Go through everything linked on each of the pages—read articles, watch videos, and make notes on areas where your knowledge might be lacking. 4. Practice with Mock Exams Finally, and most importantly, invest in a set of practice exams. I used a series of six practice tests from Udemy, which were incredibly helpful. These tests included questions that were very similar to those on the actual exam, although not identical. After each test, review the questions you missed or were unsure about. Make notes, study the related materials, and keep practicing until you can consistently score close to 100%. By following these steps, you’ll be well-prepared to not only pass the PSPO II exam but to truly understand and apply the principles of value-driven product management in your work. Good luck! 🍀

Why I think that Agile has won

By 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.

Business value focus in software development practices

By Dorota Mleczko

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.

Why I Don’t Moderate the Daily Scrum

By Dorota Mleczko

From my perspective, the Daily Scrum is the most important of all meetings. ➡  It is where developers cooperate to plan the next 24 hours and inspect the progress towards the Sprint Goal.➡  It is the only regular meeting that happens every day.➡  It is the time when I see my whole Team in action. As a Scrum Master you can learn a lot about the Team’s dynamics and habits just by joining it and observing. For example, I once joined a Team where I observed the following: ➡ Developers reporting one by one to the Product Owner.➡ In case the PO was not present, always the same developers were running the meeting.➡ And one time: Nobody speaking, because neither the PO nor the developers who are usually running the meeting had joined (no joke, we sat in silence for 6 minutes before I asked what is happening). In such a situation I could just take over and run the meeting for the Team. But what would we learn from that? And what would happen the next time I’m not present? If the developers cannot conduct this meeting independently, it’s usually a sign of deeper issues that need addressing — issues more critical than meeting management. In the above case it turned out that there was a very hierarchical structure within the Team itself. According to the developers who did not dare to speak in the Daily, there was an unwritten rule that only the „Leads“ (= senior developers) run the meeting. Funnily enough, those „Leads“ were very surprised to learn about this rule… What did I do? After the next Daily I ran a small workshop to inspect and adapt the format of this meeting. We worked out how the developers can get the most out of it – without wasting time on reporting or waiting for anyone to start speaking. 👉 What are your experiences and challenges with the Daily? Who runs the meeting and why? hashtag#dailyscrum  hashtag#selforganisation

📄 Writing documentation is boring and unnecessary

By Dorota Mleczko

Boring? Maybe.Unnecessary? Disagree. ⏲ In the refinement you spend 15 minutes trying to remember what a ticket was about that was written a month earlier. ⏲ A stakeholder asks why their bug ticket was cancelled without a comment. You need to track down the reason. ⏲ A developer is on sick leave, and we have no idea what the status of their work was. It needs to wait until he is back. ⏲ You come back from vacation and want to catch up on some project meeting notes, to know what has been going on. But there are none. You have to ask around. ⏲ … Any of that sound familiar? At our project it happens all the time. And it causes us to lose time, information and knowledge. It even leads to general lack of transparency and major misunderstandings… What’s more, time after time it is discussed in the retrospective and other „inspect and adapt“ meetings. Everyone agrees we must document. And then it just happens all over again… 🙄 I understand that documenting tickets, meetings, code is not the most exciting part of our job. And we want to be quick and productive, with a „just do it“ approach. Even the agile manifesto says „Working software over comprehensive documentation“, right? Right. But that does not mean we don’t need to document at all. The advantages of proper documentation are, in my opinion, huge: •          Enhanced Clarity and Focus•          Improved Communication•          Easier Onboarding and Knowledge Transfer•          Quality Assurance•          Efficient Project Management•          Improved Risk Management•          High Traceability 🤔 So why do we keep falling into the „I’ll do it later (or not)“ trap? 👉 How do you manage documentation in your projects? Are you facing similar challenges? Do you have tips for us how to handle it better 🙏 hashtag#documentation hashtag#agilemanifesto hashtag#knowledgeretention