In his latest newsletter, Len Lagestee wrote about Even Happier Product Owners. The piece shared 9 conditions of happiness for the Product Owner. Here’s a link to the blog post.
And here’s the list:
- They are immersed with their customers;
- They have the time and space to be visionary and creative;
- They have true ownership over their product;
- They are receiving meaningful feedback about the performance of their products;
- They have a positive working relationship with their Scrum Master;
- They have an even better relationship with technical leads and designers;
- They are proud of what the team is delivering;
- They have embraced their constraints;
- And, they are keeping themselves healthy.
I really like Len’s list as a baseline for the happiness and performance of the Product Owner role. I’d like to compare the list against my 4-Quadrants of the Product Owner role model.
Mike Cohn in a recent newsletter entitled: The Dangers of Definition of Ready made some solid points that have had me “thinking” ever since I read it.
You see, I’ve been a proponent of DoR for at least the past five years or longer in my coaching. I often “couple” the discussion with two areas:
- Definition of Done
- And as an “exit criteria” for Backlog Refinement
I actually consider DoR to be one of the healthier agile practices and I often recommend it to my clients. So I read Mike’s cautionary article with some trepidation. Hoping that I haven’t been misleading my clients in some way.
I’ve captured Mike’s exception to DoR in the below snippet from his post:
Introduction
This description is intended to help guide the implementations of Scrum of Scrums at Program / Train level.
It all started with this picture that Mike Cohn published over 10 years ago. In the explanation he briefly mentioned a hierarchical structure where multiple Scrum teams get together when they are working on related projects.
Often I explain it as: team-based Scrum behaviors, just up a level.
https://www.scrumalliance.org/community/articles/2007/may/advice-on-conducting-the-scrum-of-scrums-meeting
I’ve been training and coaching agile teams for more than 15 years. While I’ve seen quite a lot of unique dysfunctions, one of the most prevalent is the overall lack of trust leadership trust in their teams.
There, I said it.
Quite often I use the term “little t” trust so that folks aren’t too offended, because really, nobody wants to admit that they don’t TRUST someone in today’s organizations. At least not out loud and visibly.
But the harsh reality is that most leaders do no trust their teams. And the other, even harsher reality, is that the teams know that they are untrusted.
I just read a truly interesting HBR article that focused on the role of management versus team members themselves in fostering an environment of creativity and innovation.
Most of the discussions today in this space, at least in my experience, are focused towards leadership or management being responsible for innovation. That is – in setting up the environment
Very little of the focus is team ward. In that, the team bears some responsibility for its own behavior, energy, and focus towards innovation.
The HBR article had some survey data that puts “the blame” squarely on both shoulders – that of “management” and the “team” in establishing the right climate.
In my view, that’s the right focus since we all play a part in creating an environment of experimentation, innovation, and creativity.
I read an article on LinkedIn by Ewan O'Leary that really, really resonated with me.
https://www.linkedin.com/pulse/i-am-professional-agile-coach-ewan-o-leary
I fell in love with his list. Mostly because it shined a light on my own journey and the work I need to do each and every day to become a better, more present, and more connected coach.
#5 is an area where I often fall down in my journey. I sometimes use the term "that's not Agile" in my coaching, passing judgment and elevating agile above everything else. I need to stop that. I also continuously check on #8 as I engage so many people and contexts as a leading agile coach.
Anyway, without further adieu, here's the list:
- I believe in the innate value and potential of all human beings.
- I believe that Agile is a mindset that orients me towards human excellence.
- I believe that my own transformation is the path to transforming others, transforming organizations and transforming the world.
- I believe that I should do no harm, and wherever possible, improve psychological safety.
- I believe I should avoid judgement of others who I may feel are operating from a different developmental level.
- I embrace my own authenticity and share it in connection with others except where my authenticity may create unsafe conditions for them.
- I believe that I am oriented towards using my capability for good in the world.
- I practice humility and compassion, with a focus on kindness, recognizing my own shadow as it shows up in the work I do with others.
- I honor and respect each individual as the author of their own journey, free from manipulation or coercion.
- When I fail to adhere to these principles, I acknowledge my failure and its impact on others and harness it for my own development.
I am a Professional Agile Coach
I want to strongly encourage you to read Ewan's post and the comments it's received. There are great insights there as well.
And even though I'm continuously working on the list in my coaching and personal journey, I do believe: I am a Professional Agile Coach.
Stay agile my friends!
Bob.
At the end of 2016, Josh and I had published 106 posts on our Meta-Cast agile podcast that we started in January of 2010. So, we've been LIVE for 7 years now.
In that time, we've published on virtually any agile topic you can think of. I thought I'd share our Top 3 podcasts from 2016.
In this segment, we actually review one of our early podcasts that focused on agile testing and then shared some of our updated thoughts and reactions to the topic. It turns out that much remained the same, but there were difference (shifts) in our thinking.
In this segment, we explored the "movement" that is implying that agile is DEAD. We look at the forces behind it, the why if you will. But we also weigh-in on our own thoughts. And if it's not dead, where IS agile now and where is it GOING.
What's interesting in this segment is that Josh shares his direct experience at The Dude implementing agile methods. His focus has been on Scrum, Spotify, and a bit of SAFe. He characterizes it as The Agile Donut. Listen in.
The Meta-Cast is into it's 8'th year. We hope you continue to follow us and that we continue to provide value to the community.
Stay agile our friends!
Bob.
If you know me at all, you know that I speak at approximately 15-20 events per year. Sometimes, at small local conferences. Other times, at larger national conferences. And still at other times, I'm lucky enough to be invited to international events.
The reason I do it is much less about marketing or exposure, and much more about sharing my ideas in what I view as the "agile community". Even though I'm a strong introvert, I enjoy getting out there and meeting people. Getting the opportunity to share, debate, network, argue, and simply chat about all things agile (and occasionally other topics ;-)
In my agile coaching and training journey, I spend a lot of time discussing a wide variety of topics. But there are themes that form a “Top 10” of topics that everyone seems to be interested in.
One of those items is how to handle bugs. Questions like:
- Do you estimate bugs (planning poker - points)?
- Are bugs equivalent to stories?
- When do you “file a bug” while sprinting?
- Do you count bugs as part of your velocity?
- Can you deliver a story in a sprint with bugs still open?
come to the surface in my classes and at conferences with amazing frequency. I often smile inside in amazement at the level of interest focused towards “bugs”. But that being said, it is an important subject for agile teams and I thought I’d discuss my views towards handling bugs in the above contexts.
In my previous post I shared about experience I’ve had in “connecting” UX activity into Scrum development teams. I tried to explain a pattern of collaborative partnering over either embedded UX in the teams or independent UX outside of the teams.
I thought I’d share another story that illustrates an aspect of these ideas.
A Story
Not that long ago I was working with a client helping them understand and practice release-level planning across their Scrum teams. Some of the challenges they were having revolved around incorporating UX design work and cross-team dependencies in their projects.
