Does the PO need to be at standup?
As an agile coach, this question tends to come up a lot. But before I answer, I want to provide some background. In my experience, this kind of question most frequently comes from a team that is still struggling to some degree with what I would call mechanical agile.
This is the age old analogy of "doing versus being", a team that may still be in the Shu phase of the Shu Ha Ri learning curve. I say this without any judgment because every team has had to go through this phase when learning agile. In order to achieve the desired outcomes of being agile a team must often first learn the rules and mechanics of doing agile. A team that asks this question will often still think of agile as a new set of rules, ceremonies, and a very specifically executed process that is still a little awkward to them. Over time, with a little guidance but mostly experience, a team will learn to understand the full breadth of the agile mindset and why we do the things we do.
The agile mindset is complex and comprised of perhaps seven different mindsets and cultures in one. I've described this previously in the post “What is the agile mindset?”
- An Iterative Mindset. Create value in small, iterative steps allowing for early and frequent feedback on each piece of work, which helps eliminate waste and build better products faster. Be data-driven, evidence-based and use that data to decide what to do more of and what to do next.
- A Product Culture. Form long-lasting, durable and dedicated product teams that reflect the company’s focus, vision, and purpose. Have a top-down vision that influences the teams’ roadmaps and day-to-day work. Prioritize diligently. Build and support only so many products and services, and do them well.
- A Customer-Centric Mindset. Include the big picture, product vision and an appreciation for WHY it matters to users before doing anything. Don’t guess what customers want, be customer-driven and empirical about it.
- A Culture of Learning. Team members share knowledge, make learning a priority, and invest in communities that grow people and skills that benefit the company. All failures and mistakes are opportunities to learn something.
- A Culture of Experimentation. A Design Thinking mindset is utilized from idea formation through delivery. Instead of requirements, think hypotheses. What’s the smallest thing we can do to learn something?
- A Culture of Continuous Improvement. Teams are empowered to change and improve their own process. Self-reflection, transparency, courage, and respect lead to sustainable value delivery and better results.
- A Culture of Psychological Safety. People will not be punished or humiliated for speaking up with any ideas, questions, concerns or mistakes. This breeds greater innovation, inclusive collaboration and a greater flow of ideas that can impact our products, people, and company.
A team that has begun to embrace the agile mindset will instantly know the answer to the question "should the PO be at every stand up?" As they will also understand why we don’t track estimates in hours or how to think about a velocity that is fluctuating or whether it’s ok to change items in your sprint backlog, when and how often to include stakeholders in the work, whether we always need to use the ‘as a user, I’d like to’ syntax, whether it’s ok to skip a refinement session, and just how much you need to document in user stories… to name a few.
When you embrace the agile mindset, these things become clear because you understand the WHY. Why we work this way, what really matters, and which rules you’re ready to bend for what reasons. The answer is almost always “will it be better for the good of the customer, our company, and/or our team?” (in that order)
So, to more specifically answer the question about the PO missing a standup occasionally, if you understand the purpose of the daily standup you know that you should strive to find points of collaboration, escalate any challenges slowing the team down, and see how you can work together as a team to get things done sooner. If not every team member can be there, you do the best you can. The Product Owner can and should make themselves available as much as possible to the team. However, that job of Product Owner is very difficult and may require them to meet with stakeholders or address other challenges or help understand requirements from other subject matter experts and may not be able to make every standup meeting (as they consider whether their actions are for the good of the customer, the company, the product, the team, etc.) That should not stop the team from asking the Product Owner any questions in real time or at the very next earliest convenience. Most Product Owners find ways to be at most standups to answer questions in real time, but if they are good at what they do and they’re not there, you can trust they are doing something else very important that will help the team in the long run.
In agile, we slowly learn to embrace the fact that literally anything may change at any time and, as a team, we need to do the best we can the make the best decisions to do our best work taking everything into account. And that, as expected, does take some time getting used to.
Hi, I’m Brian Link, an Enterprise Agile Coach who loves his job helping people. I call myself and my company the “Practical Agilist” because I pride myself on helping others distill down the practices and frameworks of the agile universe into easy to understand and simple common sense. I offer fractional agile coaching services to help teams improve affordably. See more at FractionalAgileCoach.com
How well is your team “being agile”? Our self-assessment tool focuses on 24 topics of modern ways of working including the Agile Manifesto and Modern Agile basics, XP, Design Thinking, Lean, DevOps, and Systems Thinking. It comes with deep links into the Practical Agilist Guidebook to aid continuous improvement in teams of any kind. Learn more at MakeTeamsAwesome.com
The Practical Agilist Guidebook is a reference guide that gives easy to understand advice as if you had an agile coach showing you why the topic is important, what you can start doing about it, scrum master tips, AI prompts to dig deeper, and tons of third party references describing similar perspectives. Learn more at PracticalAgilistGuidebook.com
Follow me here on Medium, subscribe, or find me on LinkedIn, or Twitter.
