For questions about practices in #Scrum, there are only ever TWO answers. If the context of the question is about the framework itself, and thus the Scrum Guide explicitly answers it, then there's your answer. For all other questions, the answer is "it depends on the context".
For example, I just saw a question in a #Scrum Master group: "What is the role of the PO in daily standup?" A long thread of opinionated answers ensued. NO! If you're a Scrum Master, & you are using Scrum, the answer is simple - it's the "daily scrum", & it is for the developers.
"But sometimes it is very valuable to have the PO at the standup!", freshly minted CSM's cry. "They can share new bugs with the team, sign off stories and understand progress / get the team back on track". Sigh. NO! IT IS FOR THE DEVELOPERS. READ THE GUIDE!
Folks seem to argue as if the daily scrum is the only opportunity for the developers to interact with the PO. In a healthy #scrum team, the whole team collaborates on a continuous basis. Wanting to shove all interaction into the daily scrum is a symptom of a divided team.
The daily #scrum is specifically for the developers to talk about development activity, and align on the day's plan to move toward the sprint goal. Any other convos that need to be had within themselves (e.g. tech), or with the PO (or others) can be done outside of that meeting.
So back to the OT. I think this is one of the reasons folks struggle so badly with #scrum. They're basing how to do it on opinions, not the guide. The truth is - you will NEVER have a situation where everyone in a team agrees how to do everything in their process.
The solution to this is to follow the guide where explicit, and use the built-in inspection and adaptation of your process for the other stuff. If the whole team wants the PO at daily scrum, great! Again, a healthy scrum team refers to the guide and remains mindful of deviations.
But that is a specific decision in a specific context. It's never the "right" answer to say that the PO should be at the daily scrum. The guide is explicit about it being a meeting for the developers. But a healthy #scrum team is looking to be EFFECTIVE, not just to "do scrum".
So, a healthy #scrum team who wants the PO at the daily scrum would have them there, but still recognise that the meeting is for the developers (i.e. the PO, SM AND DEVELOPERS ALL RECOGNISE THIS). If there is disagreement, sticking with the guide seems a sensible approach to me.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Any imposed process, explicit (e.g. you must do standups) or implicit (e.g. you must do #agile) is likely to result in anything ranging from low performance to dysfunction. 1/
High performance comes from imposing enabling constraints (e.g. ensure we have a shippable product at all times, ensure we have a frequent feedback loop with the customer, ensure you are continuously improving), not process. 2/
Tell the team they can create whatever process they want, and that you will help remove any roadblocks. But take the constraints seriously, and make the team accountable to them. Show me the software! Show me how we're incorporating feedback! Show me how you're improving! 3/
Trying a new angle for teaching story slicing, one of the biggest struggles for teams attempting #agile ways of working and arguably the most important practice to understand, given we are trying to deliver value to customers in very short cycles. Read on if you are interested.
The way I see it, there are 3 levels of story slicing, each of which is beneficial and necessary to be able to deliver shippable increments consistently in 2 wks or less. I am currently calling them Capability Slicing, Functional Slicing and Implementation Slicing. What are they?
Capability Slicing is the narrowing of a broader capability* into more precise ones, each independently valuable and implementable and, by necessity, smaller in potential scope.
*The story of enabling a human being to achieve something they cannot currently achieve