Skip to content

Commit

Permalink
Merge pull request #148 from 8fold/move-scrum-master-shit-article
Browse files Browse the repository at this point in the history
Move scrum master shit article
  • Loading branch information
joshbruce authored Dec 18, 2021
2 parents 8a976bd + de6b7ff commit 09eab68
Show file tree
Hide file tree
Showing 10 changed files with 243 additions and 35 deletions.
175 changes: 175 additions & 0 deletions content/public/coaching/being-a-scrum-master/content.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,175 @@
---
title: Being a Scrum Master
created: 20180924
moved: 20211203
updated: 20211204
original: https://medium.com/8fold-pub/how-many-years-experience-do-you-have-62268cb2316c Medium
---

![Silhouettes armed with swords facing off to doe battle, with the words: Everybody wants to be a Scrum Master...until it's time to do Scrum Master shit](/media/coaching/scrum-master-shit.png)

# Suit up samurai

{!! dateblock !!}

{!! original !!}

Gonna be a lot going on here.

I've seen a fair amount of job descriptions over the years. They're all different, even for the same job title. Makes sense.

Having said that, I don't think I've seen as much variation than that of Scrum Master.

I get it, to a certain extent, it's a new role figuring its life out and organizations aren't always able to translate what they know to this thing. What makes Scrum Master different is the role has a canonical [baseline definition](https://scrumguides.org/scrum-guide.html#scrum-master) and doesn't need to be written from whole cloth.

The [Scrum Guide](https://scrumguides.org/scrum-guide.html) is the canonical definition for baseline Scrum. In the guide there is a definition for what the accountabilities and responsibilities of the Scrum Master are. Further, the Scrum Guide states that if we remove any of the components we cannot call it Scrum. It's okay to not practice Scrum. However, I've seen and talked to many folks who have positive and negative feelings toward Scrum and later learn that it's not Scrum; often it's traditionally practices from [.XP](eXtreme Programming) added to Scrum or replacing portions of Scrum.

In my estimation if we remove a responsibility from the person holding the title Scrum Master, they're not actually a Scrum Master, just like what is being practiced is not Scrum. Therefore, when I see job descriptions for Scrum Masters that go beyond what's listed in the Scrum Guide, I tend to think "and." So, some of these job descriptions scare me. Not because I can't do it but because I can't do it all with any high degree of effectiveness.

There's also the idea of what qualifies as experience.

I've held many job titles. It's only been since 2015 that any of them were that of Scrum Master. The number of teams I've been on practicing Scrum have been even fewer. And, I typically do the same sorts of things in each role, many of which fall into the Scrum values and the accountabilities and responsibilities of a Scrum Master. If you only look at job title though, not so much.

Time to do Scrum Master shit, the baseline of which being the values called out in the Scrum Guide: commitment, courage, focus, openness and respect.

***

## The Scrum Guide

A quick note on the distinction between accountability and responsibility.

I appreciate this definition from [Keny Beck](https://medium.com/@kentbeck_7670/accountability-in-software-development-375d42932813) (one of, if not the, creator of XP):

> A key to performing well is accountability: making commitments, working in ways I am proud of, and rendering account of my activities clearly and directly.
Accountability isn't about blame it's about being able to account for something; how's it going? Responsibility, in my estimation as of now, is about doing.

Moving on.

Imagine your résumé without the inclusion of job title, just things you've done. The responsibilities and accountabilities are more important than the job title. I've been in interviews where I've asked a rather common question for me: Can you give me sort of a day-in-the-life of the person filling this role at your company.

I cannot tell you the number of times the story of Scrum Master doesn't include most, if any, of the list from the Scrum Guide.

I've updated the following to be in keep with The 2020 Scrum Guide.

> The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide.
In previous versions of the guide, the word accountable was responsible. However, it's the last bit I see most lacking in those us taking on the mantle of Scrum Master. I've met many folks with the title, who don't know The Scrum Guide exists or that the co-creators are still actively practicing in the community. (Some don't even know about The Manifesto for Agile Software Development, it's getting better on both fronts.)

This isn't about gatekeeping, it's about awareness of a profession and the responsibilities and accountabilities of that profession or role.

On social media the other day someone made a list of all the things a web developer "needs" to know in order to call themselves a web developer. The list did not include [.HTML](Hypertext Markup Language), which is how the web displays things. That's gatekeeping: You won't be let in unless.

With that said, in my own [journey on the web](/web-development/my-history-on-the-web/), I've learned a lot that I did not know when I first started calling myself a web designer and developer. Initially I didn't feel comfortable calling myself a web developer because I didn't write code. I still don't feel comfortable calling myself a web developer. And, there is no canonical reference for web developer as a profession; for better and worse.

When it comes to being a Scrum Master, I find myself referencing the Scrum Guide all the time; because that's part of my accountability when I take on the mantle of Scrum Master. Now, it's not the *only* thing I reference.

Speaking of referencing the guide:

> Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.
Teacher and learner - continuously. Nothing stays the same—not even The Scrum Guide.

I've seen many Scrum Masters (and critics) who still say the ideal team size is 3–9 people or 7 plus or minus two or three or whatever the old language was. In previous versions this was explicit language, in the 2020 version, this language was removed and replaced with:

> The Scrum Team is *small* enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people.
By operating on the older information Scrum Masters can end up in the position of saying, "You're doing it wrong," when they may not be. It can also lead to *others* within the organization saying, "We're doing it wrong," when it's just that they're operating on outdated information. When this happens, it's time to do Scrum Master shit and inform the person of the changes.

Note: Anyone can take on that accountability. A member of the development team could tell the Scrum Master they are incorrect or operating on outdated information. If the Scrum Guide were an operating system, how many of us are still running Windows 3.1?

Back to the guide:

> Scrum Masters are true leaders who serve the Scrum Team and the larger organization.
I don't know what "true leaders" means, however, there are details that come later in the guide. Scrum Masters *serve* the Product Owner, Development Team, and broader organization. In previous versions the term servant-leader was used. I can understand why it was changed; however, I think the general point remains: It's about sharing influence and authority, not consolidating influence and authority.

Some highlights.

> The Scrum Master serves the Scrum Team in several ways, including: Causing the removal of impediments to the Scrum Team’s progress
Sometimes that's me encouraging team members to have the necessary interactions, introducing them to the necessary people, or, if the team feels they can't do it, then I say to myself: suit up samurai, you're up.

One story starts with me trying to do something small in the new virtual development environment all the software developers were supposed. I was trying to put a training video together and couldn't believe how long it took to do relatively basic things.

I talked with other Scrum Masters; they all kinda had a "What can you do?" attitude.

A little while later, the program was going to take away the workaround they had offered to developers and require they use the virtual development environment. My team was very concerned and I asked if this was something they wanted to take on or if it's something they wanted me to try and handle. They asked me to do it.

I followed the process and made a ticket raising the impediment. After over two dozen emails, between me and the lead of the team responsible for the virtual development environment the thread escalated quickly in the number of participants up to and including one of the [.CIOs](Chief Information Technology Officers). The gist of the thread from the lead was: Josh is just complaining and hindering progress. When the CIO was added to the list of participants in the thread, it changed quickly to: Let's have a meeting to discuss.

At the meeting I used my [.UX](user experience) background and demonstrated, empirically the difference between what developers are accustomed to compared to what the virtual development offered.

In five to 10 minutes I had cloned a repository from GitHub, installed all the packages necessary to run a site locally, and demonstrated I could see the site in a browser.

Then I went to the virtual development environment and tried to do the same thing. I showed how I had to go through two-factor authentication three times before being able to do anything; remarking that when the connection timed out, I'd have to do it all again. Then I skipped installing the packages because it would take 30 minutes on its own. Even with a 30 minute head start is still took roughly 30 minutes for me to get the point of trying to get the site to run locally—it never did.

We never switched to the virtual development environment while I was there. We did make progress toward it being better though.

My official title at the time was not Scrum Master.

Someone has to do the work. If no one else is willing, even all the "real" Scrum Masters, it's time to suit up samurai.

As a servant to the team, it is all our jobs to make transparent that which others may lack the courage (and other values) to do so.

That's why I think the samurai reference is better than the Superman or Batman characters I've seen elsewhere. The referee analogy is okay but incomplete. Samurai though, you could take damage (not Superman) and you don't have almost infinite resources to make something happen (Batman). You, your sword, and pretty light armor (maybe a horse).

> The Scrum Master serves the Product Owner in several ways, including: Helping find techniques for effective Product Goal definition and Product Backlog management
I think this speaks to something from The Manifesto for [Agile Software Development](https://agilemanifesto.org):

> We are uncovering better ways of developing software by doing it and helping others do it.
Of course, the ideas from The Manifesto are being applied beyond software, however, it's important to note that it doesn't say: We are uncovering the one, absolutely right way to work in all situations.

The Guide doesn't go into detail regarding what constitutes an impediment. Is an impediment only something that could stop the team from achieving their Sprint Goal? Or, is it a power of "and" situation? The way I look at this part of my role is to reduce friction between the people making something and the people who want that thing; therefore, it's a lot broader.

Now for the organization:

> The Scrum Master serves the organization in several ways, including: Leading, training, and coaching the organization in its Scrum adoption
For some, the title Scrum Master doesn't mean Scrum is being used. Instead, it's a generic term for a team-level coach. This is distinguishable from the title of Agile Coach, which is seen as an organization-level person. Both are there to help the organization adopt the values, principles, practices, and tools associated with agile software development.

I really appreciate Lyssa Adkins, author of *Coaching Agile Teams*, for coming out and explicitly saying, "Scrum Masters are Agile Coaches."

For me, if you're not trying to implement Scrum, use Agile Coach for the job titles. Of course, the intent of language is sometimes not the way it is used and this could confuse recruiters.

***

## Revisiting what qualifies experience?

![Tweet from Andy Hunt, reading: Itʼs even worse for kids just out of college. “Entry level” with years of experience required! Donʼt think they understand the concept of entry level.](/media/coaching/entry-level-andy-hunt-tweet.png)

What if I was self-employed for a while?

If not, I lose experience points.

What about personal or community projects (and volunteer work)?

If not, more lost experience points.

I think what folks are trying to do here is mitigate risk by finding someone who has worked in a similar environment for a certain period.

It's lift and shift.

Lifting someone who's worked at Bank A for 20 years and shifting them to Bank B seems safer than hiring someone "off the street."

This is how we end up hiring someone who's been a Scrum Master for 15 years and watch them struggle. Maybe they spent 15 years in the same organization, with the same team, and the organization didn't change much over that time. In that 15 years they had one class and never revisited that education. Taken further, maybe the organization "went Agile" by shifting the title Project Manager to Scrum Master without actually changing the responsibilities and accountabilities of the person.

***

## Time in grade

Most job descriptions I see require 5 years of experience. I remember asking multiple recruiters, "Are they looking for years of experience overall or years of experience where someone other than me gave me the title 'Scrum Master'?"

The response has been, "Someone else giving you the title."

To which my reply is, "I don't meet the requirement then. Thank you for thinking of me though." (I can say I have the experience now and since 2015, despite always kinda operating in the same way when I'm dropped into an environment.)

A recruiter once asked I could change on the titles on my résumé because the description was close to being a Scrum Master. I said, "I always do the same things when I get brought in. I just don't get to choose my title. If they check, they will not be told I was a Scrum Master."

There's also the idea of the number of recent years experience.

I knew someone once who said they had 20 years of experience doing software development. As I probed, I discovered the experience was working in Assembly and COBOL and they hadn't done it for 20 years.

This is why I try to be very clear when I tell people I've been doing development since 1998 and that I'm still relatively active in that regard.
Empty file.
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
---
title: December 15th, 2021 paycheck
created: 20211217
data:
- [Debt, 0, 0, 0.6]
- [Cash, 5, 10, 15.4]
- [Low correlation, 0, 1, 0.6]
- [Negative correlation, 0, 1, 0.7]
- [US equities - small, 24, 35, 21.8]
- [US equities - mid, 24, 35, 22.8]
- [US equities - large, 24, 35, 37.7]
---

# December 15th, 2021 paycheck

{!! dateblock !!}

{!! data !!}

This one is going to be a bit odd from a numbers perspective. I was paid again on the seventeenth before I published this article. December is a three check month for me.

So, the cash includes a paycheck that technically wasn't there on the fifteenth. However, it shouldn't cause too much of a problem I don't think.

The 90 days for the [.IRS](Internal Revenue Service) was up on the eighth. That includes weekends though, so, I'm giving it a few more days until I call to check status and confirm the all clear.

Transferring my [.HSA](Health Savings Account) has been finished yet. Will be calling them regarding that.

About to hit the maximum on 401k contributions. Need to email my employer to confirm what happens then.

Beyond that, pretty boring and the [.FI](Financial Independence) portfolios are proving themselves out as it relates to the risk parity portfolio concept. The 100 percent equities portfolio shows down roughly 3 percent while the risk parity should down only a little over 1 percent. I think I will start doing paycheck-to-paycheck comparisons similar to what Frank Vasquez does with the portfolios on [Risk Parity Radio](https://www.riskparityradio.com). I think it would be a better way for comparison and tracking over time; especially since I did the contribution accidentally the other day and started two of them after all the others. I can't tell if the others are actually doing better, or if it's just because they haven't been around as long.

So, yeah, pretty boring.

This file was deleted.

Loading

0 comments on commit 09eab68

Please sign in to comment.