March 27, 2025 • 37 mins
In this episode of the Scrum.org Community Podcast, Dave West and PST Andy Brandt explore the state of Agile transformations and the shift toward the Agile Product Operating Model (APOM) as featured in their recently written whitepaper. While Agile has been widely adopted, challenges like misalignment between business strategy and technical execution persist. Andy shares how focusing on products instead of work and starting small with one team can drive meaningful change. They discuss the role of AI in enhancing productivity, the importance of organizational alignment, and how executive commitment can lead to spectacular results. Tune in to learn how to move beyond Agile transformations and embrace a product-first mindset!
Referenced whitepaper: Moving Beyond Agile Transformations: Leveraging the Agile Product Operating Model
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Lindsay Velecina (00:00):
Music. Welcome to the scrum.org community
(00:04):
podcast, a podcast from the homeof Scrum. In this podcast, we
feature professional scrumtrainers and other scrum
practitioners sharing theirstories and experiences to help
learn from the experience ofothers. We hope you enjoy this
episode.
Dave West (00:20):
Hello and welcome to the scrum.org community podcast.
I'm your host, Dave West, CEOhere@scrum.org today's podcast
is part of our agile productoperating model series. Today,
we're going to discuss therecently published paper moving
beyond Agile transformations,leveraging the Agile product
(00:41):
model. And I'm really lucky tohave the author of the paper,
Andy brand, PST andOrganizational Change Guru to
talk about his motivations inwriting the paper, and really
that to really lean into what isthe state of Agile
transformations. Welcome to thepodcast, Andy,
Andy Brandt (01:04):
hi, hi, thanks for having me, Dave. Glad to be
talking to you again, talkingwith you again, about this
topic, because we talked a lotalso when we were working on the
paper. Yes,
Dave West (01:15):
we did talk a lot, and let's hope we don't bore our
listeners, because I'm sure wedid talk for hours and hours
about this. And you know, yourexperiences in the Agile
transformation world and and howyou saw those transformations
really, were really interesting,because very similar to what I'd
(01:36):
seen in the US and the worldwith respect to that. So before
we jump into the white paper,Andy, you know, let's start with
the landscape or context ofAgile transformations. So what's
your take on the state of playon Agile transformations? What's
happening?
Andy Brandt (01:56):
So I think that they are mostly a thing of the
past. So whoever wanted tointroduce agile into their
organizations, into theircompany, they have already done
that. And I would say that thisbig wave was around 2017 maybe
till 2021 maybe 22 for somecompanies. So, but if I, if I
(02:24):
encountered Agiletransformations underway in 2022
it was mostly something like asecond take. So is the second or
third time we tried to do thisbecause the first time didn't go
as well. We didn't get theresults we wanted. So we are
trying it again. But I would saythat the other transformations
are largely done. And what doyou
Dave West (02:45):
think in terms of the outcomes? You know, I've seen
lots of these Agiletransformations happen over the
last 10 years, and I've got,I've got a feeling what the
outcomes are on in in average,obviously, there's outliers on
both ends. But what do you seein terms of, you know, the
success, the value that they'vegot, that organizations have got
(03:08):
out of Agile transformations.
Andy Brandt (03:10):
So I think that they got quite a lot of value,
because in many places, theseefforts succeeded in creating,
for example, cross functionalteams. And there is just one
memory just just just pluggedinto my mind about that was,
like, 15 years ago, or maybe,yeah, that was, I think, 2011 I
(03:34):
was called to talk about agile.
That was 2011 in a large bankand, and I don't remember much
from that event. It was a verylarge event of large auditorium
in the HQ with like 200 peoplethere. And there were two
departments present, largely theDepartment of software
(03:54):
engineering and Department ofquality assurance. And as part
of my talk, I was responding toquestions from the audience,
which were coming on small slipsof paper. And I remember just
one of those questions, and itwas like this, I understand that
now, with agile, we'll have towork more closely with them, but
(04:15):
we'll have to also sit togetherwith them, okay, so, and this
showed the depth of culturaldivide between those two groups.
Now it's unthinkable that divideis largely gone. We don't have
totally separate departments ofquality assurance and software
(04:36):
development. That's one exampleof the change that happened so
we have more cohesive teams. Andalso I feel that we we
concentrate so much onprocesses, on Scrum, etc, but I
think there is also lots ofimprovement when it comes to the
craftsmanship of buildingsoftware. A lot of that has
improved over the past 15 yearsor so. But part of that is
(04:59):
thanks to tooling, but much ofthat is again, thanks to
efforts, and also thanks toagile. The sole thing that you
have to have something donefairly often. And again, it's
not so that all teams that saythey do Scrum, they actually
have something done every twoweeks, which is the predominant
splint length, by the way, butstill, they have something done
(05:21):
more often that they had in thepast, and that kind of forced
improvements in craftsmanship.
So I think there's lots of lotsof doubt. And also we have
created quite a lot of ScrumMasters, adjunct coaches, whole
departments of way of workingand and, I mean, again, some,
(05:44):
some are saying that they arenot as valuable, or maybe they
shouldn't be there asdepartments or whatever. But
basically, what we createdcreate a whole body of people
who care about the process andabout improvement and about
getting better in theorganizations, and they are,
they are still there, in asense, right? So those are those
(06:06):
things that, on average, worked,yeah, yeah,
Dave West (06:11):
I would completely agree. I think the, you know, 20
years ago, 15 years ago,delivering product and
predominantly software. Butdelivering software product was
incredibly hard. Delivering theprocess was incredibly
complicated. We were talkingabout things like CMMI. We were
(06:33):
talking about, you know, Kokomoand things like that. And I
think over this last 15 years,what I've seen is that delivery
has definitely improved, crossfunctional teams, particularly
with business analysis, testing,development, maybe UX have kind
of come together. Maybe UX,that's a whole nother debate and
(06:56):
a start, and are effectivelydoing, doing work together,
which, which would have been,you know, I remember my first
job, and you're a little bityounger than me, but you can
probably attest to this, I builtcode. There was a whole
different room where peopletested it, and they weren't very
nice people. Actually. They justkept finding problems with my
(07:17):
code, which I didn'tparticularly like, at least now
they're focused workingtogether, which is a, which is a
huge thing, but, but I stillsee, and maybe, maybe you don't
see this, but, or maybe you do.
In fact, I think this was the,the sort of premise of the
paper, the that there's still alot of these teams are still
(07:39):
working on work. They're notworking on value. They're not
aligned to innovation. There's amassive gulf between business
strategy and technical delivery.
They they're sort of going inthe they're going really
effectively, but not necessarilyin the right direction. They're
(08:03):
building things that peopledon't want. They're taking an
alternate amount of time to dothat. That's that is has not
changed because of Agiletransformations. Do you agree?
Andy Brandt (08:14):
Yeah, I think it's slightly changed. It's slightly
changed, but it changed. Iwouldn't say it's not enough
what has changed, because whatI'm saying slightly changed. I
have two things in mind. One isthe companies, the
organizations, or maybe parts ofthe larger organizations, that
you call the outliers, wherethey change really deep around
(08:38):
deep and was profound, but theyare a minority. And I would like
to make this I would digress abit, but I think it's it's
normal. It's something to beexpected when we change and when
we introduce change, and maybethat, that's another article
(09:00):
that I have in on my mind. Butwhen you change, when you
introduce change in the way wewere doing with Scrum and Agile,
we were trying and we werelooking at the best companies
and best teams and mostproductive teams and hyper
productive teams, etc. Well,average teams are average. They
cannot ever be hyper, hyper. Itwas always a minority, so it
(09:23):
couldn't hope. And no, no onecan hope really, unless they
take really drastic measures toreally become from from becoming
low average, they to jumpsuddenly to being one of the top
performing outliers. I'm notsure that. I don't think it's
even possible, but what ispossible is moving from being a
(09:49):
low performing average to higherperforming average, what I call
the 5% difference. But that 5%difference might be difference
between going down and going.
Slightly up, and that's a wholelot of difference. So that was
to be to a certain degree to beexpected, but the organizations
did not get out, and I'm gettingback to the main topic, they did
(10:10):
not get out from the coreproblem that we all have, which
is we are trying to do too much,much more than we are capable
of. And I'm saying we all haveit because it's a human problem.
We have the same problem in ourlives that we're trying to grasp
too much, but in our lives,there are kind of hard limits
that we can see or even feel.
(10:34):
And in a large organization, ifyou are an executive, a CEO or
someone of this kind, it's mucheasier to fall into that
illusion that we can doeverything, because almost no
one will say no to you. And theend result of that is that you
have an anti pattern that I seerepeatedly in organization, is
that they have like 100initiatives open, and how many
(10:59):
people are working on on thoseproject well, 25 right? I'm
exaggerating slightly, but, butthis is this kind of
relationship. We have manyprojects, initiatives, all kinds
of names for different types ofwork, and that work usually cuts
across different technologies,different systems and different
(11:21):
teams. And one, one person thatI talked to, one one manager and
at the bank, he used this jaranalogy. He said that our teams
are like this jar that is fullof sand, and there is no place
to stick big stones, where inbig stones, he meant products.
And this leads to this, to thisproblem that so we have agile
(11:43):
teams. We have we are deliveringmore often. We are better
technically. We are bettercraftsmen. However, we don't
have spectacular results. Andhow do you achieve spectacular
results? Well, but by focusing,you cannot be spectacular in
everything. You have to focus onsomething. So if you bowl that,
(12:03):
if you kind of transfer thatinto an organization, I would
say that teams have to befocused on products. And that's
the biggest problem right nowthat we don't have. I mean that
the whole work is not cut intoproducts properly. And secondly,
that those teams are not reallyfocused on those products, and
this is what we are trying toaddress with apon, I think
Dave West (12:27):
it's interesting. You sort of highlighted something
that I don't think is obviouswhen you think about moving to a
product model, but it'ssomething that Dow Fernandez, ex
CIO delivery lead of some largefinancial institutions, when he
was introducing productoperating model or a product
(12:49):
model to those organizations, hesaid the most important and most
powerful thing that it gave himand his organization, his
delivery organization, was theability to say no, and which
sounds incredibly negative, andyou're like, my god, the last
thing you want is something thatcan say no. But he said because
we said no, we said yes, so muchmore. I was like, Okay, now, now
(13:14):
hang on. I'm now going around incircles. He goes because we
actually had a road map for ourfor our products, and the teams
were aligned to those products,and they weren't continuously
changing focus, and they weren'tcontinuously, you know, context
switching and connecting anddealing with dependencies. And
everybody knew it gave us theability to do a lot more, but it
(13:39):
gave us also the ability to notstart a lot more at the time,
you know. And I thought that wasa really interesting
perspective, that that that issomething that his agile teams,
and obviously he was atFidelity, who were the what
second or third company ever inthe world to do, Scrum and, and
(13:59):
I thought, you know, I thoughtthat was a really, really
interesting, interesting pointof view. No, so, alright. So the
alright. So we've got thischallenge. You've got agile.
Transformations have happened orbeen happening, and maybe
they're still happening in yourorganizations. And sometimes
these things are big and long,so we're not judging here. We
(14:22):
don't do any of that, but thevalue that you're getting, which
is significant, could be so muchmore with this idea of a palm.
So talk a little bit about theAgile product operating model
from your perspective, that's
Andy Brandt (14:40):
also well, so from my perspective, is mostly, maybe
I wouldn't say mostly, becauseas we, as we worked on this
model, and we are working on itright now, I see that there are
different perspectives on that,but, but from my perspective,
from where I see it, so to say,I would say that how to manage a
product is an. Already solvedproblem. We already know how to
(15:02):
do that by saying we I'm sayingthe community at large. There
are books about it, there arepeople who have experience in
it. There are training courseson how to be a product owner,
product manager, or however youcall it, on different levels of
competence. So we know that. AndI'm not saying that it's easy,
but there is this body ofknowledge. However, the key
(15:25):
problem seems to be that thereare no real product owners
really managing the products.
And you said about contextswitching, we are kind of forced
to context switch, in a sensethat we have to adjust our
products to the changing marketfaster and faster and faster. So
for example, strategy now issomething two years off and not
10 years off, but still, it'sdone better when there is
(15:49):
someone who makes decisionsquickly, but they are within the
context of the product that theyactually really own and don't do
that alone, then they own itwith their team. And from time
to time, that can change, in asense that this whole team, and
this whole team with the productowner, maybe gets another
product or starts towardssomething else, if that product
is not being developed anymore,or maybe it's not needed
(16:13):
anymore, but, but still, it's alonger stretch, right? So we
deal with instability, but beingmore stable, it's something like
this, no, yes, problem that youyou mentioned, or I will say
that again. So yeah, we getstability, but we also deal with
change better. And it's likethis, yes, no, paradox that you
(16:38):
mentioned, right? So, so I seeit as a problem of how together,
and how together is mostly howwe convince people who are
running those businesses, andthey are running those
businesses in the context of oursocio economic system where they
have to deliver profits and theyhave to be rising every year.
(16:59):
How we convince them that theway to get there and to get
those spectacular results theycrave is to give more of the
organizational power that theyhave in those teams to actually
developing products, how toconvince them that it's better
to say no to many initiativesand say yes to some well
(17:22):
strategically chosen product.
And again, because we had thoseAgile transformations, because
we have agile teams, thisstrategic commitment doesn't
have to be long term. It can be,I don't know, for a quarter, and
if, after a quarter they feel aproduct makes no sense, or
(17:44):
investment in continuinginvestment makes no sense, it's
easy to switch to somethingelse. So how to get them to view
the organization, not to thelens of ongoing work, projects
initiatives, but through thelens of, okay, we have products,
and we develop products. And ofcourse, we have ongoing work as
well, but at least some part ofour power, which is manpower,
(18:10):
which is capital, is devoted todeveloping products. And that's
an organization, organizationalchange problem. And again, as we
are talking right now, it justoccurred to me that this all
happens at a crucial moment,because right now we are in the
(18:31):
midst of artificial intelligencerevolution, and I'm also very
deep into that. And when itcomes to software development,
it's a revolutionary technology.
It increases the effectivenessof teams well from 30 to 70%
depending on whom you ask. Buthaving used those tools and
(18:52):
using those tools myself, I seehuge change over the last year,
and it will just increase now.
Why I'm mentioning that? Becausethis is another kind of
temptation for the managers.
Okay, why bother with that? AIwill do everything that I want,
and no, even AI won't do all theinitiatives and all the work
(19:15):
that you do that it is this,this, this problem of having the
jar with stones and sand, itwon't go away. Yes, the job will
be bigger, but the problemitself won't go away. So while
organizations will surely investin this, in that technology, and
then I'm very much for that, andI support that, and I will even
(19:36):
be helping organizations dothat, I still believe that they
have to focus on well selectedproduct portfolio, and that's
the main challenge. I mean, themain challenge actually
convincing the CEOs, CEOs andother executives, that this is
the right way to go.
Dave West (19:58):
I think AI, it's really. Interesting. You brought
up AI. I agree that AI and thistechnology is, I mean, it's,
it's at the level of a print theprinting press, you know, in
terms of its potential impact insociety. I actually was using it
(20:18):
yesterday. I'm not very good at,you know, accountancy and
planning and forecasting and allthat stuff. And so I took it, I
took my data, and I threw it inand asked it some questions. And
I wouldn't say it was perfect,but it helped me make some
decisions about, you know, wherecertain products are going, etc.
But the key to it is thatcontext and the problem that AI
(20:44):
suffers from, and we've done alot of experiments like you
have, is, if you give it a muchbroader context, then the value
of the answers that it gives youand the solutions that it
provides are less valuable. Thegreat thing about this boundary
that we're calling product isit's customers, stakeholders,
value. You know, it's aclassical model right of a
(21:10):
context that makes sense, whichthen providing that context and
those boundaries allows AI to dosome amazing things, to increase
the power of the solutions it'sit's creating. You know, I think
that the the the alignment toproduct in an organization,
(21:31):
coupled with the use ofdisruptive technology like AI
will, I mean, potentially coulddo amazing things. Obviously,
you have to pick the rightproducts. That's a choice thing,
and you've got to make somedecisions about where value
lies. But if you, if you dothose two things, I think the
sky's the the limit really. So Icompletely agree,
Andy Brandt (21:55):
okay, to you to use your printing press analogy. It
is as hard now as it was then,to write a valuable, Wise Book,
because it starts with withhaving something to share. And
you can you back then you use,probably quail pen and stuff
like that. And right now you canuse open AI to draft it with you
(22:19):
and polish your language, butstill, you have to have some
idea what you want to have tohave something to say,
basically, right? Becauseotherwise it will be low
quality. So what the printingpress changed is that it's much
easier to then bring it to tothe users of books or to the
readers. And ebooks make thateven easier right now. So going
(22:43):
back to the core problem, thecore problem will always remain,
as long as we are in a limitedreality is that you cannot do
everything, and you have toconcentrate your efforts in
order. I mean, the question is,what do you want? Do you want to
prolong the existence of yourorganization as it is now, or do
you want spectacular results?
And I'm kind of quoting thisspectacular results is, is
(23:04):
something that one board memberdemanded from his people and,
and I think it's a fair demand.
I mean, you are doing thisextraordinary change, you have
those motivated teams. Where arethe results? It's a fair
question. However spectacularresults come from concentration
(23:25):
and focus, and it has been soalways, and I don't think any
kind of technology can everchange that. Yeah, so, so this
is the I mean, and I want tounderline that the apom is
something more than that,because we have been working on
that and discussing amongst thePSDs that are working on this
(23:46):
model. So there is, there arestill those problems, how to
manage products, how to organizecross product work, etc. But
from maybe that's my maininterest. That's why I'm so
focused on this. It's okay, buthow do you first get the
company's management to actuallyrealign much of their resources
(24:10):
around certain specific productsin a product portfolio that it's
not too large for the resourcesto be spread to think to make
any difference
Dave West (24:22):
and and that is the I want to say, $64,000 question. I
guess when that saying came out,$64,000 was a lot of money. Now
it's not, maybe as much. Butthat is the fundamental
question. And from what I'veobserved, the best way of doing
that is to start doing it andand start with one product, and
(24:45):
then incrementally add anotherand then another and start doing
that. The the message of this isthe other thing that Agile
transformations, I think, gotwrong. And I you know this is
going to sound very grandiose.
And and please shoot me down.
Andy, if I'm if I'm soundinglike I'm preaching here is that
they assumed, one that theimplementation of agility would
(25:09):
be done in a very sequentialwaterfall way. The other thing
is they assumed that all teamswould be agile, but they would
all kind of do it the same way.
They would have the sameunderlying agile operating
model, and I don't believe that.
And what I've observed isdifferent products require
(25:30):
different cultures, they requiredifferent organizational models,
they require differentincentives. They require now,
they might not be grassdrastically different from the
other products, but, but theability to own, I always thought
there was an irony when we saidthat the people that own the
scrum process that youimplement, because it's a
(25:52):
framework, are the teams, butwe're going to tell you how to
do it. And I thought there wassome irony in these Agile
transformations, telling peopleto become agile, you know,
because of the you know,ownership, whereas I do believe,
if you can empower the productteams and the leadership around
the product to take ownership ofhow they work, how they're
(26:14):
incentivized, how they'realigned, what, what the you
know, the roadmap, thetechnology roadmap, the business
roadmap, the operationalroadmap, the value model, they
take ownership of those things.
I think I honestly you talkabout spectacular results from
my experience, having done a fewstartups, the most spectacular
(26:34):
results we ever achieve is wheneverybody's aligned and owns the
things that they're working on.
And, you know, and obviously, AIand other technology can,
really, can really, can reallydrive that. So I guess to answer
your question, even though Imeant to be asking the
questions, I guess start oneproduct at a time. So what? What
(26:57):
you know, listeners, you know
Andy Brandt (27:00):
this is interesting, because when you
talk to companies, when youtalked about what were their
experiences, quite a fewcompanies have an experience of
this kind that for some reason,usually that was CEOs pet
project or something like that.
They did really set these thingsupright. So they set aside a
(27:20):
team and gave that team aproduct and let that team run
with it. And quite often, thatended in a success, larger or
smaller, depending on how bigthe market opportunity were and
other factors. However, it kindof worked. What is interesting
is that most often no one hadthe idea, okay, let's repeat
(27:43):
that with three products, ormaybe with five product next
time, right? So I know at leastone such project that ended and
this team being spun off as aseparate company, which is an
okay business decision, but whynot to try and repeat that
again, right? So,
Dave West (28:05):
yeah, I've seen that so many times. It's like when I
used to go into organizationsand and I said, How long does it
take you to deliver software?
And they said, Oh, 12 weeks. Andsaid, so when you have a
production failure, it yourproducts are out for 12 weeks.
Oh no, no, we can deliver inminutes if there's a production
problem. So you can deliversoftware in 12 minutes, or
(28:26):
whatever they say. Oh yes, butnormally we don't. I was like,
Well, how do we make the normnot how do we make the norm the
opposite. And there was, like,what, we can't do that. Why?
Well, because, you know,obviously using the best people.
So you're saying the otherpeople aren't the best. How do
we make them the best? Well, no,no. Well, we create an
(28:48):
environment around them wherethey can make choices and make
decisions. You're telling me youdon't do that for your normal
Well, we could do that. And itwas, it's just always
interesting as you unpack, youknow, the the organizational
bureaucracy that has there'sevolved for good reason to make,
you know, but at the end of theday, it's, it's about choices,
(29:11):
and it's about trust, and it'sabout support, you know, and you
get those three things in place,which I think are fundamentals
to the to a POM to the Agileproduct operating model, using
evidence to make those choices,using evidence to provide the
support you know and and fix theproblems and make those you know
(29:32):
right choices. I think that atthe end of the day, you can, you
can do amazing things. So ourlisteners, you know, we have to
keep this short, and I couldtalk to you Andy, as we've
proven many very late nights foryou, we have, we have burned the
oil talking about this stuff.
(29:55):
Our listeners, you know, maybeat many different levels in an
organization, maybe. Some ofthem are practitioners working
in Agile teams that have beenthrough an Agile transformation.
Maybe we've got some leaderslistening. What would be the
advice for them about a palm andthe to leverage this Agile
(30:15):
transformation and and to reallytake it to the next level? What?
What can they do next?
Andy Brandt (30:21):
I would say, start with the first product. So
define, well define a product.
And this is, this can be hard inits own right, because by a well
defined product is also hastechnological implications,
which means creating a productthat has as few hard
dependencies as possible, andgive that product to a team, or
a group of teams, a formation,as we call it, with a product
(30:44):
owner, and let them run withgeneric or general business
goals, like a certain number ofusers, conversions, revenue,
whatever, and see how that playsout. And obviously choose a
product that that makes sense,right? So a product that really
would appeal to your customerbase, etc, and see how that
(31:08):
plays out if you can get becauseit's much easier to get your
executives, whoever, has thepower to give green light to an
experiment like that and keepthat light, that green light on
for long enough period for thatto have any to bear any fruit.
(31:29):
It's much easier to get such acommitment for one product than
for creating a product portfolioof 40 products are 40, it's way
too many. But like 20 products,and having quarterly reviews of
those product portfolios, etc,it's much easier to get a
commitment for one product, for,I don't know, a year and and,
(31:50):
and then proving that this canwork. And what is important that
it can work here, not somewhere,somewhere else in another
company, somewhere else inanother country, not here.
That's an important proof. Andby the way, this is how Agile
transformations got started. Isthat somewhere some people
(32:11):
established a few Scrum or agileteams, and they started to be in
some aspects, better than therest, and it got someone's
attention. That's how it gotstarted, before we had all the
marketing going, before webefore the large consulting
company started talking aboutthat to clients, etc. Before
(32:33):
that, it started like this. Soyeah, that's what I would
recommend. Start
Dave West (32:42):
with a product, and it's a natural, you know, just
to re echo the white paper, it'sa natural evolution of your
agile approach. It really is.
What you're doing is you'rebasically changing the focus of
the team from a work backloginto a product backlog, and
(33:03):
really bring in the business,the people that are ultimately
stakeholders of this, thisproduct closer to that, and
empowering some sort of productowner, Product Manager, to drive
this product into the market andto deliver the results. Might be
an internal product, might be anexternal product, but deliver
(33:26):
the results that the vision andthe dream and the plan are
aspiring to. But I think it's aI think everybody has that
ability to make this change. Andthat's the other great thing
about a palm right, is thatAgile transformations,
particularly at scale, were likethese huge things. What we're
(33:49):
actually saying is get a team,or maybe a couple of teams, if
it's a slightly bigger product,focus them on it. Get a road
map, get a business map, get aROI, build those, build those
OKRs, or those goals, and thenform that and then focus it on
the problem at hand and let themgo. And then review it
(34:11):
continuously and see how itgoes.
Andy Brandt (34:18):
Right. And if it's a new product I would highly
recommend to start with one teamand many.
Dave West (34:24):
Oh, yes, so would I there is a fallacy or a sort of,
you know, if you the idea thatif you throw 100 people at a
problem, you get it, you know,10 times faster than 10 people?
No,
Andy Brandt (34:42):
it's worse. It's worse than that, because those
people have to do something. Soif there is not enough work
coming from the product owner,they will invent their own work,
which will basically meandeveloping something according
to their vision. How the productwill evolve in the future, which
(35:02):
usually ends up, in all that,having to be reward or holding
the teams back in the future. Soit's so much better to start
with one team if you arestarting with a new product,
small
Dave West (35:16):
is definitely the way to go. It is true that having
lots of teams from day one,particularly on a new product,
is a as a recipe for disaster,usually, unless there are
actually multiple products andthere's a clearly understood
this, you know, separationbetween them, which is, which is
really, really good. Andy, thankyou for spending the time today.
(35:39):
I've really enjoyed listening toyour experiences around the
Agile product operating modeland talking about your white
paper, moving beyond Agiletransformations, leveraging the
Agile product operating model.
Andy Brandt (35:57):
Thanks. Thanks for having me for this discussion in
the scrum.org podcast. So firstfor me, so you know, oh, well,
Dave West (36:07):
that's always that's always good, that's always good.
I'm glad. Finally we got,managed to get you on and
listeners, thank you forlistening today to the scrum.org
community Podcast. Today, we'relistening to Andy Brandt PST and
organizational change experttalk about his motivations in
writing the paper, moving beyondthe Agile transformations,
(36:27):
leveraging the Agile productoperating model. Hopefully it's
been as enjoyable for youlistening as it has been for me,
participating. I think the onemessage that came out was this
is a great way of really takingthose Agile transformations and
the benefits you've got andaligning it to the problems of
(36:50):
the future and to the outcomesthat the company seeks the
strategy is driving to, andreally letting it go and and AI
is just going to increase thatleverage that you can that you
can deliver the value from so Ithink that was a great message
from today's podcast. And if youliked what you heard, please
subscribe, share with friends,and of course, come back and
(37:11):
listen to some more. I'm verylucky to have a variety of
guests that talk abouteverything in the areas of
professional, Scrum, productthinking, and, of course, agile,
thanks everybody and Scrum onyou.
Music. Welcome to the scrum.org community
(00:04):
podcast, a podcast from the homeof Scrum. In this podcast, we
feature professional scrumtrainers and other scrum
practitioners sharing theirstories and experiences to help
learn from the experience ofothers. We hope you enjoy this
episode.
Dave West (00:20):
Hello and welcome to the scrum.org community podcast.
I'm your host, Dave West, CEOhere@scrum.org today's podcast
is part of our agile productoperating model series. Today,
we're going to discuss therecently published paper moving
beyond Agile transformations,leveraging the Agile product
(00:41):
model. And I'm really lucky tohave the author of the paper,
Andy brand, PST andOrganizational Change Guru to
talk about his motivations inwriting the paper, and really
that to really lean into what isthe state of Agile
transformations. Welcome to thepodcast, Andy,
Andy Brandt (01:04):
hi, hi, thanks for having me, Dave. Glad to be
talking to you again, talkingwith you again, about this
topic, because we talked a lotalso when we were working on the
paper. Yes,
Dave West (01:15):
we did talk a lot, and let's hope we don't bore our
listeners, because I'm sure wedid talk for hours and hours
about this. And you know, yourexperiences in the Agile
transformation world and and howyou saw those transformations
really, were really interesting,because very similar to what I'd
(01:36):
seen in the US and the worldwith respect to that. So before
we jump into the white paper,Andy, you know, let's start with
the landscape or context ofAgile transformations. So what's
your take on the state of playon Agile transformations? What's
happening?
Andy Brandt (01:56):
So I think that they are mostly a thing of the
past. So whoever wanted tointroduce agile into their
organizations, into theircompany, they have already done
that. And I would say that thisbig wave was around 2017 maybe
till 2021 maybe 22 for somecompanies. So, but if I, if I
(02:24):
encountered Agiletransformations underway in 2022
it was mostly something like asecond take. So is the second or
third time we tried to do thisbecause the first time didn't go
as well. We didn't get theresults we wanted. So we are
trying it again. But I would saythat the other transformations
are largely done. And what doyou
Dave West (02:45):
think in terms of the outcomes? You know, I've seen
lots of these Agiletransformations happen over the
last 10 years, and I've got,I've got a feeling what the
outcomes are on in in average,obviously, there's outliers on
both ends. But what do you seein terms of, you know, the
success, the value that they'vegot, that organizations have got
(03:08):
out of Agile transformations.
Andy Brandt (03:10):
So I think that they got quite a lot of value,
because in many places, theseefforts succeeded in creating,
for example, cross functionalteams. And there is just one
memory just just just pluggedinto my mind about that was,
like, 15 years ago, or maybe,yeah, that was, I think, 2011 I
(03:34):
was called to talk about agile.
That was 2011 in a large bankand, and I don't remember much
from that event. It was a verylarge event of large auditorium
in the HQ with like 200 peoplethere. And there were two
departments present, largely theDepartment of software
(03:54):
engineering and Department ofquality assurance. And as part
of my talk, I was responding toquestions from the audience,
which were coming on small slipsof paper. And I remember just
one of those questions, and itwas like this, I understand that
now, with agile, we'll have towork more closely with them, but
(04:15):
we'll have to also sit togetherwith them, okay, so, and this
showed the depth of culturaldivide between those two groups.
Now it's unthinkable that divideis largely gone. We don't have
totally separate departments ofquality assurance and software
(04:36):
development. That's one exampleof the change that happened so
we have more cohesive teams. Andalso I feel that we we
concentrate so much onprocesses, on Scrum, etc, but I
think there is also lots ofimprovement when it comes to the
craftsmanship of buildingsoftware. A lot of that has
improved over the past 15 yearsor so. But part of that is
(04:59):
thanks to tooling, but much ofthat is again, thanks to
efforts, and also thanks toagile. The sole thing that you
have to have something donefairly often. And again, it's
not so that all teams that saythey do Scrum, they actually
have something done every twoweeks, which is the predominant
splint length, by the way, butstill, they have something done
(05:21):
more often that they had in thepast, and that kind of forced
improvements in craftsmanship.
So I think there's lots of lotsof doubt. And also we have
created quite a lot of ScrumMasters, adjunct coaches, whole
departments of way of workingand and, I mean, again, some,
(05:44):
some are saying that they arenot as valuable, or maybe they
shouldn't be there asdepartments or whatever. But
basically, what we createdcreate a whole body of people
who care about the process andabout improvement and about
getting better in theorganizations, and they are,
they are still there, in asense, right? So those are those
(06:06):
things that, on average, worked,yeah, yeah,
Dave West (06:11):
I would completely agree. I think the, you know, 20
years ago, 15 years ago,delivering product and
predominantly software. Butdelivering software product was
incredibly hard. Delivering theprocess was incredibly
complicated. We were talkingabout things like CMMI. We were
(06:33):
talking about, you know, Kokomoand things like that. And I
think over this last 15 years,what I've seen is that delivery
has definitely improved, crossfunctional teams, particularly
with business analysis, testing,development, maybe UX have kind
of come together. Maybe UX,that's a whole nother debate and
(06:56):
a start, and are effectivelydoing, doing work together,
which, which would have been,you know, I remember my first
job, and you're a little bityounger than me, but you can
probably attest to this, I builtcode. There was a whole
different room where peopletested it, and they weren't very
nice people. Actually. They justkept finding problems with my
(07:17):
code, which I didn'tparticularly like, at least now
they're focused workingtogether, which is a, which is a
huge thing, but, but I stillsee, and maybe, maybe you don't
see this, but, or maybe you do.
In fact, I think this was the,the sort of premise of the
paper, the that there's still alot of these teams are still
(07:39):
working on work. They're notworking on value. They're not
aligned to innovation. There's amassive gulf between business
strategy and technical delivery.
They they're sort of going inthe they're going really
effectively, but not necessarilyin the right direction. They're
(08:03):
building things that peopledon't want. They're taking an
alternate amount of time to dothat. That's that is has not
changed because of Agiletransformations. Do you agree?
Andy Brandt (08:14):
Yeah, I think it's slightly changed. It's slightly
changed, but it changed. Iwouldn't say it's not enough
what has changed, because whatI'm saying slightly changed. I
have two things in mind. One isthe companies, the
organizations, or maybe parts ofthe larger organizations, that
you call the outliers, wherethey change really deep around
(08:38):
deep and was profound, but theyare a minority. And I would like
to make this I would digress abit, but I think it's it's
normal. It's something to beexpected when we change and when
we introduce change, and maybethat, that's another article
(09:00):
that I have in on my mind. Butwhen you change, when you
introduce change in the way wewere doing with Scrum and Agile,
we were trying and we werelooking at the best companies
and best teams and mostproductive teams and hyper
productive teams, etc. Well,average teams are average. They
cannot ever be hyper, hyper. Itwas always a minority, so it
(09:23):
couldn't hope. And no, no onecan hope really, unless they
take really drastic measures toreally become from from becoming
low average, they to jumpsuddenly to being one of the top
performing outliers. I'm notsure that. I don't think it's
even possible, but what ispossible is moving from being a
(09:49):
low performing average to higherperforming average, what I call
the 5% difference. But that 5%difference might be difference
between going down and going.
Slightly up, and that's a wholelot of difference. So that was
to be to a certain degree to beexpected, but the organizations
did not get out, and I'm gettingback to the main topic, they did
(10:10):
not get out from the coreproblem that we all have, which
is we are trying to do too much,much more than we are capable
of. And I'm saying we all haveit because it's a human problem.
We have the same problem in ourlives that we're trying to grasp
too much, but in our lives,there are kind of hard limits
that we can see or even feel.
(10:34):
And in a large organization, ifyou are an executive, a CEO or
someone of this kind, it's mucheasier to fall into that
illusion that we can doeverything, because almost no
one will say no to you. And theend result of that is that you
have an anti pattern that I seerepeatedly in organization, is
that they have like 100initiatives open, and how many
(10:59):
people are working on on thoseproject well, 25 right? I'm
exaggerating slightly, but, butthis is this kind of
relationship. We have manyprojects, initiatives, all kinds
of names for different types ofwork, and that work usually cuts
across different technologies,different systems and different
(11:21):
teams. And one, one person thatI talked to, one one manager and
at the bank, he used this jaranalogy. He said that our teams
are like this jar that is fullof sand, and there is no place
to stick big stones, where inbig stones, he meant products.
And this leads to this, to thisproblem that so we have agile
(11:43):
teams. We have we are deliveringmore often. We are better
technically. We are bettercraftsmen. However, we don't
have spectacular results. Andhow do you achieve spectacular
results? Well, but by focusing,you cannot be spectacular in
everything. You have to focus onsomething. So if you bowl that,
(12:03):
if you kind of transfer thatinto an organization, I would
say that teams have to befocused on products. And that's
the biggest problem right nowthat we don't have. I mean that
the whole work is not cut intoproducts properly. And secondly,
that those teams are not reallyfocused on those products, and
this is what we are trying toaddress with apon, I think
Dave West (12:27):
it's interesting. You sort of highlighted something
that I don't think is obviouswhen you think about moving to a
product model, but it'ssomething that Dow Fernandez, ex
CIO delivery lead of some largefinancial institutions, when he
was introducing productoperating model or a product
(12:49):
model to those organizations, hesaid the most important and most
powerful thing that it gave himand his organization, his
delivery organization, was theability to say no, and which
sounds incredibly negative, andyou're like, my god, the last
thing you want is something thatcan say no. But he said because
we said no, we said yes, so muchmore. I was like, Okay, now, now
(13:14):
hang on. I'm now going around incircles. He goes because we
actually had a road map for ourfor our products, and the teams
were aligned to those products,and they weren't continuously
changing focus, and they weren'tcontinuously, you know, context
switching and connecting anddealing with dependencies. And
everybody knew it gave us theability to do a lot more, but it
(13:39):
gave us also the ability to notstart a lot more at the time,
you know. And I thought that wasa really interesting
perspective, that that that issomething that his agile teams,
and obviously he was atFidelity, who were the what
second or third company ever inthe world to do, Scrum and, and
(13:59):
I thought, you know, I thoughtthat was a really, really
interesting, interesting pointof view. No, so, alright. So the
alright. So we've got thischallenge. You've got agile.
Transformations have happened orbeen happening, and maybe
they're still happening in yourorganizations. And sometimes
these things are big and long,so we're not judging here. We
(14:22):
don't do any of that, but thevalue that you're getting, which
is significant, could be so muchmore with this idea of a palm.
So talk a little bit about theAgile product operating model
from your perspective, that's
Andy Brandt (14:40):
also well, so from my perspective, is mostly, maybe
I wouldn't say mostly, becauseas we, as we worked on this
model, and we are working on itright now, I see that there are
different perspectives on that,but, but from my perspective,
from where I see it, so to say,I would say that how to manage a
product is an. Already solvedproblem. We already know how to
(15:02):
do that by saying we I'm sayingthe community at large. There
are books about it, there arepeople who have experience in
it. There are training courseson how to be a product owner,
product manager, or however youcall it, on different levels of
competence. So we know that. AndI'm not saying that it's easy,
but there is this body ofknowledge. However, the key
(15:25):
problem seems to be that thereare no real product owners
really managing the products.
And you said about contextswitching, we are kind of forced
to context switch, in a sensethat we have to adjust our
products to the changing marketfaster and faster and faster. So
for example, strategy now issomething two years off and not
10 years off, but still, it'sdone better when there is
(15:49):
someone who makes decisionsquickly, but they are within the
context of the product that theyactually really own and don't do
that alone, then they own itwith their team. And from time
to time, that can change, in asense that this whole team, and
this whole team with the productowner, maybe gets another
product or starts towardssomething else, if that product
is not being developed anymore,or maybe it's not needed
(16:13):
anymore, but, but still, it's alonger stretch, right? So we
deal with instability, but beingmore stable, it's something like
this, no, yes, problem that youyou mentioned, or I will say
that again. So yeah, we getstability, but we also deal with
change better. And it's likethis, yes, no, paradox that you
(16:38):
mentioned, right? So, so I seeit as a problem of how together,
and how together is mostly howwe convince people who are
running those businesses, andthey are running those
businesses in the context of oursocio economic system where they
have to deliver profits and theyhave to be rising every year.
(16:59):
How we convince them that theway to get there and to get
those spectacular results theycrave is to give more of the
organizational power that theyhave in those teams to actually
developing products, how toconvince them that it's better
to say no to many initiativesand say yes to some well
(17:22):
strategically chosen product.
And again, because we had thoseAgile transformations, because
we have agile teams, thisstrategic commitment doesn't
have to be long term. It can be,I don't know, for a quarter, and
if, after a quarter they feel aproduct makes no sense, or
(17:44):
investment in continuinginvestment makes no sense, it's
easy to switch to somethingelse. So how to get them to view
the organization, not to thelens of ongoing work, projects
initiatives, but through thelens of, okay, we have products,
and we develop products. And ofcourse, we have ongoing work as
well, but at least some part ofour power, which is manpower,
(18:10):
which is capital, is devoted todeveloping products. And that's
an organization, organizationalchange problem. And again, as we
are talking right now, it justoccurred to me that this all
happens at a crucial moment,because right now we are in the
(18:31):
midst of artificial intelligencerevolution, and I'm also very
deep into that. And when itcomes to software development,
it's a revolutionary technology.
It increases the effectivenessof teams well from 30 to 70%
depending on whom you ask. Buthaving used those tools and
(18:52):
using those tools myself, I seehuge change over the last year,
and it will just increase now.
Why I'm mentioning that? Becausethis is another kind of
temptation for the managers.
Okay, why bother with that? AIwill do everything that I want,
and no, even AI won't do all theinitiatives and all the work
(19:15):
that you do that it is this,this, this problem of having the
jar with stones and sand, itwon't go away. Yes, the job will
be bigger, but the problemitself won't go away. So while
organizations will surely investin this, in that technology, and
then I'm very much for that, andI support that, and I will even
(19:36):
be helping organizations dothat, I still believe that they
have to focus on well selectedproduct portfolio, and that's
the main challenge. I mean, themain challenge actually
convincing the CEOs, CEOs andother executives, that this is
the right way to go.
Dave West (19:58):
I think AI, it's really. Interesting. You brought
up AI. I agree that AI and thistechnology is, I mean, it's,
it's at the level of a print theprinting press, you know, in
terms of its potential impact insociety. I actually was using it
(20:18):
yesterday. I'm not very good at,you know, accountancy and
planning and forecasting and allthat stuff. And so I took it, I
took my data, and I threw it inand asked it some questions. And
I wouldn't say it was perfect,but it helped me make some
decisions about, you know, wherecertain products are going, etc.
But the key to it is thatcontext and the problem that AI
(20:44):
suffers from, and we've done alot of experiments like you
have, is, if you give it a muchbroader context, then the value
of the answers that it gives youand the solutions that it
provides are less valuable. Thegreat thing about this boundary
that we're calling product isit's customers, stakeholders,
value. You know, it's aclassical model right of a
(21:10):
context that makes sense, whichthen providing that context and
those boundaries allows AI to dosome amazing things, to increase
the power of the solutions it'sit's creating. You know, I think
that the the the alignment toproduct in an organization,
(21:31):
coupled with the use ofdisruptive technology like AI
will, I mean, potentially coulddo amazing things. Obviously,
you have to pick the rightproducts. That's a choice thing,
and you've got to make somedecisions about where value
lies. But if you, if you dothose two things, I think the
sky's the the limit really. So Icompletely agree,
Andy Brandt (21:55):
okay, to you to use your printing press analogy. It
is as hard now as it was then,to write a valuable, Wise Book,
because it starts with withhaving something to share. And
you can you back then you use,probably quail pen and stuff
like that. And right now you canuse open AI to draft it with you
(22:19):
and polish your language, butstill, you have to have some
idea what you want to have tohave something to say,
basically, right? Becauseotherwise it will be low
quality. So what the printingpress changed is that it's much
easier to then bring it to tothe users of books or to the
readers. And ebooks make thateven easier right now. So going
(22:43):
back to the core problem, thecore problem will always remain,
as long as we are in a limitedreality is that you cannot do
everything, and you have toconcentrate your efforts in
order. I mean, the question is,what do you want? Do you want to
prolong the existence of yourorganization as it is now, or do
you want spectacular results?
And I'm kind of quoting thisspectacular results is, is
(23:04):
something that one board memberdemanded from his people and,
and I think it's a fair demand.
I mean, you are doing thisextraordinary change, you have
those motivated teams. Where arethe results? It's a fair
question. However spectacularresults come from concentration
(23:25):
and focus, and it has been soalways, and I don't think any
kind of technology can everchange that. Yeah, so, so this
is the I mean, and I want tounderline that the apom is
something more than that,because we have been working on
that and discussing amongst thePSDs that are working on this
(23:46):
model. So there is, there arestill those problems, how to
manage products, how to organizecross product work, etc. But
from maybe that's my maininterest. That's why I'm so
focused on this. It's okay, buthow do you first get the
company's management to actuallyrealign much of their resources
(24:10):
around certain specific productsin a product portfolio that it's
not too large for the resourcesto be spread to think to make
any difference
Dave West (24:22):
and and that is the I want to say, $64,000 question. I
guess when that saying came out,$64,000 was a lot of money. Now
it's not, maybe as much. Butthat is the fundamental
question. And from what I'veobserved, the best way of doing
that is to start doing it andand start with one product, and
(24:45):
then incrementally add anotherand then another and start doing
that. The the message of this isthe other thing that Agile
transformations, I think, gotwrong. And I you know this is
going to sound very grandiose.
And and please shoot me down.
Andy, if I'm if I'm soundinglike I'm preaching here is that
they assumed, one that theimplementation of agility would
(25:09):
be done in a very sequentialwaterfall way. The other thing
is they assumed that all teamswould be agile, but they would
all kind of do it the same way.
They would have the sameunderlying agile operating
model, and I don't believe that.
And what I've observed isdifferent products require
(25:30):
different cultures, they requiredifferent organizational models,
they require differentincentives. They require now,
they might not be grassdrastically different from the
other products, but, but theability to own, I always thought
there was an irony when we saidthat the people that own the
scrum process that youimplement, because it's a
(25:52):
framework, are the teams, butwe're going to tell you how to
do it. And I thought there wassome irony in these Agile
transformations, telling peopleto become agile, you know,
because of the you know,ownership, whereas I do believe,
if you can empower the productteams and the leadership around
the product to take ownership ofhow they work, how they're
(26:14):
incentivized, how they'realigned, what, what the you
know, the roadmap, thetechnology roadmap, the business
roadmap, the operationalroadmap, the value model, they
take ownership of those things.
I think I honestly you talkabout spectacular results from
my experience, having done a fewstartups, the most spectacular
(26:34):
results we ever achieve is wheneverybody's aligned and owns the
things that they're working on.
And, you know, and obviously, AIand other technology can,
really, can really, can reallydrive that. So I guess to answer
your question, even though Imeant to be asking the
questions, I guess start oneproduct at a time. So what? What
(26:57):
you know, listeners, you know
Andy Brandt (27:00):
this is interesting, because when you
talk to companies, when youtalked about what were their
experiences, quite a fewcompanies have an experience of
this kind that for some reason,usually that was CEOs pet
project or something like that.
They did really set these thingsupright. So they set aside a
(27:20):
team and gave that team aproduct and let that team run
with it. And quite often, thatended in a success, larger or
smaller, depending on how bigthe market opportunity were and
other factors. However, it kindof worked. What is interesting
is that most often no one hadthe idea, okay, let's repeat
(27:43):
that with three products, ormaybe with five product next
time, right? So I know at leastone such project that ended and
this team being spun off as aseparate company, which is an
okay business decision, but whynot to try and repeat that
again, right? So,
Dave West (28:05):
yeah, I've seen that so many times. It's like when I
used to go into organizationsand and I said, How long does it
take you to deliver software?
And they said, Oh, 12 weeks. Andsaid, so when you have a
production failure, it yourproducts are out for 12 weeks.
Oh no, no, we can deliver inminutes if there's a production
problem. So you can deliversoftware in 12 minutes, or
(28:26):
whatever they say. Oh yes, butnormally we don't. I was like,
Well, how do we make the normnot how do we make the norm the
opposite. And there was, like,what, we can't do that. Why?
Well, because, you know,obviously using the best people.
So you're saying the otherpeople aren't the best. How do
we make them the best? Well, no,no. Well, we create an
(28:48):
environment around them wherethey can make choices and make
decisions. You're telling me youdon't do that for your normal
Well, we could do that. And itwas, it's just always
interesting as you unpack, youknow, the the organizational
bureaucracy that has there'sevolved for good reason to make,
you know, but at the end of theday, it's, it's about choices,
(29:11):
and it's about trust, and it'sabout support, you know, and you
get those three things in place,which I think are fundamentals
to the to a POM to the Agileproduct operating model, using
evidence to make those choices,using evidence to provide the
support you know and and fix theproblems and make those you know
(29:32):
right choices. I think that atthe end of the day, you can, you
can do amazing things. So ourlisteners, you know, we have to
keep this short, and I couldtalk to you Andy, as we've
proven many very late nights foryou, we have, we have burned the
oil talking about this stuff.
(29:55):
Our listeners, you know, maybeat many different levels in an
organization, maybe. Some ofthem are practitioners working
in Agile teams that have beenthrough an Agile transformation.
Maybe we've got some leaderslistening. What would be the
advice for them about a palm andthe to leverage this Agile
(30:15):
transformation and and to reallytake it to the next level? What?
What can they do next?
Andy Brandt (30:21):
I would say, start with the first product. So
define, well define a product.
And this is, this can be hard inits own right, because by a well
defined product is also hastechnological implications,
which means creating a productthat has as few hard
dependencies as possible, andgive that product to a team, or
a group of teams, a formation,as we call it, with a product
(30:44):
owner, and let them run withgeneric or general business
goals, like a certain number ofusers, conversions, revenue,
whatever, and see how that playsout. And obviously choose a
product that that makes sense,right? So a product that really
would appeal to your customerbase, etc, and see how that
(31:08):
plays out if you can get becauseit's much easier to get your
executives, whoever, has thepower to give green light to an
experiment like that and keepthat light, that green light on
for long enough period for thatto have any to bear any fruit.
(31:29):
It's much easier to get such acommitment for one product than
for creating a product portfolioof 40 products are 40, it's way
too many. But like 20 products,and having quarterly reviews of
those product portfolios, etc,it's much easier to get a
commitment for one product, for,I don't know, a year and and,
(31:50):
and then proving that this canwork. And what is important that
it can work here, not somewhere,somewhere else in another
company, somewhere else inanother country, not here.
That's an important proof. Andby the way, this is how Agile
transformations got started. Isthat somewhere some people
(32:11):
established a few Scrum or agileteams, and they started to be in
some aspects, better than therest, and it got someone's
attention. That's how it gotstarted, before we had all the
marketing going, before webefore the large consulting
company started talking aboutthat to clients, etc. Before
(32:33):
that, it started like this. Soyeah, that's what I would
recommend. Start
Dave West (32:42):
with a product, and it's a natural, you know, just
to re echo the white paper, it'sa natural evolution of your
agile approach. It really is.
What you're doing is you'rebasically changing the focus of
the team from a work backloginto a product backlog, and
(33:03):
really bring in the business,the people that are ultimately
stakeholders of this, thisproduct closer to that, and
empowering some sort of productowner, Product Manager, to drive
this product into the market andto deliver the results. Might be
an internal product, might be anexternal product, but deliver
(33:26):
the results that the vision andthe dream and the plan are
aspiring to. But I think it's aI think everybody has that
ability to make this change. Andthat's the other great thing
about a palm right, is thatAgile transformations,
particularly at scale, were likethese huge things. What we're
(33:49):
actually saying is get a team,or maybe a couple of teams, if
it's a slightly bigger product,focus them on it. Get a road
map, get a business map, get aROI, build those, build those
OKRs, or those goals, and thenform that and then focus it on
the problem at hand and let themgo. And then review it
(34:11):
continuously and see how itgoes.
Andy Brandt (34:18):
Right. And if it's a new product I would highly
recommend to start with one teamand many.
Dave West (34:24):
Oh, yes, so would I there is a fallacy or a sort of,
you know, if you the idea thatif you throw 100 people at a
problem, you get it, you know,10 times faster than 10 people?
No,
Andy Brandt (34:42):
it's worse. It's worse than that, because those
people have to do something. Soif there is not enough work
coming from the product owner,they will invent their own work,
which will basically meandeveloping something according
to their vision. How the productwill evolve in the future, which
(35:02):
usually ends up, in all that,having to be reward or holding
the teams back in the future. Soit's so much better to start
with one team if you arestarting with a new product,
small
Dave West (35:16):
is definitely the way to go. It is true that having
lots of teams from day one,particularly on a new product,
is a as a recipe for disaster,usually, unless there are
actually multiple products andthere's a clearly understood
this, you know, separationbetween them, which is, which is
really, really good. Andy, thankyou for spending the time today.
(35:39):
I've really enjoyed listening toyour experiences around the
Agile product operating modeland talking about your white
paper, moving beyond Agiletransformations, leveraging the
Agile product operating model.
Andy Brandt (35:57):
Thanks. Thanks for having me for this discussion in
the scrum.org podcast. So firstfor me, so you know, oh, well,
Dave West (36:07):
that's always that's always good, that's always good.
I'm glad. Finally we got,managed to get you on and
listeners, thank you forlistening today to the scrum.org
community Podcast. Today, we'relistening to Andy Brandt PST and
organizational change experttalk about his motivations in
writing the paper, moving beyondthe Agile transformations,
(36:27):
leveraging the Agile productoperating model. Hopefully it's
been as enjoyable for youlistening as it has been for me,
participating. I think the onemessage that came out was this
is a great way of really takingthose Agile transformations and
the benefits you've got andaligning it to the problems of
(36:50):
the future and to the outcomesthat the company seeks the
strategy is driving to, andreally letting it go and and AI
is just going to increase thatleverage that you can that you
can deliver the value from so Ithink that was a great message
from today's podcast. And if youliked what you heard, please
subscribe, share with friends,and of course, come back and
(37:11):
listen to some more. I'm verylucky to have a variety of
guests that talk abouteverything in the areas of
professional, Scrum, productthinking, and, of course, agile,
thanks everybody and Scrum onyou.
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!