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.
Julee Everett and Ryan Ripley shared a wonderful article on making technical debt more visible. In that article, they focus on visual metrics that illustrate progress in cleaning up debt.
I’d encourage you to read it.
Inspired!
The article also made me think a bit about my own experience with technical debt and how to influence the organization to take it more seriously. Here are some advice tidbits to make your technical debt more visible –
There are individuals who have influenced my professional journey significantly. Sometimes, by working with me directly. Other times, by their writing or position in our software community. And other times, simply as a role model.
I've started a segment on my blog called – My Heroes. I’ll post intermittently, perhaps every 1-2 months. But it serves as a reminder to me to be thoughtful and appreciative of the folks who’ve influenced my growth and skills. And of course, they get none of the credit for my many foibles.
The fourth one up is: Mike Cohn
Mike is one of those folks in the agile community that influences things without taking an obnoxious or too controversial stand. He's supremely experienced, is very pragmatic, and simply shares what has worked for him.
I first "met" Mike by reading his books. He wrote two of the most influential books in the "early days" of Scrum and agile.
these books were seminal at the time when many of us were really struggling with agile requirements (user stories) and agile planning. From my point-of-view, they were game-changing in providing practical guidance and advice for agile teams when it was needed the most.
Perhaps it’s just me, but I’ve been indoctrinated into the Tuckman Model as THE view or model when it comes to team maturation and overall health.
You all remember Tuckman, don’t you?
He presented the following stages:
- Forming,
- Storming,
- Norming,
- and Performing
- sometimes Adjourning
that teams go through in their evolution to a solidly performing state.
One of the things that it’s influenced in my coaching and leadership style is the predilection to honor the team. That is, once a team is formed and performing, I am loathed to break them up for whatever reason. Even good reasons like the business priorities have changed or there is a desperate need for the skills of one team member in another team. Or even, the team has some dysfunctional relationships brewing.
