Retrospective Redux

Comment

Retrospective Redux

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…

Comment

Building an Agile Coaching Team (redux)

Comment

Building an Agile Coaching Team (redux)

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?

Comment

Sprint Planning – Simple, and yet…

Comment

Sprint Planning – Simple, and yet…

It’s really quite funny. I’ve been coaching and teaching Scrum for nearly 20 years. But sometimes, my knowledge and experience sometimes gets in the way, in that I sometimes forget that the simplest of the ceremonies can often be hard to get…”right”.

One of those is sprint planning.  

I recently stumbled across two references that I think are very helpful in executing this simple and important, yet sometimes hard to get right ceremony.

The graphic is from Joshua’s article. I really like it!

I’ve also written a quick helper guide around how I’ve found it best to get started in sprint planning. Mostly with new teams. It’s a recipe I’ve successfully been using for well over 10 years and I hope you find some useful hints within.

Here’s the link: https://robert-galen.squarespace.com/s/Scrum-Sprint-Planning-Overview.pdf

Wrapping Up

Sprint planning is one of those ceremonies that embodies quite a lot of agile skills:

  • Backlog refinement

  • Estimation (at a story and task level)

  • Effective story writing

  • Collaborative workflow

  • Done and delivery

Getting it “right” can help you and your teams accelerate towards delivering on the promises of Scrum.

Stay agile my friends,

Bob.

Comment

Situational Coaching – Models

3 Comments

Situational Coaching – Models

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.

3 Comments

Checking for Safety

Comment

Checking for Safety

Safety is a hot topic in agile contexts today. Continuously begging the question – 

Is it safe?

With a nod to the film Marathon Man. Safety is incredibly relevant to the level of true agile performance at a team level.

In the following post, Joshua Kerievsky mentioned a technique originated by Norm Kerth that explores ways to “check for” safety.

https://medium.com/@JoshuaKerievsky/norm-kerths-safety-poll-bcccd5be6e44

While this may be a relatively short post, it’s an important one. And this is NOT simply focused on safety at a team level. It’s also applicable for all levels of the organization.

I also really like that Josh gives a nod to Norm. A true pioneer in this space!

Norm wrote the book Project Retrospectives, which is a foundation for nearly all of the agile retrospective advice (books, articles, etc.) that followed it. I don’t think he gets enough credit for this important work.

Anyway, please read the post and renew your focus on safety awareness within your teams.

Stay agile my friends,

Bob.

Comment

Arie on Organizational Change

Comment

Arie on Organizational Change

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.

Comment

Revisiting Agile Teams

Comment

Revisiting Agile Teams

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:

  1. Teams that stay together are more productive.             (more stories)

  2. Teams that stay together are more predictable.             (higher throughput)

  3. 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.

Comment

My Journey in Software Estimation - What a long strange trip...

Comment

My Journey in Software Estimation - What a long strange trip...

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.

Comment

Project vs. Product – Organizational Focus

1 Comment

Project vs. Product – Organizational Focus

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.

1 Comment

What IS your Legacy?

Comment

What IS your Legacy?

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?

Comment