A ScrumMaster asked me the other day how they should handle the situation where half their team doesn’t seem to care about the work. They don’t seem to be motivated. They seem to be slacking…a lot. And where two individuals seem to be doing all the work. And they seem to be burning out.
A senior leader in an organization that I’m coaching asked me the following when he found out I would be meeting with his boss. He asked me to tell him that they have too much work to do. That they are being stretched over capacity and that it’s causing delivery, quality and morale problems. In fact, the house of cards is about to fall.
I was training a class at a client the other day and three individuals, not at the same time, asked me to escalate their impediments. One impediment was that their leaders were excessively interrupting the sprints. Creating chaos. Another was that the priorities changed constantly. And the final, small problem, was that the leadership team expected the team to exceed their capacity by 350%. They wanted me to address these (fix it) with their organizational leaders. And, believe it or not, they were all serious.
This is a bit uncomfortable for me to admit, but I have some confessions to make…
I’m a SAFe SPC;
I’ve attended a 2-day Nexus training;
I plan on attending / co-teaching Scrum @ Scale with Don MacIntyre in September;
I’ve studied (I mean studied!) and contrasted DAD and LeSS;
I’ve actively coached SAFe organizations;
I’ve been leveraging simple scaling techniques (Scrum of Scrums, bits of SAFe) for well over a decade.
So, it’s fair to say that “agile scaling” is in my bones, in my DNA, and that I’m fairly experienced. And it’s incredibly easy for me to meet a larger scale client and begin discussing scaling aspects quite early in our coaching relationship.
I have some coaching acquaintances who’ve joined a relatively large firm. They’re tasked with being the internal agile coaches and leading the organization’s agile transformation.
Several times members of the organization’s leadership team have reached out to me to come in and discuss various aspects of high-performance agility. Topics like culture, scaling, and leadership agility was of heavy interest. I think they were simply looking to get an outside, experienced coach to come in and provide insights. Not undermine the internal coaches.
But each time the internal coaching team squashed the inquiry and insisted that they do the session. In fact, in other cases of invitation, they wanted to go over my “talking points” to ensure that I wouldn’t say something that differed with their guidance or perspective. Given that level of scrutiny, I respectfully withdrew any interest.
This is an actual example. But I’ve seen and heard it repeated many times in my own agile journey.
I’ve been blogging for quite a while, but I just realized that I have rarely (never) made recommendations for agile books to read as part of your learning journey. And as an author, I’m surprised at myself for this gap. A gap that I intend to start closing with this post.
My inspiration for starting to share on great books comes from Jeff Payne, who shared a similar post here - https://www.techwell.com/techwell-insights/2018/03/3-must-read-books-good-agile-foundation
Thanks, Jeff!
And this isn’t the end, but only the beginning. Look for the occasional post about learning advice for various aspects of your journey. Starting with this one…from the beginning.
I see Scrum Alliance certification classes advertised this way all of the time. Declaring minimal to no, to 100% no PowerPoints in the classes. And it’s not only the Scrum Alliance classes, but many other organizations and trainers proudly declare it.
One of the trends that have influenced this is the work of Sharon Bowman and her Training from the Back of the Room approach to adult learning. I attended the training a few years ago and it definitely changed the way I approach constructing classes, the learning, and the medium/mechanisms I used to foster the learning.
That being said, I don’t have a class today that is 100% PowerPoint-free. I just don’t feel that PowerPoint is inherently bad in its use for training. I view it as simply a tool, one of many, that I leverage. But clearly, I’m a Dinosaur in my thinking, as not many others view things the same way.
Death by PowerPoint
I think one of the reactions driving these statements is the scar tissue that poorly constructed and delivered PowerPoint classes has done to people. You can see it in their eyes of countless students who have been forced to sit through such training.
The other part of the problem is we all learn in different ways. Some of us prefer PowerPoints done well and learn quite effectively that way. Others of us want a more experiential and collaborated approach, where the learning emerges instead of us being told it. Information density is also a challenge. Especially when we’re trying to convey complex information or problems.
I was never a huge Simon and Garfunkel fan but there are a few songs of theirs that really stood out for me as I was growing up.
One of them is The Sounds of Silence.
It’s a haunting vision of the future.
And it swirled in my head as I read an article by Chris Murman. Chris is a friend and colleague that I find incredibly thoughtful about his (and others) agile journeys. But the article I found was published in September 2017, so nearly a year ago. And unfortunately, I missed it.
The article is entitled – What Can You Do About Organizational Silence?
And it focuses on a common corporate cultural phenomenon where the following occurs:
Leaders drive most of the “thinking”
Alternate ideas are not brought up
Discussion and debate are not realized
Disagreement with the status quo is discouraged
Creative ideas aren’t even suggested
And where silence, connoting tacit agreement, is the norm.
More than a few years ago, I visited a client in Greensboro, NC. I did a little consulting there, but it really wasn’t a longer-term gig.
What stood out to me, after all of these years, is that folks could bring their dogs into work. And everyone seemed to do just that.
There were dogs roaming free in the halls.
There were dog play areas.
There were dogs at their owner’s desks.
And those that didn’t have dogs were playing with others dogs.
And yes, there was the occasional “doggie accident” ;-)
It was a wonderful environment. Instead of feeling like an office space, it felt like a home that I was visiting. A comfortable home where the family loved their pets.
This is a continuation of Bad Product Ownership anti-patterns that I’ve seen all too often. And that I would encourage you and your organizations to avoid.
Without more context setting, let’s get onto the patterns –
You might be a BAD Product Owner IF you…
Too often revert to explore how and how long, over focusing on the what
It’s probably human nature.
When I ask a contractor to come over to my home to estimate fixing a problem. I usually focus on how long it will take them and how they will approach the repair.
Mike Cottmeyer has been one of my longer-term colleagues in the agile community. He’s built a nice coaching business in the Atlanta area and has been contributing his ideas for quite some time. He’s someone that, when he writes something, I usually read it.
I don’t always agree with Mike. But that’s ok. He always makes me think (or rethink) differently and that’s quite valuable to me. I like to be challenged.
He recently wrote a blog post entitled: Kanban Isn’t The Answer To Bad Product Ownership. In it, he made the case the title implies. And he made it quite convincingly. But the post also made me consider a couple of things:
How fundamentally important the Product Owner role is. Specifically, in Scrum, but generally in agile teams. I’ve seen the difference that an excellent Product Owner can make to a team. And conversely, the damage “bad ones” can do.
And lament the number of bad product owners (organizational, group, and individuals) that I’ve seen in my own coaching travels.
So, in this piece, I want to explore some of the You might be a bad product owner, IF… patterns that I’ve seen. In the hopes that we might be able to avoid some of them.
I wrote a coaching article a while ago that illustrated an agile coaching anti-pattern. It was quite well-read and I received quite a bit of feedback on it.
One of the folks who responded was Mick Maguire.
https://www.linkedin.com/feed/update/urn:li:activity:6345281715686166528
A great article by Bob Galen, he shines a light on an all too common pattern, especially among the late adopter market that we are in these days... My advice... If you are about to engage agile coaching, and you don't want to waste (a very big pile of) your money, make sure the first conversations are "what does success look like?" and "How will we know if we are getting there?...”
I’m not focusing on the coaching part of his reply, but more so reacting to this entry level statement:
“Especially among the late adopter market that we are in these days…”
Mick’s comment has stuck with me since I read his reply. Making me think about Geoffrey Moore’s, Crossing the Chasm and where the agile (movement, methods, frameworks, etc.) might be on that scale.
