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...
Viewing entries tagged
courage
A short time ago I was working with an agile coach. He was quite experienced and well known in the agile community. He also held a wide variety of certifications.
We were working together on a project that had, if I were to be honest, quite a few cultural and organizational challenges.
There was one specific individual who always seemed to be the most challenging. My coaching colleague and I were talking about them one day and he was grousing (complaining) about them to me.
No is a very tricky word. I often talk about agile teams needing to “just say No” to various things. For example:
Then I’m looking for the team to say No. Whenever I bring this up in classes or presentations, I always get pushback. Always. Usually its not based on the situation, but to the word. It seems No is a word that nobody likes using in the workplace.
There’s a wonderful video by Henrik Kniberg where he explores the role of the Scrum Product Owner. In it he makes the point that the most important word that a Product Owner can use is No. That it’s incredibly easy to say – Yes to every request. To pretend that things are always feasible or easy. But that No is important. No implies that trade-off decisions need to be made on the part of the customer or the organizations leadership. That the word leads to thinking, discussion, and decision-making.
One of my favorite movies of all time is A Few Good Men with Jack Nicholson and Tom Cruise. I can picture that highly charged confrontation at the end clearly in my mind. You know the one.
Tom Cruise says—I want the Truth…
And Jack Nicholson leans forward, with that classic look, and says—
You Can’t Handle the Truth!
What a climax to the film. I get chills every time I watch that scene.
I’ve been thinking more and more in my coaching about why leaders and managers often wait too long to ask for agile coaching help. I think it’s a general phenomenon in agile (and non-Agile) teams and organizations, but for the purposes of this article, I want to focus upward—on “them”.
I was at a conference not that long ago speaking and sharing on various agile topics. As often happens, a young man stopped me to ask a few questions after one of my presentations. We struck up a nice conversation that eventually slipped out into the hotel corridors.
We started talking about sprint dynamics within Scrum teams and I happened to mention that I usually coach teams towards declaring their sprints a success…or (pause for meaningful effect) …a failure. That we do this as part of the teams’ Sprint Review, with the Product Owner being the final determinant based on whether the team achieved their Sprint Goal(s).
As I learn and grow my agile experience, I continue to find value and power in the notion of transparency. It’s one of the softer of the agile tenets and one that gets mentioned often, but rarely emphasized as a critical success factor.
So what is transparency? Let me give you an example. In many agile instances teams and structure don’t simply come into being. Usually functional managers or other leaders put some serious thought into the composition of their initial agile teams:
I’d like to begin this post by trying to describe some of the anti-patterns or characteristics of non-transparent work behaviors. This list will probably not be complete, but it should give you a sense of the other side of the transparency fence—obfuscation.
There are several show-stopping defects in your current code base and you are either not tackling them with your best people or hoping their intermittent nature won’t surface inopportunely before general release. So essentially you are throwing a few bodies at the problem and hoping nobody truly notices.
...If you’re transparent, you must acknowledge and manage quality—being willing to “stop the line” if things aren’t’ right and fix them. This takes courage and commitment.
