Rants

The Scrum Master Dilemma

The Scrum Master Dilemma

My friend and colleague, Anthony Mersino posted the following question on LinkedIn -

https://www.linkedin.com/posts/anthonymersino_question-for-all-the-scrum-experts-out-there-activity-6778294424997814273-maRX

In order to answer his question, I’m wondering what decision we’d make if we replaced Scrum Master with something like…

Full-time, senior/experienced, backend-focused software developer. Call them BED. And reframe his question below—

Lost Art of INVITING Speakers

You’ve all seen them. A conference puts out a generic Call for Speakers or Call for Papers with a link to a website. Then perhaps sends a few email reminders and posts about the upcoming deadline. The expectation is that everyone—

  • Is aware of the website;

  • Has a clear idea to share;

  • ·Understands how to write a clear and compelling submission;

  • Has the incentive, courage, and time to do it;

  • And has the patience to wait for (most of the time) a polite decline letter that provides no

Then the deadline expires, the database is analyzed, and a program emerges.  

But often these same conference committees complain about the lack of diversity in their speakers. Or complain about the “same old voices” submitting. Or just complain.

Another Time

I remember a time, in 2010, when John Fodeh was the program chair of the EuroSTAR Conference. That year it was being held in Copenhagen, Denmark. If you’re not aware of it, EuroSTAR is a software testing centric conference. At the time, I was lightly aware of it, but I would not have thought of submitting a talk.

John reached out and invited me to do a keynote. Something that I had not done before. And he invited me to deliver a few half-day workshops as well.

He connected to me via my Software Endgames book that I’d published in 2004. While I was speaking at testing conferences, it was a “stretch” for John to reach out to me. One that surprised, frightened, and delighted me, all at the same time.

At the time, I’m not sure I appreciated the effort he put forth to reach out to me and work with me on crafting my talks at the conference. He helped me refine my topics, themes, and ideas. And he boosted my confidence along the way. In a way, he was a shepherd for me. Gently guiding me into his vision for the overall conference themes. And he was very generous with his time.

Back to the Future

I believe today’s conference organizers need to look back as a way of moving forward and perhaps follow John’s example.

The traditional Call for Submissions is not inclusive enough. It doesn’t invest sufficient effort in thinking broadly about possible invitations. It doesn’t invite new voices nor reach out to new communities. And it certainly does not mentor or shepherd them forward.

I know, I know, but it’s EASY. It would be so hard to personalize the craft of pulling a program together by actually mining for new voices and stretching out to be more inclusive.

But you know what. That’s too bad. If we want more—

  • Diversity

  • Inclusion

  • New voices

  • Novel ideas

  • Fresh approaches

  • Interesting takes

  • Contrarian points of view

  • Creative formats

  • did I say Diversity?

Then passive solicitation of presentations for your program isn’t good enough. It’s too impersonal. And, quite frankly, it’s a lazy approach.

Conference organizers around the world I have a call to action for you.

If you want more ideas, more vibrancy, more inclusion, more energy, and more excitement, then reach out and do more invitation…and more shepherding.

I think you’ll be amazed at what emerges.

And, John, thank you for extending my invitation. I’m not sure I ever truly thanked you for your incredibly generous offer and your gift of time.

Stay agile my friends,

Bob.

Empty Frame Metaphor

I’m writing this after the new 2020 Scrum Guide was announced along with a celebration of the 25th Anniversary of Scrum. 

There was quite a lot of hoopla associated with the event and the guide.

And the after-party, folks offering their interpretation of the changes within the guide, was even wilder. I swear that nearly every coach came out with a blog, whitepaper, webinar, or Q&A session to expand upon the (only 13 pages) of the Guide.

For the life of me, I’ve never seen anything like it. And I’m not implying that in a “good way”. Hey everyone, it’s a Scrum Guide. Not a new US Constitution or edition of the Bible or Harry Potter book.

Tobias to the rescue…

But leave it to Tobias Mayer to provide some perspective on all of the hoopla. I saw this post on LinkedIn about a week after the festivities—

A frame holds the artwork, but isn't itself the artwork. Hanging an empty frame on your wall won't magically create an instant masterpiece. Even making the frame yourself by following instructions in the Frame Guide won't make such magic occur. It is surprising how few people get that, and how many empty, and often poorly made frames are lying around in the corporate landscape.

WHAT a metaphor! And so meaningful and helpful to me right now.

Thank you, Tobias, for providing clarity and cutting through the hoopla!

Stay agile my friends,

Bob.

The Agile Game of Thrones

The Agile Game of Thrones

I have a confession to make. And as someone strongly tied to software development and technology cultures AND a die-hard reader of science fiction and fantasy books, this is incredibly embarrassing. But I’ll share it anyway and hope for your grace.

I never watched Game of Thrones in real-time. Instead, I collected the videos for all eight seasons with the intention of binge-watching them at an opportune moment.

Well, enter Covid-19 and opportune moment.

1—A Lannister always pays his debts.

I’m thinking of something related to technical debt in all of its forms. And in this case, have the organizational (and family) fortitude to always pay it down.

2—Winter is coming.

It’s a warning and a threat. Its reality hitting you between the eyes. It’s something that you’ve avoided for too long. I guess in agile, I’d like to connect it to Scaling Frameworks. All of them. And the acknowledgment that winter (the end) is coming for all of them. Or, at least I hope so.

The ONE Scaling Framework (Ring) to Rule Them All

This may be the shortest blog or article I ever write. 

My buddy Josh Anderson has inspired me to (re) discuss agile scaling frameworks in our latest Meta-cast series. You can listen to episodes #170 and #171 here.

In one of them, I mention that I ran across a diagram on the PMI’s Disciplined Agile site that represents all of the components.

What’s interesting in the diagram is that they’ve included:

  • DevOps

  • Extreme Programming

  • Scrum

  • SAFe (WooHoo!, finally someone ate SAFe…like it ate everything else)

  • PMBOK (even WooHoo’ier!)

  • Spotify (why not)

  • Kanban

  • Agile Modeling and Agile Data (Ambler’s work)

  • Unified Process (aka RUP)

  • Traditional (Yes!)

  • And the one I like most [and more…] aka the kitchen sink…

Under the DA toolkit/framework.

Finally

We now have ONE scaling framework to rule them all. Way to go PMI. I’m waiting to see how many certifications this leads to. WooHoo!!!

Stay agile my friends,

Bob.

Invitation vs. Imposition - Does it have to be such a STARK Delineation?

I’ve been reading Dan Mezick’s posts lately and he seems to be increasing his passion and push about invitation. I guess that makes sense. He IS a thought leader in this space and, as such, he probably needs to keep trying to inspire others towards this way of thinking.

But each time I read one of his posts, it rings “extreme” to me. Very stark and binary. That is – one either imposes or invites. With seemingly nothing in between. With imposition being Darth Vader to invitations’ Luke Skywalker.

For example, in a recent series of posts, he seemed to rail against the existing community of agile coaches, trainers, and pundits that very few (none) of them are pushing invitation. And challenging them as to why.

It even seemed as if he was judging all of them (us, me) in this. That if you didn’t publicly espouse invitation the way Dan is doing it, that you were somehow not doing your duty or were less of a coach. Or you had succumbed to the Dark Side.

I’m paraphrasing here, but I think I’ve honestly captured the essence of it.

A Recent Discussion

I recently saw a discussion initiated by Amr Elssamadisy. It seemed quite thoughtful to me and it resonated with my own experience.

Here’s a link to that post and the comments.

I considered it something in the “gray area” between imposition and invitation. Something that a thoughtful leader could navigate.

Amr directly asked Dan about his thoughts. And Dan shared them via a series of four comments.

I thought that Dan struck too binary of a stance in his reaction to Amr. That is, I’m wondering if he could be more moderated and open-minded to the possibilities of something positive between invitation and imposition? That is, are there circumstances where what Amr suggests might work? And what might those conditions be? 

What I’m really pushing on is the starkness of his view.

I also wrote a blog a while back that tried to focus a bit on the space between invitation and imposition. You can read it here.

Wrapping Up

In the end, I think Dan might be a tad too extreme. Sure, his ideas are:

  • Thoughtful;

  • Seem to be well-grounded in research;

  • Well-intentioned;

  • And often invitation is a powerful approach to real change.

But I don’t see them resonating in the real-world that leaders face today. And I don’t see sufficient trust in solid leadership to strike the right balance. Sure, many can’t do it effectively. But in my experience, many leaders can and they can inspire the results that Dan speaks to.

So, from my perspective, I’m publicly saying two things:

  1. An invitation is a powerful and often the best stance to create the space for agile change.

  2. BUT, it’s not the only approach. That is – the space in between can often be the way to go…

Amr, thanks for your insights. Dan, thank you for pushing us to consider better approaches!

Stay agile my friends,

Bob.

The Emperor Has No Clothes

This is going to be a short and hopefully sweet post. 

First, I need to acknowledge Sandy Mamoli. My goodness, I love her perspective. I think she’s smart, relevant, wise, experienced, pointed, and courageous. She’s one of those honest folks we need around us to tell us when we’re off-track. When we’ve made a huge mistake…that we continue to make. That is…when we have no clothes.

Sandy recently published a blog post entitled—Individual performance is not relevant

In it, she makes a really compelling case that we should stop worrying about, considering, measuring, and rewarding individual performance. Instead, we should be solely focused on teams and teaming and team results.

I’ve always felt this way. Always.

But I’ve been encouraged (forced) to measure individuals for years. Sure, I can say…

  • My boss made me do it

  • HR made me do it

  • The company culture made me do it

  • My peers made me do it

  • Etc….

I wasn’t a victim either. I opted into assessing individuals. But years ago, I decided to opt-out of that…forever!

To entice you to read the entire article, here’s a snippet—

Stop “managing” individual performance. I recently spoke in Hamburg at an Agile People HR meetup and someone asked “How do you manage performance?” To that person I want to say, it’s a moot point, really. Individual performance is irrelevant. You can’t win (or lose) as an individual. So, let’s please stop wasting everyone’s time trying to measure and manage individual performance.

Wrapping Up

So… 

What are you going to do with this new information? Are you going to pivot from individual to team considerations as a leader? In the end, you know in your heart what Sandy is saying is true. It just is. 

So, the real question is—Leaders, are you going to change?

Thank you, Sandy! 

Stay agile my friends,

Bob.

The Cat is Out of the Bag!

Sshhh….

Let me share the BIGGEST secret in agile transformations. But first—

  • Let me apologize in advance to all of those agile coaching & training firms for letting the cat out of the bag. And for any impacts to your revenue streams.

  • Let me apologize in advance for any impact this might have on any firm “doing agile”.

  • And finally, let me apologize for not saying this sooner. I should have probably been saying this loudly and often at least a decade ago. If not earlier!

That being said, I’m sharing it now, so better late than never…

Bob, we can’t stand it. What is the secret?

Drum roll, please…

It’s that – Leaders need to go first. In everything!

  • Go first, in understanding the agile and lean mindsets;

  • Go first, in attending sufficient training to understand of what good looks like;

  • Go first, in internalizing all of this so that they begin to become agile from the inside/out;

  • Go first, in shaping the vision, why, and stories behind their agile journey;

  • Go first, in inviting their organizations to be part of their agile why and vision;

  • Go first, in walking their talk each and every day. Modeling an agile mindset, setting the culture appropriately and showing everyone the way forward…

You can take and invest in all of the “team focused” activity you want to. But it’s not going to work out as well as it will when leaders (senior leaders, mid-level management, PMO’s, etc.) actually work on transitioning themselves to agile before they inflict it on their teams or organization.

There! The cat is out of the bag!

Enjoy the benefits of this secret information and share it with all of your friends.

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.

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!