Viewing entries in
Short Takes

Distributed Agile Teams

Comment

Distributed Agile Teams

There are literally three things that come up in any of my training adventures—

  1. How to handle estimates and forecasting with fixed-date projects?

  2. What are “Good” agile metrics?

  3. How to be “Agile” with distributed teams?

I thought I’d explore the last question on distributed teams in this post by listing some references that you might find helpful.

First, I think the Jutta Eckstein was the first author in this space. She wrote—Agile Software Development with Distributed Teams: Staying Agile in a Global World in 2010 and updated it in 2018. She was probably one of the first folks who started sharing her experiences in distributed agile and her work has stood the test of time.

Next, Johanna Rothman and Mark Kilby have written perhaps the most complete work on the topic in agile contexts. From Chaos to Successful Distributed Teams: Collaborate to Deliver is an incredibly useful look at how to make distributed teams work in agile contexts. Written by two seasoned coaches from their work in the real world. And here’s an Agile Alliance article they wrote about collaborating on the book.

And here’s Johanna and Mark’s contribution to Comparative Agility’s assessment tool.

Comment

The POWER of “Going Agile”

Comment

The POWER of “Going Agile”

I interact with team members all of the time. They speak in terms of: 

  • Their leaders have made them “go agile”;

  • That it’s not going the way they want it to be;

  • That things are worse than before;

  • Or that nothing has changed, they’re still underappreciated, overworked and stressed out.

You get the picture.

Comment

Short take on FLOW Metrics

2 Comments

Short take on FLOW Metrics

This is a true short-take on flow metrics. I want it to be a reference piece for other works… 

I attended a Professional Agile Leadership class with Ryan Ripley not that long ago. Ryan is a colleague and friend of mine and I always appreciate (and learn new stuff) when we get together. If you ever get the chance to attend a Ryan Ripley class, take it!!!

But I digress.

Ryan was VERY enthusiastic about flow metrics in the class. He has moved on from a velocity position and then from a #noestimates position, and now believes that flow metrics that the most relevancy and value in agile contexts.

2 Comments

Them & Us in Failure

Comment

Them & Us in Failure

This is inspired by a conversation I had at our Vaco Agile coach’s guild.  

We had a discussion around it being ok to fail is NOT simply leaders giving us space/safety to fail. It’s also about our internal willingness to fail.

For example, as I’m a strong and driven Type A, my personality isn’t that comfortable with failure. So, even if the ecosystem is “failure friendly” or encouraging…

  • Am I? and if not, why not?

  • Are other members of my team? And if not, why not?

  • Are members of my group or tribe? And if not, why not?

And if we’re not internally failure friendly, how do we get there? How do I/we move the needle?

Wrapping Up

This was a real short take post, but I hope it starts you thinking about your safety and failure friendly ecosystem.

While, yes, your leaders play a really SIGNIFICANT role in it. It’s not solely about them. It’s also about US and our WE walking our own talk?

How might we test it? Perhaps checking for –

  • When was the last time someone on your team failed…and shared it?

  • And, when was the last time you failed…and shared it?

Anyway, food for thought. Stay agile my friends,

Bob.

Comment

Do you need an Army of Agile Coaches?

Comment

Do you need an Army of Agile Coaches?

Let me start by saying that all organizations aspiring to be agile need an agile coaching presence. But the question is how many, for how long, and how much?  

I’ve seen many organizations that invest too heavily in coaching and keep the coaches around for far too long. This often creates a dependency on the coaches and really doesn’t help the organization’s growth.

I came upon this article around 2016 that explained how one group at Walmart approached creating an internal agile coaching capacity. What strikes me about it is how lean it is. And how it leverages the entire organization for what is essentially self-coaching.

Anyway, I thought I’d share it. I don’t think many are aware of this approach and it’s a thought-provoking alternative to many of today’s strategies.

Wrapping Up

One of the things I appreciate about this article is the author’s willingness to share—what works for them. It may not work for every organization, but it’s a real-world approach that produced results.

And on a personal note, is that this strategy aligns with my own. Instead of embedding oodles of coaches for long periods of time, it confirms that you can make great progress with a more situational approach. Not only that, the results may be even greater than applying an entire army of coaches to the effort.

Stay agile my friends,

Bob.

Comment

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

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

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