Dorota Mleczko

Category: Blog

Home » Blog
Aug 29 2024
Off

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! 🍀

Jun 28 2024
Off

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

May 13 2024
Off

I don’t care about Scrum 🤷‍♀️

By Dorota Mleczko

… nor LeSS, nor Spotify, nor SAFe nor any other framework for that matter. Well, I do a bit, because they are helpful. But I care much more about the specific needs of the Team, the Product, the Organization. And I care more about creating Business Value. And no, this is not another „Agile is dead“ post (what’s up with that anyway?). On the contrary. Being flexible about the tools and methods you apply in each context lies at the very core of agility. „Individuals and interactions over processes and tools“, remember? You can have cross-functional, high-performing Scrum Teams, and still not improve your time-to-market, because you have complicated up- or downstream processes. You can run the most perfect, super productive Dailies and Sprint Retrospectives, and still suffer from very low flow efficiency, because of unmanaged cross-team dependencies. Frameworks are helpful, but they are never the answer to all your problems. Where to get these answers then? Well, first you have to ask the right questions. 👉  Is everyone working in the same direction? Define a clear vision and make sure all value streams are working towards it. 👉  Are we building the right products? Implement short and frequent feedback loops with your stakeholders and users. 👉  What is slowing us down? Visualize your processes to identify pain points and bottlenecks. 👉  Is our system as simple as possible? Map out cross-team dependencies, reduce where possible and actively manage the rest. 👉  Are our communication channels effective? Question whether the current modes of communication facilitate clear, concise, and open dialogue across teams, stakeholders, and users. And, most importantly: 👉  Are the people creating the business value still in the center of our processes and tools? Check your expert’s happiness and adjust if needed. You will quickly find that the answers to these questions differ strongly depending on the context. What more, even the questions that should be asked in the first place will vary from team to team, from organization to organization, and from moment to moment. So, how can there be one right answer, one proper framework for all our problems? Or is there? 😉 Let me know in the comments. hashtag#individualsoverprocesses  hashtag#agileisalive

Feb 23 2024
Off

📄 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