We always talk a good game about the concept of Servant Leadership in agile contexts. But I have a hypothetical thought experiment for you. What if…
There was a relatively small or mature start-up company;
Where the founders were developers or individual contributors;
They hired a leadership team to “run” the company, but maintained primary ownership;
The founders are still actively on the board and guiding overall strategy;
But they simply enjoyed the product innovation and creation process associated with being a team member.
Now, as time goes on, these folks simply blend into the woodwork of the “teams”.
I’ve been involved in agile for ~20 years and I’ve noticed a consistent anti-pattern that never seems to change.
People wait too long to ask for help!
I’ve noticed it in my coaching. By the time I usually get called into a situation where an organization is attempting to implement agile is, dare I say it, things are off the rails. Sure, a part of me thinks that’s a good or normal thing. But that’s the revenue generation part of me.
The principled agile coach part of me always wishes that they had reached out earlier. That it would have saved so much aggravation and frustration, wasted time & effort, and ultimately cost.
But it’s not just as a coach. It also applies to my leadership experience too.
If a project was off-track or a commitment would be missed, I usually found out at the last minute. Far later than when I could have actually helped or done something. I always work hard as a leader to create safety for bad news, to be approachable, and to be grateful for it. Very hard. But it still shocked me how often folks wait too long to share something with me. I often wonder, what did I have to do to create the culture where sharing challenges was rewarded, was the norm, and not feared?
There’s a leadership anti-pattern that’s been around for a long, long time. I noticed it in the 1980s, and I’m sure it preceded that decade by quite a few more decades. If not being a permanent dysfunctional trap in perpetuity for all leaders.
I’ll call it meeting-itis.
The primary symptom is leaders who measure the quality of their day by—
I shared a post a while ago focused on coaching alignment between coaches and not making assumptions that we’re aligned. It was a personal story where I assumed something when I should have checked in and aligned with my partner coach.
A friend and colleague of mine, Richard Khor made a nice comment to the post on LinkedIn that inspired this post/reaction. Here’s his comment…
Awesome post. Another assumption that is often missed is the direction or experiments that were done before. In other words, coming behind another coach and making the bad assumptions that what was there before was wrong.
And this resonated with me for a while. I’m embarrassed to say that I’ve often been critical of what I’ve found going into a new coaching context. I don’t personalize it and start blaming my predecessor coaches, either internal or external, but I do point out what I perceive as mistakes.
I wrote the first edition of my Scrum Product Ownership book in 2009. Looking back, twelve years seems like an eternity in the agile universe. Perhaps it is. Since then, I’ve published two more editions, with the last hitting the streets in 2019. At this point, I don’t envision there being a 4th edition, but you never know.
Around 2012, I developed a Product Ownership maturity and assessment tool to accompany the book’s themes and ideas. It was a simple spreadsheet with ~20 areas of consideration for individual product owners or agile product organizations.
I was always somewhat disappointed with the ease of use and approachability of the assessment tool, but I really never had the time to change the delivery format. Nonetheless, there were quite a few people who were actively using it and gaining value from the insights.
But enough background…
We were discussing the notion of having hard, dare I say it, crucial conversations the other day in our Moose Herd session. Conversations that are challenging. Conversations where you speak truth to power. Conversations that are risky and require courage and fortitude.
One of the things I brought up was the notion of preparing for one of these. And the idea of establishing your 100% truth prior to the meeting. Sitting down, putting everything aside, and establishing what would be the 100% discussion if you were talking to your best friend, close confidant, or trusted advisor? Without any filtering, obfuscation, or any risk of ramifications.
What would that conversation look like? That then becomes the baseline for your conversation. The preferred target if you will.
Now perhaps, you can’t have that level of clarity and honesty. So, start walking back from that baseline.
Establishing what you are comfortable saying. Considering things like—
For years I’ve been asking and coaching Scrum Masters to partner with the managers/leaders of their team members. To sit down with them periodically, weekly perhaps, and over coffee, to discuss their teams. For example—
Sharing stories of success for their reports
Sharing the challenges (delivery, mindset, performance, etc.)
Sharing the team’s vision, goals, impediments, etc.
Discussing alignment with organizational goals
Asking for help or looking for guidance
All with an eye towards giving each manager a window into the dynamics of the team and how their direct reports are “doing”.
But this isn’t a performance report or a status report. It’s a partnership, as the manager and Scrum Master are in a unique collaborative relationship to build the overall maturity and performance of the overall team AND each individual.
And the discussions should be focused on continuous improvement and actions the manager can take to coach each individual. Which is, in fact, their job.
I’ve seen cobbled together Scrum teams for years, but I realized just the other day that I’ve never written about them. So, now I will…
What are they?
They are an anti-pattern and are a team in-name-only. That is, there is no collaboration because everyone works on a unique product, application, service, or platform.
I often see this anti-pattern in Ops organizations where the coverall company is adopting Scrum. The leadership team feels compelled to form teams everywhere—out of individuals with very different skill-sets, roles, and application-level responsibilities.
For example, if it’s an IT administration and support group, probably every member of the group has 1-10 applications or platforms that they are individually supporting. With little to no overlap in skills or area ownership across team members.
I’m not sure everyone is aware of some of the greats who have come before us but there have been many in our software development space. One of them is Gerald Weinberg.
When I think of Jerry, I think of the phrase—standing on the shoulders of giants. His writing has had a profound impact on me and many others in our software and agile communities. If you haven’t heard of him, I’d encourage you to become more familiar with his timeless advice and wisdom. I believe I’ve heard him say he’d written ~100 books, so there’s a lot of wisdom available. Sadly, Jerry passed away in 2018.
https://geraldmweinberg.com/
https://www.infoq.com/news/2018/08/jerry-weinberg-passed-away/
A bit of Weinberg
I want to amplify two of Jerry’s Secrets of Consulting principles in this post:
First, there is—
The Law of the Hammer: “the child who receives a hammer for Christmas will discover that everything needs pounding.”
And second, there is—
Prescott’s Pickle Principle: “Cucumbers get more pickled than brine gets cucumbered.”
I want to bring both of these principles into the world of Agile Coaching. I know, I know what could hammers and pickles have to do with coaching? Well, let’s see…
