Visible & Invisible Impediments

Comment

Visible & Invisible Impediments

I was in one of our Moose Herd sessions the other day and one of the Moose (or is it Meese) brought up a scenario around impediments. The topic was—how to encourage (inspire, make) the team take ownership of resolving their impediments.

The question elicited a wonderful Herd discussion that felt like it helped the questioner. But as it went on, I began to remember that I’d historically formed a view of 4-Types of Impediments that I hadn’t thought about in a long time or articulated. Thus, this post.

4-Types of Agile Impediments

The first thing is that there might be more than four that some of you can come up with. These are just some that have helped me decide how to describe and act on them uniquely. I like drilling down into different types because it adds contextual flavor to handling the wide variety of challenges we aggregate into the word impediment.

1 - Team Impediments

I think the Scrum Guide refers to these as impediments the Scrum Master should be helping their teams resolve. They are within the span of control of the team and can usually be “struck down” quickly and easily. Or relatively easily.

Comment

Descaling Manifesto

1 Comment

Descaling Manifesto

To be honest, I’ve been aware of and admiring Peter Merel and his work for quite some time—perhaps more than 10 years. That said, I haven’t been a consistent follower, and as I re-reviewed the Descaling Manifesto, he proposes within the XSCALE Alliance, I realized the great work he’s been doing in the agile community. Purposeful and vital work that strikes at the heart of a truly agile mindset and better ways of leading, organizing, and working.

My purpose in writing this post is to acquaint you with Peter, the alliance, and the manifesto. It also encourages you to do a deep dive into everything on the Alliance site looking for new ideas, tactics, and approaches to your scaling challenges. Perhaps in a word, leaning into descaling.

I plan on doing that myself, so look for a more detailed future update sharing my thoughts.

And a Conference!

Finally, I was excited to see Peter planning a virtual conference from October 25th – 27th. I plan on attending to reinvigorate myself, and I hope to see you there too. You can find more info here –

https://www.linkedin.com/posts/petermerel_home-activity-7095253127490121729-Z9Tc

Here’s to descaling. Stay agile, my friends,

Bob.

Oh, and by the way, I just signed the Manifesto. Better late than never I always say…

1 Comment

Respect!

Comment

Respect!

I saw this post on LinkedIn the other day from Brian Orlando. I read it and a few comments, which motivated me to write this post. 

Here’s Brian’s initial post—

I've been thinking...

In the latest Arguing Agile Podcast podcast where Hemant (Om) Patel and I discuss Peter Drucker's three different types of teams, right near the end we started to talk about aligning #management with/to the appropriate team model.

Anyone who has been involved in an #agile transformation knows organizational design changes are likely required for success (in response to product challenges, changing markets, etc).

I'm wondering why the obstinate resistance to responsive #organizationaldesign and #organizationaldevelopment?

Comment

Staying in Your Lane

Comment

Staying in Your Lane

I was coaching someone new the other day. I knew they had a broad and deep non-software background and were pivoting into a Scrum Master role. It was their first job as a Scrum Master, and the hiring company was taking a leap of faith in hiring them. But I knew they had deep skills that would translate into the Scrum Master role and that they would do well. 

That is…if…they would stay in their lane.

They had ~20 years of experience and had held organizational leadership roles in their previous companies. Given that, I knew it would be a challenge for them to, how to say it, be a Scrum Master. Especially when they encountered organizational, leadership, and broadly impacting impediments.

They also seemed to have a very proactive, fix-it mindset. I thought this would be hard to throttle in the context of Scrum Mastery in an early-stage and chaotic agile transformation, mainly if they were focused on doing things “right.”

Comment

Where has all the innovation gone?

1 Comment

Where has all the innovation gone?

The title is an homage to Pete Seegers – Where have all the flowers gone?

The other day, I was in a Moose Herd chat (mid-June 2023), and the conversation revolved around innovation. And it dawned on me that I haven’t been hearing innovation stuff as much as I used to.

For example, I’d say from ~2008 – 2015; there was lots and lots of discussion coming out of the agile community around things like –

  • Google 20% time

  • Refactoring

  • Innovation days

  • Innovation sprints

  • Active refactoring

  • Pair programming, general pairing

  • Mob programming; general mobbing

  • Hackathons

  • Design sprints

  • Paper prototyping

  • Storyboarding

Just to name a few practices around team-based innovation. But to be honest, I’m hearing less and less of this now, both from the organizations/teams I’m coaching or interacting with and from community thought leaders.

So, my question is—

Have these activities and practices slipped away and been forgotten?

Or

Are they such common practices that, nobody talks about them anymore, they just are?

To that end, my colleague and friend Leon Sabarsky and I have created a short survey to collect information about the State of Innovation in Agile Ways of Working.

We’d very much appreciate hearing about your experiences.

Stay agile my friends,

Bob.

On a related note, I wrote this in 2013…

https://rgalen.com/agile-training-news/2013/10/1/google-20-timesadly-its-gone

Something else…

https://rgalen.com/agile-training-news/2016/11/10/innovation-management-vs-team-responsibility

1 Comment

Why so much resistance to guardrails?

1 Comment

Why so much resistance to guardrails?

I saw this post on LinkedIn the other day from Damon Poole where he was responding to a question about daily standup. And it made me think of all the debates I see today around folks in the agile community, how do I say it, following the “rules” of the various frameworks, methods, and tactics. 

Now I get it. We’re agile, right? So, we should be inspecting, adapting, experimenting, not becoming dogmatic, etc.

But at the same time, I don’t get the point about all rules being bad. Especially when you’re just beginning (Shu for those familiar with that metaphor) or new to agile ways of working.

Learning to drive

For example, if you’re learning to drive, there are typically rules for learning to and maturing your driving, then the following is a fairly sensible path—

1 Comment

Clean Agile Language

Comment

Clean Agile Language

With an homage to clean language, I was inspired in a Moose Herd session the other day as we explored the damage that agile terminology can do when we’re coaching.

So, the thought that jumped in my mind was the notion of an Agile Coach coaching using Clean Agile Language.

I know what you’re thinking…what is that?

Well, we coach without using any agile terminology. Zero, zilch, nada, none! Inclusive of—

No Scrum terminology

For example—no talk of roles/accountabilities, no events, or sprints.

No XP terminology

For example, no talk about user stories, acceptance criteria, or CI/CD.

No Kanban terminology

For example—no talk of WIP, flow, or SLA’s.

No SAFe terminology

For example—no talk of value streams or trains, SAFe Scrum Masters or other roles, and no talk LACE.

No Agile book or guidance references

For example, stop referencing Agile 2, LeSS, Scrum Guide, Agile Manifesto, or Scrum: The Art of Doing Twice the Work in Half the Time.

You can’t say anything with “agile” or “Agile” in it. And don’t get me started about Agile Coaching terminology—powerful questions, reveal the system, stances, competencies, and wheels, oh my!

Bob, are there any exceptions?

I think I might make an exception for lean language or business agility language, but be super careful with it. And begrudgingly, I must allow an exception for any trainer teaching one of the above methods, frameworks, or approaches.

My Challenge to Myself and other Agile Coaches

First, let me acknowledge that I’m not good at this now. If judged harshly, one might say I suck at it. Given that, I understand how challenging making this shift might be, so I’m going to start with some small experiments—

  1. Can I go for a day of interactions applying clean agile language?

  2. Can I deliver one of my existing presentations applying clean agile language?

  3. Can I have a coaching client conversation, just one, by applying clean agile language?

Then reflect on how that felt for me and its impact on whoever I was talking to.

Wish me luck, everyone. I think I’m in for a bumpy ride…

Stay agile my friends,

Bob.

Comment

Do you need an Agile Coaching Playbook?

Comment

Do you need an Agile Coaching Playbook?

I happened upon the Boston Consulting Group paper entitled Why Your Agile Coaching Isn’t Working—And How to Fix It. 

Here’s a short snippet from the article that I want to use as a backdrop for several points—

The coaching playbook is especially useful when coaches run two-week “sprint” interventions with teams that need to improve a specific capability or to address performance gaps. The coach then chooses from hundreds of “battle-tested” interventions in the playbook that target that capability or performance gap, and designs a sprint plan based on it. At the end of the sprint, the coach and team evaluate the impact of the intervention. Reflecting on the effectiveness of the intervention and creating new ones also helps propagate and improve the catalog of interventions.

Comment

Value Stream or Organizational Structure?

Comment

Value Stream or Organizational Structure?

The chicken or the egg

It’s a bit of a chicken and egg problem. Which comes first when transitioning to agile ways of working? Do you re-organize or restructure your organization first – setting teams and roles up for more agile execution? Or do you align your product, application, and workflows into value streams to feed to your teams? What a conundrum.

Ten years ago, I saw most organizations leaning into organizational changes and not putting much thought into the value streams their teams would be working on.

Now it’s flipped a bit, and there’s a strong focus on value streams, probably influenced by SAFe, amongst many factors. And then, the executing organization is composed as an afterthought.

Comment

Valued People Create Value

Comment

Valued People Create Value

I saw this exchange on LinkedIn between David Pereira and Michael Küsters.  

Here’s a snippet of what David said—

❌ Customers don’t care which agile framework you use
❌ Customers don’t mind how you work
❌ Customers couldn’t care less about your state of the art product delivery

✅ Customers only care about how you make their lives better—no more, no less

Are we sometimes or maybe too often missing the mark?

And Michael commented—

❌ Customers don’t care if you burn out your employees
❌ Customers don’t care if you don't listen to your employees
❌ Customers don’t care if you underpay your employees
❌ Customers don’t care if you fire your employees to keep more profit for yourself

The customer isn't everything. That's a dysfunction already.

✅ Customers will care if you treat people like people, with dignity and respect - because the service they'll get from such people is going to be different than the service provided by drones.

Later on in the comment trail, someone mentioned that you can do both—

Care about value creation and how you treat your people.

And I agree. But that statement puts the two on equal footing. However, that part I disagree with and want to prioritize one over the other.

I believe people should come first and how you treat your people drives the value that you create for your customers.

I realized that’s not what David was saying. But I wanted to lean into Michael’s perspective and amplify it a wee bit more.

Stay agile my friends,

Bob.

BTW: it’s worthwhile to read David’s entire post AND all of the comments.

 

Comment