Since agile methods have become a mainstream approach to software development, the coaching of agile teams is a HOT topic and role.
It seems as if EVERYONE is an agile coach nowadays. And I literally mean, everyone! I see people leaving a 2-day ScrumMaster certification class and then hanging out a shingle as a coach.
Or someone with 1-2 years of experience. But I digress.
I’ve already recommended Lyssa Adkins book in the ScrumMaster book list. But it certainly applies here as well. I’m just not going to count it against my quota ;-)
First of all, it’s been far too long for me writing something about metrics. It’s one of those topics in the agile community that keeps on giving ;-)
But I’ve been inspired (yet again) by an article that Anthony Crain wrote a while back on the topic. He introduced it as his QPPE Metrics Model, where:
Q – represents Quality,
P – represents Predictability,
P – represents Productivity, and
E – represents Engagement.
You can find the article here –
I shared this article with my friend and colleague, Shaun Bradshaw. I’ve known Shaun for the better part of two decades and he’s my go-to guy when it comes to all thing’s metrics related. Here’s his initial reaction to the QPPE post:
It seems like retrospectives are still one of the more challenges agile activities/ceremonies to execute and get right. Which is somewhat surprising to me in that it’s a fairly simple activity. For example –
A team sits down periodically to look in the mirror and brainstorm way(s) to improve themselves.
How hard can that be?
We could also apply the word kaizen or kaizen event to it. Here’s a snippet as to what Wikipedia has to say about its meaning –
The Japanese word kaizen means "change for better", with inherent meaning of either "continuous" or "philosophy" in Japanese dictionaries and in everyday use. The word refers to any improvement, one-time or continuous, large or small, in the same sense as the English word "improvement".
Again, it’s a simple, yet core element of your agile culture and I don’t necessarily understand why it’s so challenging. But let me share a few stories to illustrate the point that it IS challenging. At least to do it well…
Awhile ago, I’d written a blog post about the lack of an agile engagement having a cohesive coaching team. But later it dawned on me that I’ve never shared what an agile coaching team might look like.
Given that inspiration, I spent some time developing the first version of this post in which I discussed aspects of creating (finding, forming, and building) a great team of coaches for a larger-scale, agile transformation initiative.
Since then, I’ve updated my experience and renewed my focus on this important topic. I’ve also developed some additional posts that support the ideas. So, I thought I’d share an update with everyone.
Here’s a link to the original post. And let’s explore it again, below:
Are they followers?
I was running one of my coaching circles the other day and someone brought up the X-wing Coaching Model. To be honest, I had to admit that I didn’t know what that was.
Then they sent me a link, http://agilecoachinginstitute.com/agile-coaching-resources/
and I realized it was the Agile Coaching Competency framework put forth by the Agile Coaching Institute. It’s a model (picture) that speaks to the various capabilities that one should have when approaching agile coaching.
I wanted to share a couple of reactions to the model.
First, Can I Really DO It All?
One of the problems I have with the model, and it’s one of the few, is the implication that a coach needs to have competency/skill in all of the areas. Or to be growing their skills broadly across all of them. And my issue is, I don’t think that’s possible.
Arie Van Bennekum is one of the original signatories of the Agile Manifesto. So, he’s got significant experience and credibility in the agile space. He’s also the founder of a company called Wemanity, based primarily in the Netherlands, but spread across several European countries.
Arie recent shared on InfoQ about two models or approaches that’s he has invented and used in Wemanity’s journey that I thought might be interesting to share.
The Integrated AgileTM Transformational Model
Arie and his Wemanity team have created the following 6–step approach to introducing agile approaches and changing organizational culture. It’s intended to be a round-trip, iterative approach to incremental organizational and cultural change.
Revisiting Agile TeamsThis post is inspired by this article by Derek Huether - https://medium.com/@derekhuether/stable-teams-should-be-non-negotiable-59af0972f77
His is the sort of the position I used to have. However, I’ve been rethinking my position over the last few years. Not that I’m moving away from honoring the team. I’ll always do that.
But I’ve started to think that a little adversity isn’t necessarily bad for a team.
I want to use this post as an update to my writings about agile teams. The following post best captures my thoughts – http://rgalen.com/agile-training-news/2018/3/5/stop-norming-performing
Back to Derek’s point
Derek makes 3 key points in the article:
Teams that stay together are more productive. (more stories)
Teams that stay together are more predictable. (higher throughput)
Teams that say together are more responsive. (less time in process)
And he supports those conclusions with data from Larry Maccherone while he was with Rally/CA and reviewing data collected through their tooling. Another key point Derek makes is against the frequent reorganizations that run rampant in many companies. That they undermine all three aspects.
I’m not going to challenge the data or Derek’s key point. Let’s assume that everything is right. That we want to focus on team productivity. However, I think there are things to consider equally (and perhaps even more importantly) than productivity.
I’ve had a long career with estimates in software projects. While it’s been a rocky journey, I now feel that I’ve gotten to the point where I truly understand how to and the value of estimation.
But before I give you the great reveal, let me share some of my history…
I first began my career as a newbie in estimation. I fell into the trap of being as honest as a could be and I found that my estimates were often used against me. For example:
My bosses would often forget the “fine print” around the estimates. Words like – “this is only a guess until I get more formal requirements. Or, I’ve never done this before, so I really don’t know how long it will take” were never remembered. Imagine that?
People who had not a clue would weigh in on my estimates. Bosses, who were under pressure to release quickly, would cut them. And project managers, who were trying to “defend” the project, would pad them. And my developer colleagues, who always had an optimistic spin on things, their estimates would always be lower than my own. Imagine that?
And I always felt that nobody wanted the “truth” in estimates. That they couldn’t handle it. So, it negatively influenced me to pad/cut depending on the situation. But the key point is the inherent dishonesty I felt around all estimate discussions. Early on, it felt like a game of sorts. Where the last one that weighed in on a number…won. And the development team…generally lost. Imagine that?
But as in all things, I grew in my experience and in my career. Soon, around the late 1980’s, I became a “manager”. Which meant that I not only had to estimate for myself but for my group(s) as well. This showed me both sides of the estimation continuum and frankly, I didn’t like it much.