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.
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…
Estimate Newbie
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.
Sometimes my clients ask me which are the best organization structures that support a move to agile approaches. There are many ways to characterize their organizational structure and focus, but a common view I use is this:
Are they aligned as a Project-based organization or a Product-based one?
You can move to agile methods with either focus, but I think a Product-based focus makes it much easier. Let’s explore the dynamics of each. This will help you determine where your organization currently resides AND how you might want to shift your focus if you’re thinking about agility.
I spent over 10 years working at a company in Connecticut called Micrognosis. I wrote about an aspect of my experience there in this post.
During my tenure at Micrognosis we delivered many, many products and projects. We made millions of dollars on our technologies and our customers were fairly happy with our efforts. All of this happened in the span from 1986 – 1996. If you asked me today whether anyone, and I mean anyone, really cares about the efforts we made (products, effort, blood-sweat-tears, etc.), I’d say no.
One of the hidden factors in all of our legacies, and I know technologists don’t want to hear this, is that what we’re working on really doesn’t matter in the long term. No matter what you’re working on!
For example, Netflix or Google or Spotify of today really won’t matter (technically) 20 years from now. Sure, they’ll be historical notes about them on Wikipedia, but the products themselves won’t matter.
So, what does matter?
