We’ve tried that before…

1 Comment

We’ve tried that before…

Many years ago, I volunteered to help a local conference team reenergize their conference program. They had been putting on the conference for a number of years and were looking for some new, fresh, and outside opinions on how to change the format and reenergize it. 

You see attendance was declining, not too much, but a troubling trend. And attendee feedback, while positive, pointed to getting a bit bored with the current repeating recipe.

We went out to dinner to brainstorm. It was attended by the long-time program chair and an invited set of 4-5 outsiders who were asked for their ideas.

We’ve tried that before…

As the dinner commenced, the introductory conversations turned into a brainstorming session All seemed to be going swimmingly and I was excited about the possibilities.

1 Comment

Opportunities in an Iteration or Sprint, Review and/or Demo

1 Comment

Opportunities in an Iteration or Sprint, Review and/or Demo

I was reading a blog post from a coach who was working with a continuous deployment team. In essence, every story (work item, PBI, etc.) from their sprint made it into the customers hands immediately. They received feedback on each in real-time and took follow-up actions as appropriate.

Since they were using Scrum, they were still conducting a Sprint Review every few weeks. The coaches question related to the value of the review. As it seemed that everyone was questioning it in this particular context. That is, since they saw (and accepted) things in real-time, what was the need to see them again in a review? Or were they just doing it because the Scrum Guide said to do it?

And the backstory was that the coach was struggling with dogmatic Scrum in the organization. I.e., doing things just because the book said to do them, rather than thinking and adapting.

This question made me think a bit about Sprint Reviews. And it led to the following online response to that coach –

My reply

1 Comment

Listen to ME!

Comment

Listen to ME!

We were sharing stories in a recent CAL class. One of the students talked about the dynamics of release engineering related to gaining customer feedback. I shared a recent post from Jason Fried where he mentioned the importance of releasing a product to get feedback. Making the point that customers are the only arbiter whether you were on track or not in your MVP development path.

Here’s the link -

https://uxplanet.org/10-things-i-learned-from-jason-fried-about-building-products-5b6694ff02aa

The young man brought up his frustration with the phenomenon of organizations often listening more to outsiders rather then listening to their own teams or internal experts. Either in person or as names being dropped in conversation.

I sometimes liken this to bandwagon syndrome and I shared on that here –

http://rgalen.com/agile-training-news/2014/4/13/bandwagons-the-good-and-the-bad

I fully resonated with his comment. Being an outside consultant, I often hear “insiders” say something like:

I’ve been giving my leadership team that feedback for several (days, months, even years) and they’ve never really listened to me. You (consultant Bob) come in and say it once and suddenly everyone takes it seriously. 

Do you know how frustrating that is?

Actually, I do. And I’m incredibly empathetic to the point.

I remember when I was at iContact as their agile transformation coach, I had everyone’s ear for the first year or so. And my recommendations were easier to make and have them stick. But as time passed and everyone got used to my voice, stories, and style, they started to tune me out a bit.

So, this phenomenon happens to us all.

I started to bring in other thought leaders, either hired or invited, to mix the ideas (and voices) up a bit. And this seemed to work beautifully to break through the ice and renew some of my influence.

Wrapping up

While this can be a bit frustrating to folks on the inside, I think this is a natural occurrence in all organizations. Folks get accustomed to our voices and we need to augment them with book / article references, outside perspectives, and other ideas.

I think it’s simply the way it is. And you know…

It doesn’t matter where or who the idea comes from as long as the organization gains a flow of ideas, tries and experiments with new things, and continues to learn & evolve.

It’s all good.

Stay agile my friends,

Bob.

Comment

The Agile Coaching Dilemma

1 Comment

The Agile Coaching Dilemma

Renee Troughton is someone that I don’t follow nearly enough. But when one of her articles crosses my path, it nearly always resonates nicely with my own experience or helps define a concept or notion that I’ve been struggling with.

Renee published - What do people want agile coaches to do? on May 7th.  

I’ve found that striking the right balance (or stance) in my own agile coaching journey is a constant exercise of self-awareness, situational-awareness, and leveraging all my years of experience. It’s really, really hard.

Here’s a snippet from Renee’s article that explains the dilemma from her perspective –

I have had a lot of feedback in the past that I tend to be different from other coaches. I’ve even seen people refer to coaches as two different types, often not in good terms. One commentator referred to the schism as “fluffy agile sprinkles coaches” who are all oriented around mindset and “delivery coaches” who are all oriented around practices and techniques. To this commentator, the middle ground of coaches who are both and have the expertise to know when to use one approach over the other is a dark art that few know well.

1 Comment

Back to Basics…Part Deux

Comment

Back to Basics…Part Deux

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

Comment

Book & Video Recommendations – Agile Coaching

Comment

Book & Video Recommendations – Agile Coaching

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 ;-)

Comment

QPPE Metrics Model – A Measured Reaction

2 Comments

QPPE Metrics Model – A Measured Reaction

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:

2 Comments

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