Dorota Mleczko

Tag: tag2

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