Gimme Back My Bullets

Gimme Back My Bullets

There’s a song by Lynyrd Skynrd entitled Gimme Back my Bullets. It came to mind when I was thinking about this post and I thought I’d share that backstory with you. 

This is a follow-up to a blog reaction I had to a post from Dan Mezick.

Bullet Metaphor

I’ve been using this metaphor for the past 20 years of my agile coaching. It helps me to focus on what engagement opportunities I want to pursue. These would be both as internal and external coaches.

The metaphor has strengthened as I’ve gotten older. And right now, it very clearly guides every discussion I have around helping others with their agile journeys.

It involves an old west gun holster with bullets around the belt. Many years ago, I started out with a full belt when I began consulting. And over the years, I’ve used my bullets at a wide variety of organizations. Some of them hit the mark and the organizations had great successes. Not because of me. But because of themselves and their level of commitment to an agile mindset and agile principles.

An Agile Decade: Past, Present, and Future

An Agile Decade: Past, Present, and Future

There have been some troubling trends I’ve seen in the last 10 years of my agile journey. I’d like to share some of them in order to bring them into the light of day.

To be fully transparent, this post was inspired by one that Melissa Perri made here. While the format isn’t the same, it inspired me to look backward in order to look forward.

The lists are in no particular order. That being said, if something made it on the list, I think it’s important!

A (Painful) Look Backward at the Past

Traits of an Agile Nation

If you know me at all, you know that I’m rarely caught without words. Well, I have no words to add to this. I’m simply pointing out an article and a TED talk that is all inspiring to me.  

I’m incredibly moved by Rashina Hoda and her words and I felt compelled to share it with you.

The Traits of an Agile Nation

https://www.infoq.com/news/2019/10/traits-agile-nation/

Stay agile my friends,

Bob.

BizProdUXDevQASecSTOPOps

I’m getting a little tired with all of the ***Ops crap.  

I was triggered by a keynote presentation at the recent StarWest conference. It was entitled: QADevSecOps – Leading a Quality-Driven DevOps Transformation by Stacy Kirk.

The keynote was great. And Stacy did a wonderful job of telling her story. That’s not my issue with it.

It’s the title that ticked me over the edge. 

Product Ops

The other kicker for me was seeing something around Product Ops published by Pendo. Now it seems as if another “ops” has popped up.

WTF?

News Flash

I don’t need some fancy-schmancy list of letters to establish the pattern of people working together for the greater good of producing great products or applications for the clients/customers.

That should be common sense, empowered, and just happening naturally. Period!

And if you’re in an agile environment, then it should be happening even more…like every day.

Why can’t we just all get along and work together? Without having to apply a series of letters in front of OPS?

Stay agile my friends,

Bob.

BTW: Here’s a great explanation of DevSecOps by RedHat - https://www.redhat.com/en/topics/devops/what-is-devsecops

that I thought I’d share. And here a post I’ve written previously about DevOps.

What do I Do as an Agile Coach?

What do I Do as an Agile Coach?

Dave Rooney is a Canadian Agile Coach who recently wrote a nice article about what he focuses on in his agile coaching. I thought I’d share it and play off of Dave’s ideas a bit.

In the article, he mentions 6 important activities:

  1. First Do No Harm!

  2. Listen

  3. Ask boatloads of questions

  4. Challenge assumptions

  5. Teach/Coach Agile practices

  6. Work myself out of a job

My reaction to Dave’s list…

No Assholes Allowed!

No Assholes Allowed!

I have a confession to make.  

I’ve led software development organizations for several decades. The bad news is that early on, I made some critical mistakes. The good news is that I quickly learned from those mistakes. But one of the things about mistakes that involve people is that it’s always hard to recover from them. The better strategy is to be really crisp in your people decision-making.

One of the mistakes I made early on was hiring “Brilliant Jerks” or people who had exceptional technical skills but lacked skills in other areas. Another way to put it is they were, how shall I say it, assholes. But I tolerated their asshole-ness because of how smart, how productive, and how loud they were.

Nobody wants to work with them and they brought the entire team/organization down. But at the same time, I tolerated them because they had incredible value in certain areas.

Big mistake!

Has Scrum’s time come & gone?

Has Scrum’s time come & gone?

I think the answer is a resounding…

YES! 

But let me explain a bit…

First, what do I mean by Scrum?

Let me share a multi-faceted definition of Scrum to focus on what I’m railing against. 

Scrum has been “around” since the mid to late 1990’s. So, for ~25 years. That’s an incredibly long time for a methodology (or framework) for software development (and other things) to exist.

Second, when I say, Scrum, it’s the Scrum that was created by Schwaber and Sutherland. The Scrum that’s defined in the Scrum Guide. That has been periodically updated by those two esteemed gentlemen.

Third, when I say Scrum, it’s the Scrum that has created/inspired a certification frenzy across:

  • Scrum Alliance

  • Scrum.org

  • Scaled Agile

  • PMI

  • SCRUMstudy

  • Scrum Institute 

  • Scrum Inc.

That has inspired literally hundreds of people to jump on the certification trainer bandwagon and doll out as many (typically 2-day class) certifications as possible. Why? Mostly because it’s such a lucrative way to make a living.

Can There be Too Much of a Good Thing?

Can There be Too Much of a Good Thing?

I have a good friend, Ryan Ripley, who is an excellent Scrum trainer with Scrum.org (PST). I just attended a workshop with him and it contained lots of Liberating Structures or LS. 

And when I say lots, I mean LOTS!

And he was clearly excited about them and about stringing structures together. In our debriefs, it was almost as if LS was a pattern language for teaching. In other words, how to teach specific, complex topics and how to communicate to a diverse group of students.

Now I’m not an expert on LS, but it seemed as if Liberating Structures was his new favorite technique when it came to teaching.

But was that good?

Thoughtful

Tobias Mayer is one of the voices in the agile community that often makes me feel uncomfortable.  

Rarely does he mince words. Or, as I’m inclined to do, use too many words. He’s mastered the art of short, thoughtful, and thought-provoking prose.

And you can tell he’s not being controversial for its own sake. A strong sense of genuineness comes out in his writing. It’s simply him…sharing…his personal discovery and thoughts.

He recently (May 2019) published an article on LinkedIn entitled Small Things. In it, he spoke about getting back to a place where learning, in this case in the agile space, as being a small, person-to-person experience.

It made me reconsider how I engage in “teaching & sharing” my agile experience in the world. Yes, I’ll still do workshops. But I might try to make them smaller, more intimate experiences. Not focusing so much (gulp) on registration numbers.

And instead of my talking so much, I’ll try to create more space for conversations and for story-telling. And this leads into considering the space itself. Space matters. Do I schedule a class in a sterile hotel OR do I look for a much more interesting space where we’re close to nature and have room to lounge, spread out, or even be alone for reflection?

And instead of forcing things like TFTBOTR, Lego games, Liberating Structures, Speed Boat, and a myriad of other facilitative techniques on my attendees, I might just try to create a space for dialogue. Where each person can find their voice, share their stories, and we can all grow and learn.

Wrapping Up

As I thought about Tobias’ article, it came to me that we both might have the same intent in our writing. Or at least I do.

I want folks not to read my words as fixed or prescriptive or declarative or judgmental.

Instead, all I ever try to do is create a space of thoughtfulness.

I’m hoping that I inspire each and every reader to simply consider my stories and my words. Looking for any helpful truth in them. And then decide, for themselves, if there is anything worth acting on? Is there anything useful?

That’s it. I’m not trying to make a global point or posture as some agile expert. I’m simply trying to touch one person at a time.

Stay agile my friends,

Bob.

Does anybody remember laughter?

I’m wondering if the #1 metric for agile teams (individuals, groups, organizations) is joy? Or to quote Robert Plant – Does anybody remember laughter? 

https://www.youtube.com/watch?v=EZB4hPyPR2M

I’ve often reminisced in my classes that I started developing software for the sheer joy of it. I had fun doing it. It was creative. It was something I could do alone and within teams. It was something that created something useful for a customer/requester and I could deliver it to them and see how it delivered value. It brought me joy.

Then somewhere along my journey, the bean counters took over. As did the project managers. The folks who micromanaged me, putting more stock in estimates than the work itself. Folks who, in many cases, didn’t have a clue as to what I was doing. They started pushing me for artificial dates and telling me the wrong thing to build. They didn’t listen to me or treat me like I was a partner. I became a software developing cog in their machine.

Then, I lost my joy.

Developing software became a job, a chore, and joyless. I lost the excitement and fun.

Then in the mid-1990’s, I discovered agile. The manifesto, Extreme Programming, the agile mindset, and a new, more inclusive way to create teams that delivered valuable software. And something magical happened.

I got my joy back. Building software became fun again. Was it challenging, and hard, and sometimes aggravating? Yes. But my overall feeling was again one of joy.

That agile was the best way to build software. And, just as I was feeling good again, then it happened…

Again, I lost my joy.

Enter…The Agile Industrial Complex

Lately agile isn’t fun anymore! It’s lost its joy.

One reason for that is the Agile Industrial Complex that is selling:

  • Certifications,

  • Training,

  • Coaching,

  • Frameworks,

  • And Bears…Oh My!

For huge sums of money. It appears that they’ve lost their way and that the dollars are driving much of what they do. Instead of leading with agile basics and principles – both personal and agile. 

There is so much failure in the world around agility. Given the money to be made, charlatans are popping up everywhere. They claim to be experienced, but they’re not. They claim to deliver a magical performance result. They can’t. And client success suffers as a result.

In particular, the scaling frameworks drive me crazy. Everyone seems to want a Silver Bullet solution for scaling with SAFe leading the way. Here are my final thoughts on that.

And the bean counters seem to be taking over agile. Along with managers, the Agile PMO, project managers, and everyone else who is trying to take away the spirit of the agile team.

Several others have written about the Agile Industrial Complex and warned against its joylessness -

Wrapping Up

But I’m hopeful.

I’m hopeful that there are initiatives afoot that will bring about another era of agile in practice. One that gets back to the roots of the thing. A back to basics if you will. And, one that reemerges the joyfulness.

I’m looking for my joy and I’m hopeful that I will find it again. And does anyone remember laughter?

Stay agile my friends,

Bob.