Thread by @rdonoghue

I've been getting involved more in how we form scrum teams (in the logistics and hiring sense, not the "forming, storming etc) and it's struck me that it is ass backwards that we seek out Scrum Masters & Product Owners the same way.

Getting a Scrum master for a team is like hiring any other specialist. Some overlap of domain knowledge is valuable, but you are bringing them in to do specific work with specific tools and learning what they know is part of the expertise.

Like a facilitator, much of what a good scrum master can contribute is agnostic to what the product is. Expertise and learning add value, but the baseline requires very little. Which is great, because it means you can air drop a scrum master into most situations and see results

(Same is true of a good project manager. This statement only needs to get made because we like to pretend that agile and project management are contradictory disciplines, but that's mostly a fiction created to sell certifications)

Product Owners are not so fungible.

Now, I have to qualify that statement a little. There is a category of professional product folks who also have specific skills and tools, and those *are* portable and flexible.

You can airdrop one of those folks into any situation and they'll ask the right questions, kick off the right activities and generally do the professional product work that can really make things AWESOME.

Such people are rarely given the role of product owner.

It's *awesome* when it happens, but there's a cultural disconnect that especially hangs around the names. Peopel who are good at this have titles that reflect their expertise. For them, product owner is - linguistically at least - a demotion.

And it also kind of undercuts the value of their skills because 'anyone can be a product owner'.

That sentiment is true, but also a bit deceptive, and merits unpacking.

A project needs a vision, and in scrum, that vision comes from the customer, as represented by the product owner. Ideally, the PO *is* the customer, or someone who works for them, but it might also be a middleperson or similar. Whoever they are, SOMEONE needs to have a vision.

If they have product skills, it will be a BETTER vision. It will have been interrogated more strongly, communicated with people more, tested more, and generally be better handled.

But if they have the skills but no vision, then the project is just an exercise.

This *shouldn't* be a hard problem to solve. Someone else might have the vision but no skills can work with someone with the skills, who serves as the product owner.

But this seems vanishingly rare in my experience.

Partly because product skills are rare enough that they are better deployed higher up the food chain. Partly because the perspective that connects to those skills tends to draw one away from the weeds of day to day standups and code checkins.

I am not saying those skills are harder than those of a scrum master or developer - I don't think they are - but they're *rarer*, because we don't have the infrastructure to teach them, nor have we fully articulated the demand for them.

There are many bad things to be said about the agile certification mill system, but scrum has absolutely succeeded in articulating the case for the scrum master (arguably to the point of commoditization).

I should also note that the skills of a good scrum Master and a good Product person overlap a lot (because a lot of them are variations on the 'value people') theme, which is why product is often the route "up and out" for strong scrum masters. Which perpetuates the divide.

Bottom line, it's hard to get a professional product person as a PO, and even if you can, *someone* still needs to own the vision. So the easiest solution is to just make the person who has that vision the PO, no matter what their actual job is.

Because, remember, the *roles* on a scrum team are only the roles in that team. Scrum Master & Product owner aren't (or shouldn't be) *jobs*. They are the roles on the team filled by people with the skill.

And, once again, that illustrates the divide: Scrum Master is often the job *and* the role. It's pretty rare that the same is true for product owners.

So product owner tends to be a bit of a crap shoot. At the very least, you hope you have someone who has a clear, strong vision and a willingness to engage the team. They may not have the skills, but those can be taught (and that's something a good Scrum Master can coach).

Less ideally, but more frequently, you get someone who works for the person who works for the person who has a vague idea of the vision, doing their PO work as a side gig on top of their real job.

This goes as well as you might expect

Worse, this less ideal situation is common enough that it's almost *expected*. Which goes a long way towards explaining why people who are passionate about product as a discipline and have built their skills don't want to be even FAINTLY associated with the role.

Which brings us back to how we build teams.

Quite frequently, someone has an idea for a team, and its followed by an allocation process of creating slots for developers, a scrum master, and a product owner. The first parts are fine, but the last is where it gets backwards.

To my mind, the Product Owner should be the FIRST person on the team. They are the demiurge responsible for WHY there's a team in the first place. They have a problem or a need or a want, and all work flows from that,

When you start from the product owner, you start from the reason to work, and things flow very organically from there.

But if product owner is just a seat to fill, how can you possibly end up with anything but compromise?

I don't have any kind of magic bullet solution here. There are several obvious hard work solutions on the table, but that represents its own challenge.

But I talk through all this to help sharpen things in my mind as I go into conversations where people are going to treat the role of PO as an afterthought, and I need to find ways to change that.

Oy. Well, that's setting me up for a cheery day.

This puts it very succinctly:

https://twitter.com/capybarbarian/status/1461327128872599556

Sidebar: Part of the reason that I see overlap in skills between product and agile is their shared root concepts, but also - practically - an SM may need to coach a PO on product practice, and a PO needs to be able to actually work *with* the team, which agile helps with.

Which is to say, both roles benefit from a deep appreciation of the other role.

BTW, it might sound like I am suggesting that the Product Owner role is less replaceable than the Scrum Master role on a team.

I am not suggesting it.

I am stating it outright.

Don't get me wrong: The scrum master role is valuable, and it's also how I put bread on the table, so I'm kind of invested in it. But If you have a team and a product owner, stuff will get done, even without an SM. Remove one of the other legs of the stool and it falls over.