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...
https://thepsychologist.bps.org.uk/volume-35/march-2022/persistent-irony-dunning-kruger-effect
Unskilled and unaware of it.
The relationship between confidence and competence.
Anyway, I thought I’d share this article on the DKE for your reading (and understanding) pleasure.
Stay agile my friend,
Bob.
When writing the EBAC book, my (our) perspective was largely from the position of the “universal” agile coach. One where the approaches, tactics, skills, and strategies were essentially the same no matter your place in the organization.
But there are many aspects of agile coaching where the subtleties of your place significantly influence your approaches. None is probably more varied and nuanced then whether you’re coaching as an internal (employee, full-time, FTE, role-based) coach versus an external (contractor, consultant, full or part-time, outside the organizational hierarchy) coach.
I think the differences are so compelling that I wanted to share the following table with you to sensitize you to some of the differences in perspective and approach.
While there may be differences, I want you to minimize the internal gyrations you go through to do your job. In essence, I still want you to be you as a coach. But, depending on your organizational positioning, I thought it would be useful to highlight some of these subtle and not-so-subtle differences.
I could have also titled this short post—The 3 Bs to Beginning any Agile Change…
Celebrate your history and journey
Celebrate the people who contributed to that journey
Mine thru the defensiveness and denial
Find the failures, face them, and embrace them
Every organization has induced some level of deep trauma, find it, expose it
It could be individual-based (ghost spirits); name them
I’d recommend doing this as part of an open space (or similar) event where you kick things off with your team.
Then, using these insights, craft your overarching Why for moving to agile ways of working and then leverage that to focus your strategy.
Food for thought. Stay agile my friends,
Bob.
I came across a post entitled—Stop treating managers like the bad guy, by Sander Dur. And here’s a LinkedIn thread that contains some interesting reactions to it.
I’ve written on this topic several times as I believe there’s a significant anti-pattern in the agile universe where we treat managers poorly. Largely by the same folks who claim the managers are treating them poorly. So, reciprocal disrespectful behavior.
Here are two of those articles:
https://rgalen.com/agile-training-news/2018/6/23/stop-disrespecting-managers-in-agile-contexts
https://rgalen.com/agile-training-news/2014/4/14/were-going-agile-fire-all-the-managers
In fact, I believe this is one of the primary factors that have served to drag down agile transformations. Serving as a blaming, disrespectful, and braking function that inhibits learning, growth, and forward progress.
One of my hopes for our agile future is that—
Leaders & managers develop into the agile leaders we need for tomorrow’s high-performance organizations and
Teams meet them where they are, take responsibility for their parts, and partner to create those organizations.
Well, one can hope!
Stay agile my friends,
Bob.
I saw this post by Jeff Gothelf and I felt compelled to weigh in, just a little.
First, I don’t believe Jeff needs my help. He did a great job of defending himself, his position, and his thoughts. But I didn’t want him to stand alone.
Points to be reaffirmed and made:
Cargo Cult agile is still alive and well in the world and we need to recognize it.
We need to be able to respectfully critique, debate and disagree around agile topics.
And there needs to be no room for personal attacks. Attack ideas, but don’t make it personal or attack people.
The agile world needs more Jeff Gothelf’s. Instead of attacking them, we should be thanking them. Thanking them for challenging the status quo, bringing in new ideas, and having the courage to be a bit disruptive.
Those are the attributes of the original Agile Manifesto folks and we need that more today than we did then.
So, stay agile and stay open-minded, my friends,
Bob.
While I agree 100% with the spirit of this article, I want to riff off of it from an agile transformation leadership perspective…
It’s simply not good enough for a CEO of a company that aspires to agile ways of working (transformation, business agility, flow, employee engagement, etc.) and not take a strong ownership stake in it themselves.
To simply hire someone to make things be agile without being in the game themselves. Not as a:
Sponsor
Supporter
Proponent
Advocate
Stakeholder
Funder
Cheerleader
Isn’t good enough. Not for something as powerful, as challenging, as impactful, with as much potential as changing their culture and the way they do work.
John Cutler recently wrote an article on his Beautiful Mess blog entitled—The Weeds. In it, he explores the notion of going too far into the details of a role/activity from another role perspective. Aka, getting into the weeds.
For example, a project manager might be asking too detailed questions about the design of a particular UX component and trying to reduce the effort associated with it. They have gone “into the weeds” with the developer.
A couple of things that this article made me think about including—
Someone in my network sent me the following question the other day:
One question that's been surprisingly hard to answer is "Where did the concept of a long-lived team (vs a team that adjourns after a project is complete) first surface?"
And it started me to thinking about the notion.
Today, we talk a lot about moving from a Project focus to a Product focus, that is from:
Teams are formed and then disbanded or reorganized around the dimensions of a specific project. When the project is done, the team is done.
To
Teams are formed around a product area (or function) or around a functions area (infrastructure, architecture, etc.). The teams in this case are longer-lived in that there are no artificial closures based on their work.
Clearly, the latter strategy aligns better with the notion of a self-directed, cross-functional, high-performance agile team. But to the questioner’s point, when did that surface as an intentional focus, or even a directive or thing, in the agile community?
Jon Rennie has an interesting twist here, in that, the leader is ALWAYS to blame for EVERYTHING. Well, at least the captains in the US Navy are held responsible for ship-wide mistakes.
And it got me thinking. Is this true of organizational leaders? Or technology leaders in agile contexts?
If something bad happens, we look to the following—
The Senior leader
Management
Teams
Individuals
To see who’s responsible for it? I can’t speak for all cases, but only what I’ve seen in my own experience. Typically, the organization and organizational leadership seem to look for the lowest level individuals to blame. With many fingers being pointed in all directions. In other words, I think the “captains” are held accountable in very few cases.
And is assigning blame or blaming even the point?
Or is it better to focus on learning what happened (root cause) and on preventing it from happening in the future?
I’m still mulling this one over from a leadership perspective. I thought I’d share it with you to see what you think?
Stay agile my friends,
Bob.
Another related link – https://www.military.com/daily-news/2021/11/04/navy-fires-2-top-officers-of-submarine-damaged-collision.html
My friend and colleague Mike Hall inspired me with a recent article he shared on Choosing a SAFe Training Partner.
To be clear, I was once an SPC but I fell away from being an active practitioner of SAFe. That being said, I’m often quite opinionated about it, but over time, I have less and less direct experience.
Mike is the opposite. He’s incredibly experienced with it. So, when Mike tells me something from a SAFe perspective, I know that’s not based on opinion but on hard-won experience. And I respect that.
I really appreciated his questions about engaging a SAFe training partner. But I felt there might be some additional questions to add. Not only for a training partner but for a consultant who is prescribing SAFe as the scaling solution for my organization.
