Bob's Blog
Bob is a prolific blogger who simply enjoys sharing his experiences with colleagues in the Agile Community. Topics revolve around Scrum, XP, Kanban, Project Management, Business Analysis, Testing, Leadership and General Musings.
Check back often as we've always got something to say...
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.
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:
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.
I’ve been teaching and coaching Scrum for nearly 20 years. During that time, I’ve always tried to stay true to the basic Scrum guidance and the Scrum Guide. But I’ve also shared my own practical experience.
One of the things that I’ve been consistent about in my guidance is that the ScrumMaster is NOT a manager or HR role. That is, they should not be “mucking around” with personnel performance issues. At least not directly.
For example, they should not be writing/executing Performance Improvement Plans (PIPs) or removing folks from teams or firing folks.
So, you can imagine my shock & chagrin when I saw an article by Barry Overeem that seemed to be saying the opposite. Now I’ve followed Barry for many years and I normally align with his recommendations. Or at least I see the soundness in his perspective. And often he simply makes me think about things in new ways. Which I appreciate.
But in this case, I think this is a very dangerous point of view and flat out wrong. So, let me share my thoughts…
There’s been a movement afoot in the agile community for a while. It’s about getting back to basics. I characterize it as:
We’ve lost the essence of agility. We’ve forgotten the very things that got everyone excited in the first place. The simplicity. The power of the team. The results that an engaged customer can inspire.
We’ve all been there. Someone walks up to you in the hallway, musters up their courage and gives the gift that keeps on giving – direct, thoughtful, feedback.
In this case, I’m presuming it’s constructive or otherwise challenging feedback to share with you. And if you’re a leader within the organization, you have to realize that it was probably hard for them to muster the courage to give you that feedback. Let’s say it’s critical.
Or conversely, you're walking down the hall and run into a colleague. And you ask them for feedback on how you're handling yourself in a critical agile project. As a leader. Again, they muster up their courage and share honest and open feedback with you.
So, what is the next thing you do?
Of course, you don’t:
Instead, you ask them for precise examples that support the feedback they just gave you. Probing, inquiring, and looking for direct evidence. Picture an episode of Law & Order. Clearly, putting them on the defensive and making the feedback their challenge versus your own.
If you’ve followed my writing, you know that I’m quite enamored with Kim Scott and her Radical Candor book. (check out another post here) I saw this blogs picture on a LinkedIn post and it inspired me to write this short reply.
Whenever someone gives you constructive feedback, you want to consider it a gift. Don’t challenge them. And don't ask them for "supporting evidence".
Instead, simply accept it and consider it. Most of the time, it’s the gift that keeps on giving.
Stay agile my friends,
Bob.
For years and years, I've been a strong advocate of goal-setting within your agile teams. Ares where I think goals are important include:
A colleague of mine in Dallas, Jack Schwartz, sent me an email asking the following:
Bob,
I’m working on a presentation focused towards Hiring a ScrumMaster and I wonder if you could provide some insights to the following questions:
Thanks,
Jack.
Well, Jack here is my initial stab at a response…
February 5, 2018
I’m experienced enough in the Scrum community to remember several early attempts at assessing the maturity of agile and Scrum teams.
My point in taking you down “history lane” is that agile assessment tools and frameworks have been thought about since ~2007. So, for the past 10+ years.
The problem is, that none of these, and the ones introduced later, have really done an effective job of helping teams improve.
I came across a blog post by Tricia Broderick in January 2018. I often read Tricia’s thoughts and really enjoy her perspectives. This one was entitled Leadership Is Lonely and it largely lamented this aspect of leadership. To her credit, Tricia shared some activities that leaders could use to combat the effects of the inherent loneliness.
But I wanted to provide a different take or perspective.
I’ve been in leadership roles for over 25 years. In the early days of my leadership journey, I felt very much like Tricia. In fact, it was one of my early and shocking discoveries of leadership.
When I wasn’t leading, I was “friends” with most of my work colleagues.
But when I was promoted to a leadership role, things changed. I was no longer Bob. I suddenly became “the Boss”. And in today’s terms, that often meant being equated to the pointy-haired boss in the Dilbert cartoons. It also meant that it was suddenly a very lonely place to be.
