It dawned on me the other day. I client asked for role-based guidance around ScrumMasters and Product Owners. One of my pointers was to the Meta-cast podcast that Josh Anderson and I do together.
But there are 100+ and counting podcasts there and I realized that it's very hard to cull through them all to get role-specific advice.
So I thought I'd pull together three lists in this post that align with the three Scrum roles: ScrumMaster, Product Owner, and Team. It's not intended to be exhaustive, but I think you'll find value in the discussions.
Every year I try to spend time on my own training. I usually start thinking about two things the year before:
- What are some knowledge gaps that I have that I’d like to fill, and
- What are upcoming trends that will cause me to become obsolete if I don’t get ahead of them?
Then I review the available courses and I’ll try to come up with 2-3 things that I’ll focus on for improvement.
Last year I posted my first "Sharpening the Saw" post in June. That inspired me to do it again for 2017, but closer to the beginning of the year. You'll probably see this become an annual post to remind me (and perhaps you) to plot a journey of continuous learning.
In 2001 I was laid off from Lucent Corporation in Raleigh, NC. At the time, I was a software development director leading a group of developers and testers implementing optical networking devices. It was incredibly complex work and the teams were dedicated to doing great things.
This was just post the 9/11 attack and the Telecom bubble burst so to speak. So, all of the large Telecomm companies were impacted.
I was placed on the building close-out crew, so I had a long period of time “managing” the reduction. At that time, I began to write a book. I completed it in 2002 and it was finally published in December 2004. I remember at the time being incredibly impatient as the publisher, Dorset House, took its sweet time in the editorial and printing processes.
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.
