In May of 2018, I published this Back to Basics post -
http://rgalen.com/agile-training-news/2018/3/5/back-to-agile-basics
The intent was to refocus attention back to some of the original thinking and mindset of the early days of agile. Not to sound too nostalgic, but life was much simpler then.
I want to add to the list I shared then:
If you want to get back to the roots of agility I encourage you to research the following…
And you might want to investigate how Spotify is implementing agile practices. Not putting them up on a pedestal but considering them a role model for learning the basics of agility in practice. https://www.infoq.com/news/2016/10/no-spotify-model
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 –
https://techbeacon.com/how-software-teams-can-measure-anything-qppe-metrics-model
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".[5]
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.
https://www.infoq.com/articles/future-ready-organization
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.
