April 2, 2025 • 32 mins
The Agile landscape has evolved dramatically in recent years, with demand for traditional roles decreasing while expectations for value delivery increase. How can Agile practitioners adapt and thrive in this changing environment?
Jessica Soroky, Senior Director of Program Management and Product Operations at Pendo, shares her fascinating journey transforming a team of Scrum Masters into Program Managers. This strategic shift expanded their focus from the software development lifecycle to the entire product development lifecycle – from initial ideation through customer validation to post-launch activities.
What makes this conversation particularly valuable is Jessica's candid assessment of the current state of Agile. While rejecting claims that "Agile is dead," she acknowledges significant market changes where once-plentiful positions have become scarce and increasingly specialized. Her insights on domain knowledge requirements reveal a troubling trend: companies demanding hyper-specific industry experience rather than valuing diverse perspectives that could drive innovation.
The most powerful takeaway comes from Jessica's practical experience leading organizational change. By redistributing responsibilities (engineering managers taking over standups, product managers owning sprint planning) while preserving the core facilitation expertise of Agile professionals, her team accomplished something remarkable – they shifted conversations from outputs to outcomes. Rather than celebrating completed sprints, they began focusing on delivering actual customer value.
For Agile practitioners wondering about their career trajectory, this episode provides a compelling roadmap. The skills that make great Scrum Masters – facilitation, process improvement, and human-centered problem-solving – create countless opportunities when applied more broadly. Former team members have progressed into product management, operations roles, and chief of staff positions they might never have discovered otherwise.
Ready to expand your perspective on what Agile can be? Listen now and discover how broadening your focus might reveal unexpected career opportunities and deliver greater value to your organization.
Connect with Jessica on LinkedIn:
https://www.linkedin.com/in/jessicasoroky/
Follow us on LinkedIn:
https://www.linkedin.com/company/the-agile-within
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:06):
Welcome to the Agile Within.
I am your host, mark Metz.
My mission for this podcast isto provide Agile insights into
human values and behaviorsthrough genuine connections.
My guests and I will sharereal-life stories from our Agile
journeys, triumphs, blundersand everything in between, as
(00:29):
well as the lessons that we havelearned.
So get pumped, get rocking.
The Agile Within starts now.
Before we dive into today'sepisode, I'd like to take a
moment to thank our sponsor,impact Agility.
Impact Agility specializes intraining and coaching through
(00:49):
scrumorg and proconbonorg,empowering teams with
cutting-edge tools andtechniques.
Their classes are designed todeliver actionable insights,
whether you're a scrum master,agile coach, delivery manager or
organizational leader.
Whether you're a scrum master,agile coach, delivery manager or
organizational leader, at thehelm is president and founder
(01:13):
Matt Domenici, who has guidedover 50 organizations toward
professional agility.
With his hands-on experience,matt helps teams and
organizations take ownership oftheir processes and outcomes,
unlocking their full potentialTo explore free learning
resources, check out theirtraining schedule or book a free
consultation.
Visit impactagilityco Onceagain.
(01:35):
That's impactagilityco.
Well, hey, welcome backeverybody.
This is your host, mark Metz,at the Agile Weather Inn.
I hope you're having anabsolutely fantastic day out
there today.
Our guest for this episode isJessica Soroki.
Jessica, welcome to the show.
Speaker 2 (01:54):
Thanks for having me, mark, super excited.
Speaker 1 (01:56):
Well, jessica is from nearby Atlanta Georgia.
I'm just about four hours eastof her in Columbia, south
Carolina.
So, jessica, if I were comingto Atlanta Georgia for a day,
been there many times, but if Ihadn't been there before, what's
one thing that you would saythat I couldn't miss?
Speaker 2 (02:11):
doing.
I would say you couldn't missthe aquarium.
It's like the number oneattraction, so I don't feel
super unique in suggesting it,but it is super cool.
And I did recently learn thatyou can actually go scuba diving
with the whale sharks, so thatis now newly on my to-do list at
some point is to get in thewater with them, and that's I'm
(02:33):
super cool.
Speaker 1 (02:34):
And you did say whale sharks, not sharks, right?
Speaker 2 (02:38):
Yes, whale sharks, they are very gentle, from what
I understand.
Speaker 1 (02:43):
We both have families and I understand that you can
have like spend-the-nightparties in the aquarium.
Is that right?
Speaker 2 (02:49):
You can have sleepovers in the aquarium, like
sometimes schools will do it oryou can do it privately.
And they actually also have apretty extensive summer camp
program now for like 5 to, Ithink, 12 years old, all about
STEM and getting kids excitedabout the sciences and math and
all that kind of fun stuff.
Speaker 1 (03:08):
That's awesome.
Well, I'll have to say itreally is impressive when you
walk into the aquarium and yousee those whale sharks for the
first time, because you try toprepare yourself for how big
they're going to be, but untilyou see them in person, they're
tremendous.
They are huge.
Speaker 2 (03:24):
We have three little boys five and twin
three-year-olds and we can sitthere for quite some time just
looking at that huge aquariumand watching the whale sharks go
by and all the other things.
And anyone who has little kidsknows that attention spans are
very short, but that keeps theirattention quite long actually.
Speaker 1 (03:42):
Well, I'm a big kid at heart.
I love animals, so yeah, Icould spend all day in the
aquarium and be perfectly happy,all right.
Well, I want to introduceJessica.
She is a Senior Director ofProgram Management and Product
Operations.
Jessica, why don't you tell usa little bit about your role?
Speaker 2 (03:59):
Yeah.
So I figured it might behelpful to give like a little
description of the role but alsomy background.
I was in Agile roles for 12years prior to my current role,
so that would be everything froma scrum master to Agile
consulting and coaching.
I was a professionalfacilitator and professional
(04:20):
speaker for a long time doingthe big conference circuit.
I was an executive coach allthe things.
My current role programmanagement and product
operations for Pendo is kind ofmy next evolution in that role,
which I'm sure we're going toget into all things there.
But product operations the bestthing I can say about it simply
(04:40):
to an agile audience is it islike a souped up scrrum Master
for an entire productorganization.
So their whole job is to makeproduct managers more effective,
minimize wasteful activities,get them focused on all the
creative ideation, buildingproducts things.
Speaker 1 (04:59):
So, leading into that , you and I had a conversation
before this recording and wetalked about the state of Agile,
yeah, and so let's talk alittle bit.
What do you see as the currentlandscape for Agile and for
agility, jessica?
Speaker 2 (05:14):
Yeah, I'm not going to jump on the bandwagon of it's
dying or it's dead.
I don't think it is dying ordead.
I do think that it is less of acraze than it used to be and I
do think that, unfortunately,there's just not a super
consistent success story withagile and corporations.
(05:34):
So when you go from company tocompany large or midsize markets
you just hear really mixedexperiences with it and I think
that because there's not thislike super strong, consistent,
no, when you do agile, you get X, y and Z out of it.
I think executives are still amixed bag of weariness and
(05:55):
buy-in level and because of that, I think that's why it is kind
of in the same state, in thesense that I don't think it's
dead.
I think you have plenty ofleaders out there and plenty of
companies that still get somevalue out of it, but I don't
think it's ever going to go backto the peak that it was.
When you were you couldn't.
You could throw a rock and hita hundred job openings or maybe
(06:17):
that's a little bit of anexaggeration but dozens of job
openings.
It wasn't difficult to find ajob in the agile market,
regardless of what level youwere at.
That's all changed.
There's been some really bigagile forward companies, like
Capital One and a few others,that very publicly cut all, if
not very close to all, of theiragile roles, and the market
(06:41):
right now is really difficult.
My husband just went through ajob hunt recently in agile roles
and senior scrum, master, rtetype of roles and it is really
difficult.
You're getting hundreds ofpeople applying for every
opening out there and it is areal fight because there's just
not nearly the demand that thereused to be demand that there
(07:08):
used to be, so I think it isimportant to delineate.
Speaker 1 (07:09):
There is demand.
It's just not what it used tobe.
Yeah, because that demand usedto be high, we had a large
number of people entering theworkforce.
Speaker 2 (07:16):
Absolutely.
Speaker 1 (07:17):
So now we have a smaller market with more people,
so it's simple supply anddemand right.
Speaker 2 (07:23):
Yeah, absolutely, which is why I don't think it's
dying or dead, because there isstill a demand for it.
There are still companies whosee value and agility and want
to embrace it.
If that weren't the case, Iwould jump on the bandwagon of
okay, it's dying or it's dead.
Everyone, give up and find thenew thing.
Speaker 1 (07:40):
So you and I discussed that companies like
Capital One are doing away withanything that has Agile in the
title.
They just got rid of thosepositions right.
And I think when we werelooking at Agile positions, many
of us as Agilists, we wereleaning back.
And when I say leaning back, wewere leaning back from the
(08:01):
business, from the product, andwe were focused more on how the
sausage is being built, what areour processes like, and not as
much leaning in to the actualbusiness.
So what do you see as domainknowledge?
How important do you feel thatis for Agilis today?
Jessica?
Speaker 2 (08:21):
Yeah, I think my opinion has changed over time.
I used to be veryanti-technical backgrounds when
it came to Agilist, scrumMasters, coaches, and I still,
frankly, if you're hiring orhave Scrum Masters, I still very
much believe that, while beingtechnical in some way can have
(08:42):
some value, in my experiencebrings too much danger to the
conversation and that they wereway too comfortable with what
the engineers are talking about,and I think we all know there's
not a single engineer out therewho wants anybody in a scrum
master, agile role telling themhow or what to build.
So my stance was always likeknow just enough to know what
(09:05):
questions to ask, but don't knowenough to have an opinion on
the answer.
And I don't know that.
That's wildly different.
I will say, like, if we get intolike where I think Agilists
should start looking when itcomes to career, what's next for
them, I do think domainknowledge becomes more important
, but I would still argue thatif you are really good at
(09:26):
operations, process humans, teambuilding, all those types of
things, it really shouldn'tmatter what the context is of
what they are working on.
You should be able to do all ofthose things regardless.
And I think people lean intotoo much domain knowledge when
they aren't as comfortable onsome of those other skills.
That being said, I'm going tocontradict myself a little bit
(09:47):
here and say that, like I dothink you have to have basic
domain knowledge of how abusiness builds products and how
an engineering team buildssoftware.
I think that is important, butI don't know that it has to go
deeper than that.
Speaker 1 (10:03):
I'll just share a frustration of mine here
recently.
So I have been in the job huntmyself, like your husband, and
was applying for jobs, and therecruiters would ask me if I had
banking experience, and myanswer was yes.
And their next question was ohso which bank are you coming
from?
And my response was well, I'mnot coming from a bank.
I have from years past.
(10:24):
I have banking experience, butI'm not coming from a bank.
Oh well, this customer, theywant someone coming from a
banking background directly, andyou know, you know, I think you
sell yourself and so you knowthe customer is always right.
But you're trying to sellyourself and it's like, well,
sometimes you can be so close tothe problem that you can't
(10:47):
really think outside the box.
And that was my angle and I wasunsuccessful at painting that
picture.
But I was like, do you reallywant someone who is in the
banking bubble that maybe youdon't have?
There are other domains outthere.
There are other verticals,other businesses that you could
benefit from.
Wouldn't it behoove you to havesomeone that has a wealth of
(11:10):
experience and not just in yourown little bubble?
Speaker 2 (11:13):
And you're not the only one that experienced that.
My husband had the exact sameexperience.
It wasn't, I don't know,banking, but it definitely was
like insurance was a big one.
Which insurance company are youcoming from?
Those types of things?
I think my hot take here isgoing back to that supply and
demand point we were makingearlier.
I think it has everything to dowith that.
(11:34):
Five years ago, when demand andsupply weren't matching and
there weren't enough people tofill all of the agile roles or
opening, there was a lot moreopenness, I think, to diverse
backgrounds and different pointsof views.
And now, because there's somuch supply and so little
comparative demand, I thinkcompanies are getting into like
really weird behaviors that youjust described of like no, I
(11:57):
need exactly this experience,exactly this background, and
they're probably convincingthemselves that that's the key
to making agile work and that is, I know, means, the key to
making it work.
I will say my current company.
We look at backgrounds, butmainly from like to understand
what speed of organizations youcome from.
So, for instance, like we willlook at resumes when it comes to
(12:18):
like insurance or banking andno offense to anybody in those
worlds, they're typicallyslightly slower moving companies
than a SaaS startup right.
So it's not to say that it's adeterrent, but it does change
some of our questions andinterviews to make sure that
somebody coming from thosebackgrounds into a SaaS startup
type of environment feels likethey can still be successful
(12:39):
because the speed of pace iswildly different and I think
that's okay.
But I think getting reallystuck in know what specific bank
did you come from feelsunnecessary.
Speaker 1 (12:51):
I agree, I agree.
So, like I said, I wasunsuccessful, but I'll continue
to fight the crusade along withyour husband.
There we go.
So, jessica, we talked aboutone dead end road that I have
experienced.
What are some alternative paths, maybe, that we might take in
order to serve companies betterand not be stuck in the?
(13:13):
You know, I'm just going to bea facilitator or I'm just going
to schedule meetings, I'm givingair quotes.
How do we pivot here for theagilist out there?
How do we pivot here for theAgilist out there?
Speaker 2 (13:25):
Yeah, so Pendo, which is where I work.
I've been there for almostseven years and we actually
experienced this need for I hateto use the word transformation,
but essentially this need foran internal transformation.
We have always been an Agilecompany and I really do mean
that Two of our four co-foundersare very, very deeply embedded.
(13:46):
They've always been bought in.
It's never been a fight.
But, all that being said, therecame a point where, even in
that environment, questionsstarted to arise around, like do
we really need this many scrummasters?
What do they really add value?
Like, how do they really addvalue?
Why can't my engineeringmanager just do this meeting
facilitation stuff and keep usorganized and do the math on
(14:10):
sprint velocity and capacity andall that kind of fun stuff?
And so when I heard thosequestions, it was, I think,
about a year into COVID and thatkind of sent like my hairs
raising right, like, oh, I'vebeen down this path before.
I don't want to see big layoffsin this team Like they.
I know that they are highlyskilled.
So we did an objectiveassessment of kind of like how
(14:31):
we were executing against ouragile processes and how we built
products, and what we came upwith was, I think, a really
significant career move for alot of agilists out there.
But what we figured out is thatthe product development
lifecycle is actually a lotbigger than the software
development lifecycle.
The software developmentlifecycle is a piece of the
(14:52):
product development lifecycle,and what the product development
lifecycle has that the otherone doesn't is it has the early
ideation phases, it has customervalidation, it has research,
it's got data gathering, it'sgot experimentation and designs.
It also has, at the other endof it, when the software is done
, being built, how do youprepare a company to launch that
(15:14):
software into customer hands?
How do you make sure that yoursupport organizations are ready,
that your sales team knows howto sell it, that your
documentation is where it needsto be all these different pieces
right.
And so we weren't really goodat either one of those parts.
We were good at the softwaredevelopment lifecycle.
We'd gotten that.
We figured that part out, and sowe made a decision that was
pretty bold and we moved all ofour Scrum Masters from
(15:37):
engineering as Scrum Masters toproduct as program managers and
we partnered them up with theproduct this very small product
operations team that we had atthe time, and the whole point of
that was because we wantedthere to be a single point of
accountability essentially forthat entire product development
lifecycle, and we needed aprocess expert to help us make
(15:59):
that whole product developmentlifecycle much more effective,
much more efficient.
We needed a consistent processacross.
At the point At that time, Ithink we had don't totally hold
me to this but roughly 30 scrumteams, give or take a few, and
so we needed to figure out howto get them all marching in the
same direction, just like wewould.
A software developmentlifecycle, but now for this
whole beginning of idea throughcustomer hands, and so we move
(16:23):
them into program management.
And I will say I didn't love itwhen I came to the team and
said hey, I'm going to changeyour titles and I'm going to
change your job.
I need you, and I kind ofpositioned it from the point of
view of I need you to maintain alot of what makes a great scrum
master a great scrum master.
I just need you to do it in adifferent scope of work now with
a slightly different set ofstakeholders.
(16:43):
So instead of your entire breadand butter being your
engineering teams, your designer, maybe the product person that
you're working with with thoseteams.
I need you now to think about awider range of stakeholders
that include go-to-marketfunctions.
Go-to-market functions meaningsales enablement, doc writing,
(17:03):
technical support, customersuccess all of these team
members that are vital to awhole business's success that,
frankly, engineering doesn'toften hang out with.
I'll just put it that way.
So we changed their jobs toprogram management, and I know
I'm going to hit pause for asecond, because I know that
there's a lot of differentdefinitions of program
management and, depending onwhat company you're at, you
(17:25):
might even see technical programmanagement, which is a slightly
different slant than what I'meven describing.
This is what worked for us.
I still very much believe Iprobably could have kept their
title scrum master, even thoughI changed their role.
But I'm a big believer inpsychology and I think had I not
changed their title, they wouldhave done.
It would have been very hard forthem to have broken their old
(17:47):
habits and to apply new behavior.
And it's been really, reallysuccessful.
And I think one of the coolestthings about it is that it has
really created an endlessopportunity, endless list of
opportunities of what's next intheir careers, because now they
get exposure to so much of thebusiness.
I've had two of my old teammembers who have moved into
product management becausethey've gotten a lot more
(18:09):
exposure into how products arebuilt and they found passion
there.
I've had folks start to exploreother operational type of roles
, like revenue has operationsroles, sales marketing has
operation roles, and those arecareer opportunities they
probably would have never hadthe chance to explore had they
stayed in that scrum masterbubble.
(18:30):
I've even had folks that areexploring chief of staff roles,
helping to run major parts ofour organization, and it makes
complete sense when you stepback and look at it, because
it's running a bunch of specialprojects, getting organized,
creating consistent operatingpractices.
Like it's all the same skills.
It's just I think sometimesAgilists get way too close to
the trees and they forget thattheir skill set can be applied
(18:53):
in a myriad of ways.
Speaker 1 (18:55):
So what did that look like when you started talking
about the new set ofaccountabilities that they were
going to have with this newtitle?
What did that look like fromthe team?
I'm sure they were.
Were they taken off guard?
Were they very?
Speaker 2 (19:07):
I had quite a few that weren't happy with me.
I am proud to say, though, thatwe had a team of, I think, 17.
I could be off again by a fewthere.
Okay, in the transformationprocess, I only had one choose
to leave, and they chose toleave, and they were very, very
(19:39):
honest about what they wanted,and what they wanted was a very
traditional scrum master.
They loved that.
Right, like I said, wasentirely focused on engineers
and maybe a designer, maybe aproduct manager.
Now they were supporting wholeprograms.
So the way we define ourprograms are essentially like
think about it like a productarea, typically a team of teams,
(20:02):
right, so you could, if you'rethinking about like a scaled
agile point of view, like arelease train.
Now, granted, they were small,so, like, I don't want anyone
freaking out and thinking thatwe went from you support one or
two to 20.
It was, they went from one ortwo to maybe three to five, but
it's because they weren't in theweeds, and something
controversial that we did was tohelp give them the capacity to
(20:25):
do that.
We had our engineering managerstake over running daily
stand-ups.
We didn't say that my teamwasn't allowed to go.
They were encouraged to stillgo whenever they possibly could.
But we needed to take theburden of you have to be there
every single day off of theirplate.
And, ironically, if any of themare listening, I don't care,
they still mostly go.
If any of them are listening, Idon't care, they still mostly
go to all of them.
(20:46):
But, for whatever reason, themental burden of oh my gosh, I
have these daily standups for aset of teams every single day.
There's no way I can take onadditional work.
I'm like, no, you can't.
So we moved the day-to-dayresponsibility to the
engineering managers, which alsoupped their accountability and
making sure that the engineeringmanagers knew what was actually
happening with their team.
And then we moved the bulk ofthe responsibility of sprint
(21:08):
planning to our product managers, so they were the ones that had
to make sure backlogs wereready.
We still have varying levels ofexperience in like setting
sprint capacity and velocity andtalking all the math.
A lot of times our programmanagers will still kind of help
with that conversation.
In some cases our engineeringmanagers have learned how to do
(21:29):
that math too and they can leanin on that part, which I know is
again probably controversial.
The one space that we haveprotected is retros.
I do very much, deeply believethat an engineering manager or
product manager should not bethe one leading a retro.
I think it's a skill.
So they still lead all of ourretros.
And then the other bigdifference is that their direct
(21:49):
leadership team changed.
So now we created leadershipteams at that program level.
So we had a product lead, adesign lead, an engineering lead
and then this program manager,and that became their first team
if you're familiar with theconcept of first team and so
they spent a lot of their timethere.
But action-wise,day-to-day-wise, they now had to
(22:10):
not just manage the day-to-dayof these engineering teams,
which was a little bit more onthe engineering manager's plate
now which ones are coming toengineering teams, which ones
are in engineering teams' handsand which ones are coming out of
engineering and needing to moveto business readiness, and so
they're managing a lot more,frankly, amounts of things on a
(22:31):
day-to-day basis.
But the cool thing is that to me, and what I think they really
enjoy about it is, every dayfeels different.
So it's not like, okay, I'm in asprint, I'm going to go do
sprints to daily standup.
Okay, I'm going to talk to myteam and help unblock them on
this thing.
Okay, well, tomorrow's kind ofthe same, oh, the day after
that's a retro, and the dayafter that we have to plan, and
then, oh wait, we just beat thewhole thing again.
(22:52):
This is like really a every dayis very much different based on
what they have, lifecycle and,like I mentioned earlier, it
also is causing them to have tosolve wildly different problems.
How do we enable sales on thevalue of the thing your team
just built, while they don'thave to have every tiny granular
detail of the answer to thatproblem?
(23:13):
They have to now go hunt thatproblem down and they have to
now go work with a differenttype of team to figure out how
do we make sure that all thismoney we just invested building
this thing isn't a completewaste to the business.
So I think that they veryquickly got on board when they
recognized that they just get tosolve different problems now.
Speaker 1 (23:32):
One of the things that stood out to me is the
empowerment that you provided tothem with this decision, and
just it's a small thing, but Itend to just pick up on little
small things and one of thethings that you said was okay,
now, instead of requiring you togo to the daily scrum every day
, or the daily standup, now it'soptional.
And the team's reaction was ohwell, okay, I can't attend every
(24:00):
daily stand up, but then whenyou made it optional and left it
up to them, they were like hmm,I probably do need to go, that
probably is useful for me to doso.
The empowerment of giving thechoice to them, to let them make
the decision, is it somethingthat is valuable to you?
Do you bring value and do youget value from it?
I think just speaks volumes.
Speaker 2 (24:22):
Well, I think it changed how they viewed a lot of
this and I think it reignitedthis idea of how you constantly
evolve something to ensure thatit is still valuable to
everybody involved.
I think when it was just kindof a part of a regular motion,
even though somewhere in theirminds I'm sure they knew that
their job was to constantly makethings better, it's really easy
(24:44):
just to get stuck in that rutof, well, that's what we do and
this is how it happens, and thisis how my team is happy, and so
that's, I think, drove a lot ofthat too is different kinds of
conversations of is this stillvaluable, the way that we're
doing it, and how can we make itbetter?
Speaker 1 (24:57):
Did retros change a lot?
Speaker 2 (25:00):
No, I will say that we are currently in an open
debate with engineeringleadership right now, because we
allow our engineering managersto be in retros, which, I will
admit, is something that I don'tactually like.
But I have chosen not to fightthis fight.
I think it's important to pickyour battles, and that was just
(25:23):
one that I didn't think thereward was worth the battle.
But we're getting to a pointwhere some of our teams are
trying to get creative about howto continue to keep value in
retros.
So, on a good note, I wouldargue that it's coming from a
place of.
We've gotten our teams prettyopen and honest with each other
to where they're having regularconversations about what's
(25:45):
working, what's not working.
So, like we have teams that arecurrently experimenting with
doing retros based on releases,not based on sprints.
So instead of it being everytwo weeks, it's we release quite
frequently.
So it's not like we're saying,hey, you're going to wait three
months or six months to have aretro, but, like when an epic
gets completed, that might beonce a month or once every
couple of weeks.
(26:05):
What changes the value in theretro if we were to focus from
that point of view versusinsisting again that it be every
two weeks?
Speaker 1 (26:13):
And we're going to so I was curious about yeah, yeah,
I was curious about that, abouthow this move to a program
manager kind of broadened thehorizon from a scrum master and
they started asking differentquestions in the retro based on
their based on what they wereseeing, because they weren't
just looking at just the team,they had a much broader view of
(26:34):
the customer, of the problemsand things like that.
Speaker 2 (26:39):
I think the number one thing that it did is it
shifted.
I think there's a lot of theorytalk in the difference between
outputs versus outcomes.
I think there's lots of voicesin the ad industry on this idea,
but for me at least for years Iwas like, okay, I can
understand the idea you'redescribing and I don't know how
to actually do the culturalshift or the to get people to
(27:02):
change behaviors, to to be aboutoutputs and not outcomes, or be
about outcomes not outputs.
See, I can't even get it right.
Um, until we did this, this,that was like a really
unintentional result that we gotwas every conversation shifted
to away from okay, great, youchecked a box of getting this
(27:24):
sprint done or you met yoursprint commitment.
It changed from that to butwhat value does this provide?
How do we know customers willwant this thing and will buy
into it and will adopt it?
It also helps that the companythat I work for is a product
analytics tool, so we areliterally building a tool to try
to get companies to betterunderstand how their tool is
(27:45):
being adopted.
So like a lot of drink your ownchampagne kind of stuff
happening there.
But I don't think we were evenhaving enough of those
conversations until we made thisshift and until we were able to
see the impact company-wide andcustomer-wide, and the fact
that, like, hey, we don't buildjust to build, we build because
we're trying to solve a problem,so how do we know we're solving
that problem?
(28:05):
So I do think we've made thatshift and I'm sure that that
drives different conversationsin those retros, but I see that
driving different questions andconversations in pretty much
every aspect of what we do inthis PDLC, which is really cool
to see.
Speaker 1 (28:22):
Coming from an engineering background myself,
engineers like tough problems tosolve right, and sometimes it's
not about the value, it's abouthow fun is this challenge going
to be to solve?
And we forget that big picturethat somebody is actually going
to be using this and it is goingto it's either going to make
their life better or it's notright.
Speaker 2 (28:42):
Right.
Speaker 1 (28:42):
So that should be why we're doing what we're doing,
not because it's a fun puzzle tosolve, right?
That's a byproduct.
Speaker 2 (28:49):
I mean I will say thanks to AI, because AI is
making plenty of fun puzzles tosolve.
Speaker 1 (28:57):
So, as we're wrapping up here today, jessica, I want
to ask you the strategic movethat you made to transition
scrum masters into programmanagers.
If you had to do it over again,is there anything that you
would do differently?
Speaker 2 (29:12):
Oh, that's such a good question, I'm sure.
Yes, yes, there's always thingswe can do differently.
I think two things pop into mymind right away.
The first one is because of allof the other responsibilities
that we are asking them to takeon that were different from
their typical scrum masterresponsibilities, I do think we
(29:36):
lost track for a while of thesestill critical skill set of
facilitation, and so Ipersonally believe that
facilitation is one of the mostpowerful skills somebody could
have, and I think it's somethingthat you continue to hone over
time and you can continue tobuild.
And so I don't.
I would.
I would love to go back, and weprobably took almost six months
(29:56):
where we didn't, just it wasn'ton the top of the priority list.
It's not that we weren't doing,we weren't doing any of it,
it's just we weren't activelycontinuing to try to build that
skill and and looking at how wecan make it better.
So that's probably one thing,because we then had to kind of
do some reworking after to comeback to it and go hey guys, this
is still a critical part ofyour job.
I still need you to be reallygood at this, especially since
(30:16):
the audiences you'refacilitating are wildly
different.
And when you're facilitating abunch of engineers who, frankly,
have now been years and yearsand years used to a Scrum Master
, that's an easier facilitationaudience.
Then now you're working withall these business partners who
maybe aren't used to having aformal facilitator.
I lost track of that so I wouldhave probably done that better,
and then we did.
(30:36):
It took us a hot minute tofigure out that we needed to do
this.
So have looking back, I wouldhave done it much sooner.
We ended up doing a I don't knowlike an education tour where,
because I was exposing them tomuch more of the business, I
just assumed, kind of what Imentioned at the very beginning
of this podcast that, like,domain knowledge wasn't nearly
as critical, and I still believethat.
(30:57):
But they need to have some kindof base, that understanding of
what each of these departmentsdo.
So we figured out probably toolate and did eventually bring in
, like representatives from eachof these major departments to
come to my team and do a quickoverview of what the department
even did, what they care about,what drove like, what motivates
them.
So, like we, I had a bunch ofscrum masters who understood
(31:17):
what motivates engineers butthey weren't totally clear on
like how do you motivate acustomer success individual, how
do you motivate a salesenablement team member, like
those types of things.
So once we got into that motionof continued education and we
were constantly having peoplecome in and talk to us, that
like really unlocked the valuethat they were able to do.
So looking back, I would haveday one I probably might have
(31:40):
even done it before we formallychanged their jobs.
Looking back on it versus afterthe fact and after a couple
months of struggling.
So probably those are my twothings.
Speaker 1 (31:51):
Jessica, thank you so much for coming on the show.
This has been wonderful.
I've enjoyed talking with youOur audience.
If they want to get in touchwith you, how might they do that
?
Speaker 2 (32:00):
LinkedIn is probably the easiest.
Just my name, Jessica Soroki.
Yeah, that's the easiest.
Speaker 1 (32:05):
We'll put a link in the show notes to make it easy
for everybody.
Jessica, again, thank you somuch for being a guest here on
the show.
Really enjoyed having you.
Speaker 2 (32:13):
No problem, thanks for having me.
Speaker 1 (32:15):
All right, everybody.
That brings an end to anotherepisode of the Agile Within.
We'll see everybody next time.
Thanks for joining us foranother episode of the Agile
Within.
If you haven't already, pleasejoin our LinkedIn page to stay
in touch.
Just search for the AgileWithin and please spread the
(32:39):
word with your friends andcolleagues Until next time.
This has been your host, markMetz.
Welcome to the Agile Within.
I am your host, mark Metz.
My mission for this podcast isto provide Agile insights into
human values and behaviorsthrough genuine connections.
My guests and I will sharereal-life stories from our Agile
journeys, triumphs, blundersand everything in between, as
(00:29):
well as the lessons that we havelearned.
So get pumped, get rocking.
The Agile Within starts now.
Before we dive into today'sepisode, I'd like to take a
moment to thank our sponsor,impact Agility.
Impact Agility specializes intraining and coaching through
(00:49):
scrumorg and proconbonorg,empowering teams with
cutting-edge tools andtechniques.
Their classes are designed todeliver actionable insights,
whether you're a scrum master,agile coach, delivery manager or
organizational leader.
Whether you're a scrum master,agile coach, delivery manager or
organizational leader, at thehelm is president and founder
(01:13):
Matt Domenici, who has guidedover 50 organizations toward
professional agility.
With his hands-on experience,matt helps teams and
organizations take ownership oftheir processes and outcomes,
unlocking their full potentialTo explore free learning
resources, check out theirtraining schedule or book a free
consultation.
Visit impactagilityco Onceagain.
(01:35):
That's impactagilityco.
Well, hey, welcome backeverybody.
This is your host, mark Metz,at the Agile Weather Inn.
I hope you're having anabsolutely fantastic day out
there today.
Our guest for this episode isJessica Soroki.
Jessica, welcome to the show.
Speaker 2 (01:54):
Thanks for having me, mark, super excited.
Speaker 1 (01:56):
Well, jessica is from nearby Atlanta Georgia.
I'm just about four hours eastof her in Columbia, south
Carolina.
So, jessica, if I were comingto Atlanta Georgia for a day,
been there many times, but if Ihadn't been there before, what's
one thing that you would saythat I couldn't miss?
Speaker 2 (02:11):
doing.
I would say you couldn't missthe aquarium.
It's like the number oneattraction, so I don't feel
super unique in suggesting it,but it is super cool.
And I did recently learn thatyou can actually go scuba diving
with the whale sharks, so thatis now newly on my to-do list at
some point is to get in thewater with them, and that's I'm
(02:33):
super cool.
Speaker 1 (02:34):
And you did say whale sharks, not sharks, right?
Speaker 2 (02:38):
Yes, whale sharks, they are very gentle, from what
I understand.
Speaker 1 (02:43):
We both have families and I understand that you can
have like spend-the-nightparties in the aquarium.
Is that right?
Speaker 2 (02:49):
You can have sleepovers in the aquarium, like
sometimes schools will do it oryou can do it privately.
And they actually also have apretty extensive summer camp
program now for like 5 to, Ithink, 12 years old, all about
STEM and getting kids excitedabout the sciences and math and
all that kind of fun stuff.
Speaker 1 (03:08):
That's awesome.
Well, I'll have to say itreally is impressive when you
walk into the aquarium and yousee those whale sharks for the
first time, because you try toprepare yourself for how big
they're going to be, but untilyou see them in person, they're
tremendous.
They are huge.
Speaker 2 (03:24):
We have three little boys five and twin
three-year-olds and we can sitthere for quite some time just
looking at that huge aquariumand watching the whale sharks go
by and all the other things.
And anyone who has little kidsknows that attention spans are
very short, but that keeps theirattention quite long actually.
Speaker 1 (03:42):
Well, I'm a big kid at heart.
I love animals, so yeah, Icould spend all day in the
aquarium and be perfectly happy,all right.
Well, I want to introduceJessica.
She is a Senior Director ofProgram Management and Product
Operations.
Jessica, why don't you tell usa little bit about your role?
Speaker 2 (03:59):
Yeah.
So I figured it might behelpful to give like a little
description of the role but alsomy background.
I was in Agile roles for 12years prior to my current role,
so that would be everything froma scrum master to Agile
consulting and coaching.
I was a professionalfacilitator and professional
(04:20):
speaker for a long time doingthe big conference circuit.
I was an executive coach allthe things.
My current role programmanagement and product
operations for Pendo is kind ofmy next evolution in that role,
which I'm sure we're going toget into all things there.
But product operations the bestthing I can say about it simply
(04:40):
to an agile audience is it islike a souped up scrrum Master
for an entire productorganization.
So their whole job is to makeproduct managers more effective,
minimize wasteful activities,get them focused on all the
creative ideation, buildingproducts things.
Speaker 1 (04:59):
So, leading into that , you and I had a conversation
before this recording and wetalked about the state of Agile,
yeah, and so let's talk alittle bit.
What do you see as the currentlandscape for Agile and for
agility, jessica?
Speaker 2 (05:14):
Yeah, I'm not going to jump on the bandwagon of it's
dying or it's dead.
I don't think it is dying ordead.
I do think that it is less of acraze than it used to be and I
do think that, unfortunately,there's just not a super
consistent success story withagile and corporations.
(05:34):
So when you go from company tocompany large or midsize markets
you just hear really mixedexperiences with it and I think
that because there's not thislike super strong, consistent,
no, when you do agile, you get X, y and Z out of it.
I think executives are still amixed bag of weariness and
(05:55):
buy-in level and because of that, I think that's why it is kind
of in the same state, in thesense that I don't think it's
dead.
I think you have plenty ofleaders out there and plenty of
companies that still get somevalue out of it, but I don't
think it's ever going to go backto the peak that it was.
When you were you couldn't.
You could throw a rock and hita hundred job openings or maybe
(06:17):
that's a little bit of anexaggeration but dozens of job
openings.
It wasn't difficult to find ajob in the agile market,
regardless of what level youwere at.
That's all changed.
There's been some really bigagile forward companies, like
Capital One and a few others,that very publicly cut all, if
not very close to all, of theiragile roles, and the market
(06:41):
right now is really difficult.
My husband just went through ajob hunt recently in agile roles
and senior scrum, master, rtetype of roles and it is really
difficult.
You're getting hundreds ofpeople applying for every
opening out there and it is areal fight because there's just
not nearly the demand that thereused to be demand that there
(07:08):
used to be, so I think it isimportant to delineate.
Speaker 1 (07:09):
There is demand.
It's just not what it used tobe.
Yeah, because that demand usedto be high, we had a large
number of people entering theworkforce.
Speaker 2 (07:16):
Absolutely.
Speaker 1 (07:17):
So now we have a smaller market with more people,
so it's simple supply anddemand right.
Speaker 2 (07:23):
Yeah, absolutely, which is why I don't think it's
dying or dead, because there isstill a demand for it.
There are still companies whosee value and agility and want
to embrace it.
If that weren't the case, Iwould jump on the bandwagon of
okay, it's dying or it's dead.
Everyone, give up and find thenew thing.
Speaker 1 (07:40):
So you and I discussed that companies like
Capital One are doing away withanything that has Agile in the
title.
They just got rid of thosepositions right.
And I think when we werelooking at Agile positions, many
of us as Agilists, we wereleaning back.
And when I say leaning back, wewere leaning back from the
(08:01):
business, from the product, andwe were focused more on how the
sausage is being built, what areour processes like, and not as
much leaning in to the actualbusiness.
So what do you see as domainknowledge?
How important do you feel thatis for Agilis today?
Jessica?
Speaker 2 (08:21):
Yeah, I think my opinion has changed over time.
I used to be veryanti-technical backgrounds when
it came to Agilist, scrumMasters, coaches, and I still,
frankly, if you're hiring orhave Scrum Masters, I still very
much believe that, while beingtechnical in some way can have
(08:42):
some value, in my experiencebrings too much danger to the
conversation and that they wereway too comfortable with what
the engineers are talking about,and I think we all know there's
not a single engineer out therewho wants anybody in a scrum
master, agile role telling themhow or what to build.
So my stance was always likeknow just enough to know what
(09:05):
questions to ask, but don't knowenough to have an opinion on
the answer.
And I don't know that.
That's wildly different.
I will say, like, if we get intolike where I think Agilists
should start looking when itcomes to career, what's next for
them, I do think domainknowledge becomes more important
, but I would still argue thatif you are really good at
(09:26):
operations, process humans, teambuilding, all those types of
things, it really shouldn'tmatter what the context is of
what they are working on.
You should be able to do all ofthose things regardless.
And I think people lean intotoo much domain knowledge when
they aren't as comfortable onsome of those other skills.
That being said, I'm going tocontradict myself a little bit
(09:47):
here and say that, like I dothink you have to have basic
domain knowledge of how abusiness builds products and how
an engineering team buildssoftware.
I think that is important, butI don't know that it has to go
deeper than that.
Speaker 1 (10:03):
I'll just share a frustration of mine here
recently.
So I have been in the job huntmyself, like your husband, and
was applying for jobs, and therecruiters would ask me if I had
banking experience, and myanswer was yes.
And their next question was ohso which bank are you coming
from?
And my response was well, I'mnot coming from a bank.
I have from years past.
(10:24):
I have banking experience, butI'm not coming from a bank.
Oh well, this customer, theywant someone coming from a
banking background directly, andyou know, you know, I think you
sell yourself and so you knowthe customer is always right.
But you're trying to sellyourself and it's like, well,
sometimes you can be so close tothe problem that you can't
(10:47):
really think outside the box.
And that was my angle and I wasunsuccessful at painting that
picture.
But I was like, do you reallywant someone who is in the
banking bubble that maybe youdon't have?
There are other domains outthere.
There are other verticals,other businesses that you could
benefit from.
Wouldn't it behoove you to havesomeone that has a wealth of
(11:10):
experience and not just in yourown little bubble?
Speaker 2 (11:13):
And you're not the only one that experienced that.
My husband had the exact sameexperience.
It wasn't, I don't know,banking, but it definitely was
like insurance was a big one.
Which insurance company are youcoming from?
Those types of things?
I think my hot take here isgoing back to that supply and
demand point we were makingearlier.
I think it has everything to dowith that.
(11:34):
Five years ago, when demand andsupply weren't matching and
there weren't enough people tofill all of the agile roles or
opening, there was a lot moreopenness, I think, to diverse
backgrounds and different pointsof views.
And now, because there's somuch supply and so little
comparative demand, I thinkcompanies are getting into like
really weird behaviors that youjust described of like no, I
(11:57):
need exactly this experience,exactly this background, and
they're probably convincingthemselves that that's the key
to making agile work and that is, I know, means, the key to
making it work.
I will say my current company.
We look at backgrounds, butmainly from like to understand
what speed of organizations youcome from.
So, for instance, like we willlook at resumes when it comes to
(12:18):
like insurance or banking andno offense to anybody in those
worlds, they're typicallyslightly slower moving companies
than a SaaS startup right.
So it's not to say that it's adeterrent, but it does change
some of our questions andinterviews to make sure that
somebody coming from thosebackgrounds into a SaaS startup
type of environment feels likethey can still be successful
(12:39):
because the speed of pace iswildly different and I think
that's okay.
But I think getting reallystuck in know what specific bank
did you come from feelsunnecessary.
Speaker 1 (12:51):
I agree, I agree.
So, like I said, I wasunsuccessful, but I'll continue
to fight the crusade along withyour husband.
There we go.
So, jessica, we talked aboutone dead end road that I have
experienced.
What are some alternative paths, maybe, that we might take in
order to serve companies betterand not be stuck in the?
(13:13):
You know, I'm just going to bea facilitator or I'm just going
to schedule meetings, I'm givingair quotes.
How do we pivot here for theagilist out there?
How do we pivot here for theAgilist out there?
Speaker 2 (13:25):
Yeah, so Pendo, which is where I work.
I've been there for almostseven years and we actually
experienced this need for I hateto use the word transformation,
but essentially this need foran internal transformation.
We have always been an Agilecompany and I really do mean
that Two of our four co-foundersare very, very deeply embedded.
(13:46):
They've always been bought in.
It's never been a fight.
But, all that being said, therecame a point where, even in
that environment, questionsstarted to arise around, like do
we really need this many scrummasters?
What do they really add value?
Like, how do they really addvalue?
Why can't my engineeringmanager just do this meeting
facilitation stuff and keep usorganized and do the math on
(14:10):
sprint velocity and capacity andall that kind of fun stuff?
And so when I heard thosequestions, it was, I think,
about a year into COVID and thatkind of sent like my hairs
raising right, like, oh, I'vebeen down this path before.
I don't want to see big layoffsin this team Like they.
I know that they are highlyskilled.
So we did an objectiveassessment of kind of like how
(14:31):
we were executing against ouragile processes and how we built
products, and what we came upwith was, I think, a really
significant career move for alot of agilists out there.
But what we figured out is thatthe product development
lifecycle is actually a lotbigger than the software
development lifecycle.
The software developmentlifecycle is a piece of the
(14:52):
product development lifecycle,and what the product development
lifecycle has that the otherone doesn't is it has the early
ideation phases, it has customervalidation, it has research,
it's got data gathering, it'sgot experimentation and designs.
It also has, at the other endof it, when the software is done
, being built, how do youprepare a company to launch that
(15:14):
software into customer hands?
How do you make sure that yoursupport organizations are ready,
that your sales team knows howto sell it, that your
documentation is where it needsto be all these different pieces
right.
And so we weren't really goodat either one of those parts.
We were good at the softwaredevelopment lifecycle.
We'd gotten that.
We figured that part out, and sowe made a decision that was
pretty bold and we moved all ofour Scrum Masters from
(15:37):
engineering as Scrum Masters toproduct as program managers and
we partnered them up with theproduct this very small product
operations team that we had atthe time, and the whole point of
that was because we wantedthere to be a single point of
accountability essentially forthat entire product development
lifecycle, and we needed aprocess expert to help us make
(15:59):
that whole product developmentlifecycle much more effective,
much more efficient.
We needed a consistent processacross.
At the point At that time, Ithink we had don't totally hold
me to this but roughly 30 scrumteams, give or take a few, and
so we needed to figure out howto get them all marching in the
same direction, just like wewould.
A software developmentlifecycle, but now for this
whole beginning of idea throughcustomer hands, and so we move
(16:23):
them into program management.
And I will say I didn't love itwhen I came to the team and
said hey, I'm going to changeyour titles and I'm going to
change your job.
I need you, and I kind ofpositioned it from the point of
view of I need you to maintain alot of what makes a great scrum
master a great scrum master.
I just need you to do it in adifferent scope of work now with
a slightly different set ofstakeholders.
(16:43):
So instead of your entire breadand butter being your
engineering teams, your designer, maybe the product person that
you're working with with thoseteams.
I need you now to think about awider range of stakeholders
that include go-to-marketfunctions.
Go-to-market functions meaningsales enablement, doc writing,
(17:03):
technical support, customersuccess all of these team
members that are vital to awhole business's success that,
frankly, engineering doesn'toften hang out with.
I'll just put it that way.
So we changed their jobs toprogram management, and I know
I'm going to hit pause for asecond, because I know that
there's a lot of differentdefinitions of program
management and, depending onwhat company you're at, you
(17:25):
might even see technical programmanagement, which is a slightly
different slant than what I'meven describing.
This is what worked for us.
I still very much believe Iprobably could have kept their
title scrum master, even thoughI changed their role.
But I'm a big believer inpsychology and I think had I not
changed their title, they wouldhave done.
It would have been very hard forthem to have broken their old
(17:47):
habits and to apply new behavior.
And it's been really, reallysuccessful.
And I think one of the coolestthings about it is that it has
really created an endlessopportunity, endless list of
opportunities of what's next intheir careers, because now they
get exposure to so much of thebusiness.
I've had two of my old teammembers who have moved into
product management becausethey've gotten a lot more
(18:09):
exposure into how products arebuilt and they found passion
there.
I've had folks start to exploreother operational type of roles
, like revenue has operationsroles, sales marketing has
operation roles, and those arecareer opportunities they
probably would have never hadthe chance to explore had they
stayed in that scrum masterbubble.
(18:30):
I've even had folks that areexploring chief of staff roles,
helping to run major parts ofour organization, and it makes
complete sense when you stepback and look at it, because
it's running a bunch of specialprojects, getting organized,
creating consistent operatingpractices.
Like it's all the same skills.
It's just I think sometimesAgilists get way too close to
the trees and they forget thattheir skill set can be applied
(18:53):
in a myriad of ways.
Speaker 1 (18:55):
So what did that look like when you started talking
about the new set ofaccountabilities that they were
going to have with this newtitle?
What did that look like fromthe team?
I'm sure they were.
Were they taken off guard?
Were they very?
Speaker 2 (19:07):
I had quite a few that weren't happy with me.
I am proud to say, though, thatwe had a team of, I think, 17.
I could be off again by a fewthere.
Okay, in the transformationprocess, I only had one choose
to leave, and they chose toleave, and they were very, very
(19:39):
honest about what they wanted,and what they wanted was a very
traditional scrum master.
They loved that.
Right, like I said, wasentirely focused on engineers
and maybe a designer, maybe aproduct manager.
Now they were supporting wholeprograms.
So the way we define ourprograms are essentially like
think about it like a productarea, typically a team of teams,
(20:02):
right, so you could, if you'rethinking about like a scaled
agile point of view, like arelease train.
Now, granted, they were small,so, like, I don't want anyone
freaking out and thinking thatwe went from you support one or
two to 20.
It was, they went from one ortwo to maybe three to five, but
it's because they weren't in theweeds, and something
controversial that we did was tohelp give them the capacity to
(20:25):
do that.
We had our engineering managerstake over running daily
stand-ups.
We didn't say that my teamwasn't allowed to go.
They were encouraged to stillgo whenever they possibly could.
But we needed to take theburden of you have to be there
every single day off of theirplate.
And, ironically, if any of themare listening, I don't care,
they still mostly go.
If any of them are listening, Idon't care, they still mostly
go to all of them.
(20:46):
But, for whatever reason, themental burden of oh my gosh, I
have these daily standups for aset of teams every single day.
There's no way I can take onadditional work.
I'm like, no, you can't.
So we moved the day-to-dayresponsibility to the
engineering managers, which alsoupped their accountability and
making sure that the engineeringmanagers knew what was actually
happening with their team.
And then we moved the bulk ofthe responsibility of sprint
(21:08):
planning to our product managers, so they were the ones that had
to make sure backlogs wereready.
We still have varying levels ofexperience in like setting
sprint capacity and velocity andtalking all the math.
A lot of times our programmanagers will still kind of help
with that conversation.
In some cases our engineeringmanagers have learned how to do
(21:29):
that math too and they can leanin on that part, which I know is
again probably controversial.
The one space that we haveprotected is retros.
I do very much, deeply believethat an engineering manager or
product manager should not bethe one leading a retro.
I think it's a skill.
So they still lead all of ourretros.
And then the other bigdifference is that their direct
(21:49):
leadership team changed.
So now we created leadershipteams at that program level.
So we had a product lead, adesign lead, an engineering lead
and then this program manager,and that became their first team
if you're familiar with theconcept of first team and so
they spent a lot of their timethere.
But action-wise,day-to-day-wise, they now had to
(22:10):
not just manage the day-to-dayof these engineering teams,
which was a little bit more onthe engineering manager's plate
now which ones are coming toengineering teams, which ones
are in engineering teams' handsand which ones are coming out of
engineering and needing to moveto business readiness, and so
they're managing a lot more,frankly, amounts of things on a
(22:31):
day-to-day basis.
But the cool thing is that to me, and what I think they really
enjoy about it is, every dayfeels different.
So it's not like, okay, I'm in asprint, I'm going to go do
sprints to daily standup.
Okay, I'm going to talk to myteam and help unblock them on
this thing.
Okay, well, tomorrow's kind ofthe same, oh, the day after
that's a retro, and the dayafter that we have to plan, and
then, oh wait, we just beat thewhole thing again.
(22:52):
This is like really a every dayis very much different based on
what they have, lifecycle and,like I mentioned earlier, it
also is causing them to have tosolve wildly different problems.
How do we enable sales on thevalue of the thing your team
just built, while they don'thave to have every tiny granular
detail of the answer to thatproblem?
(23:13):
They have to now go hunt thatproblem down and they have to
now go work with a differenttype of team to figure out how
do we make sure that all thismoney we just invested building
this thing isn't a completewaste to the business.
So I think that they veryquickly got on board when they
recognized that they just get tosolve different problems now.
Speaker 1 (23:32):
One of the things that stood out to me is the
empowerment that you provided tothem with this decision, and
just it's a small thing, but Itend to just pick up on little
small things and one of thethings that you said was okay,
now, instead of requiring you togo to the daily scrum every day
, or the daily standup, now it'soptional.
And the team's reaction was ohwell, okay, I can't attend every
(24:00):
daily stand up, but then whenyou made it optional and left it
up to them, they were like hmm,I probably do need to go, that
probably is useful for me to doso.
The empowerment of giving thechoice to them, to let them make
the decision, is it somethingthat is valuable to you?
Do you bring value and do youget value from it?
I think just speaks volumes.
Speaker 2 (24:22):
Well, I think it changed how they viewed a lot of
this and I think it reignitedthis idea of how you constantly
evolve something to ensure thatit is still valuable to
everybody involved.
I think when it was just kindof a part of a regular motion,
even though somewhere in theirminds I'm sure they knew that
their job was to constantly makethings better, it's really easy
(24:44):
just to get stuck in that rutof, well, that's what we do and
this is how it happens, and thisis how my team is happy, and so
that's, I think, drove a lot ofthat too is different kinds of
conversations of is this stillvaluable, the way that we're
doing it, and how can we make itbetter?
Speaker 1 (24:57):
Did retros change a lot?
Speaker 2 (25:00):
No, I will say that we are currently in an open
debate with engineeringleadership right now, because we
allow our engineering managersto be in retros, which, I will
admit, is something that I don'tactually like.
But I have chosen not to fightthis fight.
I think it's important to pickyour battles, and that was just
(25:23):
one that I didn't think thereward was worth the battle.
But we're getting to a pointwhere some of our teams are
trying to get creative about howto continue to keep value in
retros.
So, on a good note, I wouldargue that it's coming from a
place of.
We've gotten our teams prettyopen and honest with each other
to where they're having regularconversations about what's
(25:45):
working, what's not working.
So, like we have teams that arecurrently experimenting with
doing retros based on releases,not based on sprints.
So instead of it being everytwo weeks, it's we release quite
frequently.
So it's not like we're saying,hey, you're going to wait three
months or six months to have aretro, but, like when an epic
gets completed, that might beonce a month or once every
couple of weeks.
(26:05):
What changes the value in theretro if we were to focus from
that point of view versusinsisting again that it be every
two weeks?
Speaker 1 (26:13):
And we're going to so I was curious about yeah, yeah,
I was curious about that, abouthow this move to a program
manager kind of broadened thehorizon from a scrum master and
they started asking differentquestions in the retro based on
their based on what they wereseeing, because they weren't
just looking at just the team,they had a much broader view of
(26:34):
the customer, of the problemsand things like that.
Speaker 2 (26:39):
I think the number one thing that it did is it
shifted.
I think there's a lot of theorytalk in the difference between
outputs versus outcomes.
I think there's lots of voicesin the ad industry on this idea,
but for me at least for years Iwas like, okay, I can
understand the idea you'redescribing and I don't know how
to actually do the culturalshift or the to get people to
(27:02):
change behaviors, to to be aboutoutputs and not outcomes, or be
about outcomes not outputs.
See, I can't even get it right.
Um, until we did this, this,that was like a really
unintentional result that we gotwas every conversation shifted
to away from okay, great, youchecked a box of getting this
(27:24):
sprint done or you met yoursprint commitment.
It changed from that to butwhat value does this provide?
How do we know customers willwant this thing and will buy
into it and will adopt it?
It also helps that the companythat I work for is a product
analytics tool, so we areliterally building a tool to try
to get companies to betterunderstand how their tool is
(27:45):
being adopted.
So like a lot of drink your ownchampagne kind of stuff
happening there.
But I don't think we were evenhaving enough of those
conversations until we made thisshift and until we were able to
see the impact company-wide andcustomer-wide, and the fact
that, like, hey, we don't buildjust to build, we build because
we're trying to solve a problem,so how do we know we're solving
that problem?
(28:05):
So I do think we've made thatshift and I'm sure that that
drives different conversationsin those retros, but I see that
driving different questions andconversations in pretty much
every aspect of what we do inthis PDLC, which is really cool
to see.
Speaker 1 (28:22):
Coming from an engineering background myself,
engineers like tough problems tosolve right, and sometimes it's
not about the value, it's abouthow fun is this challenge going
to be to solve?
And we forget that big picturethat somebody is actually going
to be using this and it is goingto it's either going to make
their life better or it's notright.
Speaker 2 (28:42):
Right.
Speaker 1 (28:42):
So that should be why we're doing what we're doing,
not because it's a fun puzzle tosolve, right?
That's a byproduct.
Speaker 2 (28:49):
I mean I will say thanks to AI, because AI is
making plenty of fun puzzles tosolve.
Speaker 1 (28:57):
So, as we're wrapping up here today, jessica, I want
to ask you the strategic movethat you made to transition
scrum masters into programmanagers.
If you had to do it over again,is there anything that you
would do differently?
Speaker 2 (29:12):
Oh, that's such a good question, I'm sure.
Yes, yes, there's always thingswe can do differently.
I think two things pop into mymind right away.
The first one is because of allof the other responsibilities
that we are asking them to takeon that were different from
their typical scrum masterresponsibilities, I do think we
(29:36):
lost track for a while of thesestill critical skill set of
facilitation, and so Ipersonally believe that
facilitation is one of the mostpowerful skills somebody could
have, and I think it's somethingthat you continue to hone over
time and you can continue tobuild.
And so I don't.
I would.
I would love to go back, and weprobably took almost six months
(29:56):
where we didn't, just it wasn'ton the top of the priority list.
It's not that we weren't doing,we weren't doing any of it,
it's just we weren't activelycontinuing to try to build that
skill and and looking at how wecan make it better.
So that's probably one thing,because we then had to kind of
do some reworking after to comeback to it and go hey guys, this
is still a critical part ofyour job.
I still need you to be reallygood at this, especially since
(30:16):
the audiences you'refacilitating are wildly
different.
And when you're facilitating abunch of engineers who, frankly,
have now been years and yearsand years used to a Scrum Master
, that's an easier facilitationaudience.
Then now you're working withall these business partners who
maybe aren't used to having aformal facilitator.
I lost track of that so I wouldhave probably done that better,
and then we did.
(30:36):
It took us a hot minute tofigure out that we needed to do
this.
So have looking back, I wouldhave done it much sooner.
We ended up doing a I don't knowlike an education tour where,
because I was exposing them tomuch more of the business, I
just assumed, kind of what Imentioned at the very beginning
of this podcast that, like,domain knowledge wasn't nearly
as critical, and I still believethat.
(30:57):
But they need to have some kindof base, that understanding of
what each of these departmentsdo.
So we figured out probably toolate and did eventually bring in
, like representatives from eachof these major departments to
come to my team and do a quickoverview of what the department
even did, what they care about,what drove like, what motivates
them.
So, like we, I had a bunch ofscrum masters who understood
(31:17):
what motivates engineers butthey weren't totally clear on
like how do you motivate acustomer success individual, how
do you motivate a salesenablement team member, like
those types of things.
So once we got into that motionof continued education and we
were constantly having peoplecome in and talk to us, that
like really unlocked the valuethat they were able to do.
So looking back, I would haveday one I probably might have
(31:40):
even done it before we formallychanged their jobs.
Looking back on it versus afterthe fact and after a couple
months of struggling.
So probably those are my twothings.
Speaker 1 (31:51):
Jessica, thank you so much for coming on the show.
This has been wonderful.
I've enjoyed talking with youOur audience.
If they want to get in touchwith you, how might they do that
?
Speaker 2 (32:00):
LinkedIn is probably the easiest.
Just my name, Jessica Soroki.
Yeah, that's the easiest.
Speaker 1 (32:05):
We'll put a link in the show notes to make it easy
for everybody.
Jessica, again, thank you somuch for being a guest here on
the show.
Really enjoyed having you.
Speaker 2 (32:13):
No problem, thanks for having me.
Speaker 1 (32:15):
All right, everybody.
That brings an end to anotherepisode of the Agile Within.
We'll see everybody next time.
Thanks for joining us foranother episode of the Agile
Within.
If you haven't already, pleasejoin our LinkedIn page to stay
in touch.
Just search for the AgileWithin and please spread the
(32:39):
word with your friends andcolleagues Until next time.
This has been your host, markMetz.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!