One of the new capabilities of my agile coaching practice is the ability to deliver the Scrum Alliance, Certified Agile Leadership (CAL1) class. It’s a relatively new certification for the Scrum Alliance and it targets the management and leadership levels within organizations who are planning to or who have already adopted agile approaches to software development.
I’ve been coaching agile transformations (organizations, groups, teams) for over 15 years. During that time, I’ve noticed that there are literally 3-tiers to any transformation:
- Sr. Leadership Tier
- Organizational Leadership & Management Tier
- Team Tier
Most organizations only focus the transformation or adoption towards the team level. But in my experience, success is in effectively guiding all three tiers towards agile principles, tactics, and leaner agile mindset.
In fact, I think the critical tier is in the middle.
I’ve sometimes heard it called the “frozen middle” because it’s where true agile transformation lies, but it’s the tier that often gets the least attention.
Enter – Certified Agile Leadership
The CAL is solely focused towards the middle-tier. And finally, we’re engaging leadership folks with training and coaching of their agile transformational skills.
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.
