6 min read
August 25, 2022
Ep. 177
Episode Description
This week, Dan Neumann is joined by Adam Ulery to explore the topic of scaled approaches independent of embracing an industry framework. In this episode, Dan and Adam are discussing scaling without adopting an Agile framework like SAFe. They share the reasons organizations use industry frameworks to scale, dive deep into the characteristics of SAFe and other frameworks, and describe the principles that need to be prioritized while scaling, such as Clarity of Vision, Goal Alignment, Frequent Delivery of Value, Planning and Coordination, and Transparency.
Key Takeaways
SAFe is the most popular Agile framework for leading enterprises because it works; it’s trusted, customizable, and sustainable.
Why do people want to use an industry framework to start with?
People choose an industry framework to start with because they recognize and feel familiar with something that is out there in the market.
There is a script to follow, so people don’t have to think about the complicated parts; it is already done for them.
When to look for another scaling framework that is not SAFe?
When the scaling framework doesn’t work for the client, based on where they are at the moment.
Dan and Adam share an example to describe the situation where certain frameworks would not be of use.
The model can’t be against the organizational structure.
Principles around how an organization can scale:
Clarity of Vision: Make sure there is a good vision for the groups that are involved in the change, clearly expressing the purpose and goal behind the everyday work.
Goal Alignment: Capture the vision and create an alignment of goals that promotes it.
Aligning strategy to execution is an enormous tool.
Frequent Delivery of Value: Teams learn by delivering value and receiving feedback, which helps coordinating and planning the next step.
Transparency: Practicing transparency is key in a scaling process, especially when things get more complicated.
Technologies involved in scaling must be aligned; coherence is crucial.
Mentioned in this Episode
Back Mechanic, by Dr. Stuart McGill
Thinking Orthodox: Understanding and Acquiring the Orthodox Christian Mind, Eugenia Scarvelis Constantinou
Want to Learn More or Get in Touch?
Visit the website and catch up with all the episodes on AgileThought.com!
Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!
Transcript [This transcript is auto-generated and may not be completely accurate in it’s depiction of the English language or rules of grammar.]
Intro [00:03]:
Welcome to Agile Coaches’ Corner by AgileThought the podcast for practitioners
and leaders seeking advice to refine the way they work band PA the path to better
outcomes. Now here’s your host coach and agile expert, Dan Neumann.
Dan Neumann [00:17]:
Welcome to this episode of the Agile Coaches’ Corner podcast. I’m your host Dan
Neumann. And today I have a pleasure of being joined by Adam Ulery. One of my
colleagues here at AgileThought, and we are going to be exploring scaled
approaches without embracing an industry framework. Adam, thanks a ton for
joining. Appreciate it. Yeah, thanks for having me back on Dan. Always a pleasure
and I’m excited to dive into our conversation today. Perfect. Perfect. And you seem
like a guy who likes to talk about kinda larger challenges with agile, with scaling and
leadership and organization and kind of, kind of a sweet spot for you. Yeah, yeah. I
do seem to gravitate towards those. Perfect. Hey, we’re going to be talking about
scaling without following an industry framework and at least for me, I think a lot of
times scaling is thought to be synonymous with the skilled agile framework for
enterprises or safe as it’s be come to be known.
Adam Ulery [01:18]:
And I dunno, is that what kinda, what you’re seeing as well? Yeah. Whenever I’ve
heard a, a client or a potential client some, some organizations, leaders talking
about a scaled agile initiative, it’s always safe. I, I don’t think I’ve ever heard them
mention one of the lighter weight frameworks for scaling or, or some of the lesser
known ones. It, it always seems to be safe. They seem to have that, that what
would you call it brand awareness in the market? Kinda like the Kleenex of the
scaling world. That’s exactly what I was thinking. Kleenex, Coke, whatever safe. But
there are other brands, if you will, of scaling there there’s nexus, which is a scaled,
scrum approach people yeah. Less still tend to less. Yeah. People think of Spotify as
a bit of a model that they might get the papers on and, and kind of embrace on
their own.
Dan Neumann [02:27]:
I dunno, I dunno where you feel about Spotify as a thing, not as Spotify music
service, but as a scaling model. Yeah, well, you know, I listen to their music service
but as a, as a model, it’s interesting because even Spotify doesn’t use it or has, has
moved on. And and so maybe, and, and, and to be honest with you, I haven’t
followed it very closely. So I, I don’t know the reasons why they moved on and, and
all of the story, maybe you do, but they, for whatever reason are not doing it now,
so it’s not working for them where they are now. And I, I think it’s interesting that
people will want to latch on there’s something about it that attracts people. They
want to latch onto it, but but the of people who created it aren’t even using it.
Adam Ulery [03:20]:
So that’s always kind of interesting to me. It is interesting. Yes, safe is for sure, the
800 pound gorilla in the scaled agile marketing world. And I, I don’t have the
specific metrics, but a tremendous number of organizations that are scaling are at
least saying they’re doing safe and it’s possible. It’s like scrum, where somebody
says, they’re doing scrum and you look at it and you go, Ew, that’s not actually
scrum. Yeah. Yeah. Oh. And then that just gets scaled up into safe. Doesn’t it? We
see that constantly. Yeah. I’ve, I’ve seen so something about skilled agile in general
is there has to be some agile to scale. And I have seen the let’s teach people what
agile on Monday and Tuesday, and then we’re gonna do a program increment
planning session Wednesday, Thursday, Friday. And that went about as well as it
sounds like it probably would’ve gone.
Dan Neumann [04:15]:
And we see that so often as well. I mean, I, I don’t know. Yeah. Right. Hey, let’s we
don’t wanna do the little stuff. That’s easy. Let’s just go for the big stuff. Let’s talk
about briefly. Why do you think people want to use an industry framework to start
with what’s what’s the motivation there behind taking that approach versus a
different one? That’s a good question. I mean, part of it, I, I wonder if people would
admit this, but it’s a recognition or a familiarity of, of something that’s out there,
like that’s recognizable. So, you know, it’s a brand that they recognize, it’s
something they’ve heard about. And, and in some way that feels that feels familiar
to them. So they’re, they’re more likely to be, I don’t know, to, to be open to
considering it not, that’s more of a, that’s more of an emotional, like intangible
reason.
Adam Ulery [05:15]:
That’s, that’s not easily justifiable for people who are taking a thoughtful approach
to it, I think there’s something around the fact that it’s, it’s packaged up you know,
there there’s a script to follow if you will, or, you know, the framework to follow. And
so they can take this thing and they can install it. And they don’t have to think
about a lot of the complicated pieces and parts because it’s already there for them.
And, and they just have this idea that they can just install that thing. And it works I
believe you know, I believe there’s a lot to that. What do you think, Dan, I agree
with you on, I think all the points you’ve, you’ve mentioned there, and it makes me
think back it’s been a couple decades probably since the, the metaphor made
sense, but it was like nobody got fired for hiring IBM.
Dan Neumann [06:16]:
You know, if looking for an outside vendor, an outside expert, you know, back in the
day, it was big blue, right. You hire IBM. And look, if the project gets screwed up, it’s
not my fault. I hired the best I hired. Right. IBM. And I think there’s a little bit of
safety in, well, I went with the industry leader, I went with safe. So you hit that
tipping into that critical mass where now you’re the industry leader and it unleashes
that well, why wouldn’t you, you know, do safe. Yeah. And I, you know, maybe it’s,
if, if you think about I don’t know, a lot of consumer products are this way, you
know, do I want to build the thing myself? I mean, do I, do I wanna make my own
chair from scratch or do I want to buy one? Even if I have to pull it out of a box and
bolt it together, but there are instructions about how to do so it’s a lot easier.
Dan Neumann [07:12]:
Yeah, for sure. And I guess we should probably maybe a little, little AgileThought,
disclaimer, little Noman, disclaimer, like not bashing safe, just saying like, there’s a
tremendous amount of pull by people who have multiple scrum teams that need to
coordinate. And that seems to be the, like tap yourself on the knee. The, the foot
kicks up. You want to do scaling the foot kicks up. It’s it’s safe agree. But we see, I
think in our salting, a lot of organizations that for very good reasons, they isn’t
necessarily the, the right choice for them at that time. Maybe even nexus or less, or
Spotifys, those kind of canned approaches, aren’t the best in, in years, in my
professional opinion for them to take. And maybe we can explore like what would
cause organizations to have a legitimate interest in not just installing the scaled
package of choice.
Adam Ulery [08:14]:
Yeah. It’s, that’s, that’s a good topic to unpack here. And I, I think if, if you’re just
thinking, well, maybe safe is we’re not really, we don’t have a need for that level of
scale because safe is designed to scale with the largest of organizations actually
makes a lot more sense with those really large organizations. But it, you know, if
you’re a, a relatively small organization say you’re not even the size of a, the
recommended size of a release train. And, and you’re trying to think about how do
use save then obviously it’s, it’s a bit too much for what you need, and you could
just look at one of the other scaling frameworks, like, like less or nexus, right. And,
and that might work, but then what Dan and I see a lot of times is there are pieces
or arts of what they’re doing, or, or maybe there’s something about their
environment that, that doesn’t lend itself well to a complete framework like that.
Adam Ulery [09:27]:
And some pieces of the framework need to be bent or even broken, I guess,
augment something changed for it to work for them. And, and a lot of times I know,
I know Dan and I think about things as as, you know, do, do what you can now and
then learn from that and incrementally improve. Right. So a lot of times it’s a
starting point. And then, you know, you would like to get to maybe using one of the
frameworks at some point, or maybe you never need to doesn’t matter as long as it
works for you. But I guess the, the reason there in, in all of that, the reason is
there’s something about the framework as it sits that just doesn’t work for the client
based on where they are right now. Is that fair? Yeah. I think it is fair.
Dan Neumann [10:18]:
And to maybe add some examples the term chief chief product owner in safe, well,
there’s chief executive officers, chief financial officers, chief, and now you’re
introducing the phrase chief into an organization can be confusing, right? Wait, is,
have we created a new, a new C-suite member as part of our scaling? So even
things as seemingly innocuous as bringing in the, the, the terminology of some of
the scaling frameworks can be create organizational confusion. Yeah. Yeah. That’s,
that’s a good one. And kind of the, what is it, the larger pattern there may be that
there there’s some, there’s some structure in place that they’re not willing to give
up, but it doesn’t quite fit within a framework. Quite for example, maybe they have
some, some middle level team, like a, you, you would think of it at, at being at the
feature level and they may even be calling it a program team.
Adam Ulery [11:26]:
And, and they really don’t want to give that up, but the framework you’re talking
about, doesn’t call for it. You know, then that, that may be an example of where you
can sort of design a framework that would allow for that team to add value and, and
operate in a way where you don’t have to get rid of them. And then over time they
may see, oh, we don’t necessarily need them as a specific, a formal team. You
know, maybe, maybe it’s more of a virtual team and those people can add value in
other ways. And we’ll find out what that looks like for us as they move forward, but
to begin with they, they couldn’t even consider it. So certain frameworks to be off
the table from the beginning there. Yeah. As you start I think what you’re describing
is starting to put the model against the organizational structure and yes, over time,
maybe the org structure evolves to be something that is different than it is today.
Dan Neumann [12:24]:
Maybe more aligned with that framework, maybe less, but that’s where you are
right now. And, and changing org structure is not something that’s done
whimsically. It involves people in specific positions who value those positions for
various reasons. It could involve the human resources or the people, people, and
redefining job descriptions and pay grades and recruiting structures. And, and so
some of these scaled kind of packages, if you will require a lot of organizational
change to bring them in as, as part that’s a, that you’re getting to the heart of it,
you know, I think that’s, if you could only boil it down to one thing that that’s
probably it, right. It’s that ability to change for various reasons, organizational
changes difficult. And for a myriad of reasons, some organizations just are not able
to make some changes that would be required to use an off the shelf framework.
Adam Ulery [13:26]:
So what can we do to sort of meet them where they are and design something that
will work for them and, and then help them move along that, that maturity curve
perfect. And that is what we wanna spend some time digging into. So assuming that
an organization doesn’t want to, or can’t, or won’t kind of grab a scaled framework
and to be clear, I’m not even sure it ’s in totally appropriate in a lot of places to just
grab the framework and install it. There’s, there’s a lot of consideration around what
might be done. So let’s talk about some of the principles around how an
organization can scale their agile delivery. And so I think of it multiple teams
coordinating to deliver value. And the first one on the list probably is making sure
that there’s good vision for the groups that are coordinating to make sure they
know what’s, what’s the vision for this product we’re doing.
Adam Ulery [14:22]:
Yeah. That is important. I mean, it it’s important in general, like for businesses to
have that, but so many, we see don’t for a lot of reasons. And when, yeah, when
implementing of framework one of, one of the big advantages that we would seek
to get from that is this clarity of the longer term view of things, right? What is our
vision and, and having everyone who’s operating within the framework aligned to it
and, and supportive of it fully embracing it, are there some ways you’ve seen or
used where to capture the vision and to create alignment of goals to that overall
vision? Yeah, and I, I think it’s the making sure that top level leadership has the
vision clearly articulated, first of all oftentimes the vision will just be more of a idea
in some top leaders head and then their nearest, their nearest leaders would have a
notion of it as well.
Adam Ulery [15:42]:
And they would all probably be able to discuss it, but in more, you know, more, I
guess, descriptive terms, it, it’s not clearly articulated. It’s not, you know, it’s not
something that is a, a statement that we all understand the full meaning of and
and, and could repeat it crisply and succinctly, right? So it’s forming that, making it,
making it a crisp statement it with meaning and then effectively communicating the
meaning behind it. The, the reason why, and any context around it that’s needed.
And then the structure of the framework itself should lend to that, right? Just the,
kind of the way we set up the, the structures of the scaling framework, the teams
the, you know, the cadence, their interactions, all of those things should make it
conducive to share that vision and to discuss that vision as needed. And to make
sure that we’re aligned to it,
Intro [16:57]:
Have a topic you want us to tackle, send an email to podcast AgileThought.com or
tweet it with a hashtag AgileThought podcast.
Dan Neumann [17:08]:
When you’re talking about vision. I think the, the point that it needs, it can’t just to
be fuzzy. It needs to be clear, and it needs to be kind of ingrained in the, what
people bring to the project, how they view things. And so if you are doing different
agile events, making sure that that vision is repeated or, and, or written down
visible, it can’t just be something where there’s an assumption that everybody
knows what the vision is and what the next most valuable steps towards that overall
vision attainment are. And then you were also mentioning team structure and
making sure that teams can contribute effectively to that vision. And, and that gets
into things like, have we eliminated to the degree possible, the interdependencies
that are going to slow down value delivery? So if my team’s dependent on your
team, plus two other teams, and we all have to coordinate our value chains to
deliver something that’s much harder than if the team I’m on has one loose
dependency on one other team to deliver.
Dan Neumann [18:22]:
And so looking at how you get the people and the skills aligned into team to deliver
for that vision is, is a huge steel. Yeah, yeah. You’re spot on. And that, that’s a good
example of what I mean by having that, that structure set up and the design of the
teams and the cadence is in a some sort of a, a cross team planning session. One of
the, one of the steps that we take in the itself is to state the vision and, and how our
current goal aligns to it, for example. So that, that was a good example of that. And
Dan, this is all about alignment, right? I, I, I think alignment is this really powerful
kind of underlying principle that ties a lot of this stuff together. It, when we’re
talking about this, a scaling framework, right, we want alignment across multiple
teams of the vision of the top level goal of our understanding of what we’re trying to
achieve.
Dan Neumann [19:32]:
Right. We all wanna be rowing in the same direction. That’s interesting. And, and I
was just thinking of, of examples where misalignment creates a problem. If I’m
optimizing for flexibility and you are optimizing for performance, we are going to
slam against each other in a very bad way at, at some point down the line, that’s a
great example. And what does our vision tell us we should be optimizing for, right.
Like there’s something in there that would help us get into alignment there, for
sure. Yeah. You’ve talked about OKRs in the past. Do you see OKRs playing a role in
the vision and in alignment as well as, you know, obviously team structure, but OKR
is then helping to make sure everybody’s aligned towards common goals. They’re
an enormously effective tool to align strategy to execution. And that strategy is you
know, it’s, it’s intertwined with the right.
Adam Ulery [20:34]:
The vision informs the strategy. So, yes, absolutely because I sort of see it, the
layer, I almost see it like the layer under it, and the way, the way I look at it anyway
is having strategic objectives, let’s say quarterly objectives which is OKRs or a
framework for that. Then tho those support, the longer term vision we’re gonna
choose strategic quarterly objectives that align to our vision. And then beautiful
thing OKRs is those will, those will kind of radiate so that the teams are all able to
find ways to contribute towards that quarterly objective and their domain. And they
set goals. Very cool. It’s all, it all aligns very nicely that way. For sure. So then
you’ve got the vision alignment perhaps articulated through KRS. You mentioned
cross team planning as one of those important facets to scaling and framework a, B
and C are each going to have their own version of cross team planning or multi
team planning.
Adam Ulery [21:44]:
And that’s where it becomes important for an organization to figure, okay, we have
teams, how would we like to enable them to do their planning together, or, and it
doesn’t have to be inflicted. You could even go to the teams and say, Hey, teams,
you all need to coordinate what works best for your situation, right. And a big
advantage of that is getting those teams again. I could use the word aligned here
you know, getting those teams aligned, but getting those teams coordinated.
That’s, that’s also something to think about there with making sure that they’re,
they’re not, you know duplicating work or, or worse that they’re not pulling against
each other in some way, you know, they’re, they’re coordinated and they’re, I really
like that metaphor of, of rowing in unison together. And they can get together for
just long enough to be able to coordinate in that way and make sure that the, the,
what they’re doing works well together for them all to if kind of the larger goal of
the, of the whole say program or organization that, that they’re part of.
Dan Neumann [23:01]:
Definitely. And, and that’s that type of coordination. If all the teams are using
scrum, or if they’re all using iterative approach, an organization may find a
particular pattern of synchronizing on planning works. If they have teams that are
flow based, not iterative, that might inform a slightly different type of coordination
as far as planning and frequency. And, and so kind of that context matters. Yeah.
And then within that, we are trying to get teams to deliver value frequently as well.
Another principle then beyond clarity of vision, goal alignment, coordinating
planning is frequent delivery of value. Right? And we like, we like that for several
reasons, right? We like to deliver frequently because we’re delivering value more
frequently. So that keeps customers happier than if they have to wait a really long
time to get something. And then it’s not exactly what they expected.
Adam Ulery [24:04]:
But you know, giving them little bits along the way just tends to keep them happier.
We get, we learn so much. That’s one of the bigger advantages is that we just learn
so much about delivering frequently. That’s how we learn by delivering, right? And
then we get feedback from not only from customers, which is, is extremely
valuable. We like to take their feedback and help that inform our next plan. But we
get feedback from our colleagues and peers and coworkers about what’s working
with our processes themselves. You know, how is this delivery process working for
us? How, how are, is the release that’s working for us, all of those things and more
so, we’re just learning a ton about that. And then it takes a lot of coordination to be
able to do that across multiple teams, because we’re, we’re not just thinking at our
team level, we’re thinking systemically because we’re, we’re in an environment
where we have multiple teams and we’re kind of working on something together.
Dan Neumann [25:09]:
So that’s where that coordination piece comes in. If you want to deliver frequently,
you have to stay coordinated. Yes. And the other piece, in addition to the value
delivery and the feedback loops, there is the tremendous amount of risk that can be
reduced by putting different pieces together, frequently, putting them into
production, seeing what behaves you your root cause analysis is a lot easier when
you do frequent delivery, cuz you go, Ooh, something we changed in the last week,
two weeks, et cetera, just degraded performance. Didn’t perform the way we
thought broke. Cut customers, hate it, whatever the feedback might be. You go,
well, I know what we changed in the last couple weeks. It’s better than looking back
over a year and going, oh shoot, 12 months ago, we made a bad choice. Didn’t we?
Right? That’s like finding a needle in the haystack at that point.
Adam Ulery [26:03]:
It is. I mean, we’ve anybody who’s been part of a, a waterfall delivery software
project has experienced that at the end where, you know, you’ve got the, the huge
March towards release and you’re trying to, to test and you’re, you’re finding things
and there are all these outstanding bugs that need to be fixed. And it’s more than
you thought you’re discovering things you didn’t realize were there. And I, I mean
the releasing frequently, it mitigates all of that. I mean you start finding things so
much sooner, you start discovering these things so much earlier on, and then you
can, you know, you can account for those things because you’re finding them, you
can manage those things for sure. So vision, goal alignment, coordinated planning,
frequent delivery transparency. Also another principle as people are scaling up.
Yeah, yeah, absolutely. Especially as things get more complicated.
Adam Ulery [27:07]:
So if you’ve got one team building something, that’s, that’s complicated enough
because of the nature of our work, but then you, you know, every time you add a
team, it, it greatly increases the complication because those teams are you, you
know, they’re doing things within their own team and then across teams, there are
things that impact each other. And, and so as that increases the need to have
everything about the process and the work and the flow of work and the
management of the work, all of that transparent it becomes almost crucial, right?
So if it’s not easy to see information about the flow of work through our teams, it
becomes extremely difficult to do all the things we just talked about with
coordination and alignment, et cetera. And then there’s always gonna be the the
squeaky wheel manager.
Adam Ulery [28:08]:
Who’s not closely associated with the effort, but needs to know the, the general
status of it and, and the progress of it. And, and they’re gonna demand that and
that’s gonna become a real pressure. It’s so much easier to provide them with what,
what they need, if everything’s fully transparent. I mean, one of the ways to do that,
that, that we commonly use is, is with boards, right? Like a, a combo board or a
scrum board and, and work item cards, you know, user stories and, and just making
all of that visible. And then it’s easy to report on those things. It’s easy to show
those things, to roll them up to pride forecasts all of that, but it’s crucial to be
transparent and and show the information and show the data and be honest about
the actual situation or agreed.
Dan Neumann [29:07]:
And I get the sense people don’t intent if people who are intentionally deceiving,
that’s a whole nother problem. But I imagine if you will, that people are trying to do
their best, the data hygiene takes effort putting, you know, just making sure that
the status is correct, and there’s good attention to the product backlog, all that’s
stuff takes effort and, and care and feeding. But boy, when it gets out of sorts and
muddy, now you don’t have information to make decisions with. And so again,
whatever scaling approach an organization evolves into making sure that it fosters
transparency to the work is, is key. Yeah, it’s crucial. Right. And the last one just to
touch on here is making sure there’s an appropriate amount of alignment around
the technologies involved. Right. So with the technologies, I, you know, I think we
just want them to work with each other and, and probably not have a redundancy or
overlap of those things.
Dan Neumann [30:12]:
So you know, just, they don’t, I guess they don’t necessarily have to be the same,
but we just want them to, to work well together. Right. I, I think coherence is the
term for me that comes to mind. We don’t have to be consistent, meaning you and I
do the same thing for everything, but some degree of coherence, a as well as
transparency, here’s what I’m doing. And here’s the why, what is your team doing
and why? And maybe we work together over time to bring those into more and
more consistency, but as long as they’re coherent and it makes sense to use the
two together, I don’t tend to get too twisted up about making everybody be same,
same. Yeah. Right. Yeah. can, yeah, exactly. Well said. Yeah, for sure. So, well,
there we go. We’ve got some around scaling for folks that are maybe in a spot
where they don’t want to, or it doesn’t make sense to grab a, a scaling framework
off the shelf at the store and, and just pop it in and, and microwave, if you will,
their, their agile journey.
Dan Neumann [31:19]:
So, oh, clear vision, clear goals, frequent delivery of value, supported by planning
and transparency and, and then, and technology coherence as we go through any
closing thoughts you have Adam I think one thing that will come up, I, when, when
you start thinking about designing the framework and talking with the, the various
leaders and partners you’ll need to make it happen, we’ll, we’ll be around the, the
specific process itself. So, you know, when, when you’re designing that process and
you’re thinking about things like, okay, what are, what are the roles, what are the
meeting cadences? What, you know, what do we do in those? And, and how does
that all tie together? What are the artifacts we deliver from, from those, or are the
outputs, you know, what are the outputs from, from those events? I, if you keep
these principles in mind when you’re designing that, you know, I, I think it will serve
you pretty well.
Adam Ulery [32:24]:
And a lot of times in fact, I could say Al almost every time you’ll never end up where
you start. So, you know, try, try something out and set those expectations that,
look, this is gonna be a starting point. We’re gonna start here and we’re gonna learn
from this, we’ll pay attention to the results we’re getting. And we’ll use what we
learn to inform how we might modify this to make it work for us. And it’s gonna take
some time to get it where it completely serves you. But it’s, it’s more of an
evolution. It’s not thing that you will just install and it’ll be there. Perfect. And that’s
the way it’ll work forever. That totally makes sense. And what you described is a lot
of clarity around, like you said, processes and roles and expectations, and here’s,
here’s the reason for this event or this meeting or this synchronization point or, or
whatever the case might be.
Adam Ulery [33:20]:
Perfect. Good, good extra principle to keep in mind. So, Adam, what is on your
continuous learning journey as we get towards the back part here to the podcast?
Oh man, this is this is always a fun one to think about, but right now, right now, for
me, it’s it’s not agile stuff that I’m, that I’m working on. Yeah, it’s some, some faith
based stuff. That’s just real interesting to me. And that, that’s kind of, what’s in my
continuous learning right now. Very cool. Well, thanks for sharing. For me, it’s not
directly related to agile either, but more of a, more of a metaphor I’ve I think I
mentioned more than once, probably in this podcast, I have, have done running.
And as part of that, I have screwed up something in my back but much like a poorly
functioning organization. It’s like, yeah, something back there is not right. And I
can’t quite figure out what it is.
Dan Neumann [34:24]:
So it’s a book called back mechanic and, and much like systems, the, the spine and
everything that goes with the spine is so much interdependency and little pieces
and parts and things like that. So I am going on a, an inspect, an adapted journey
now for the last well, for the last year I’ve been dealing with it. It’s like, okay, how
do we how do we first eliminate the pain and then go about kinda rebuilding there.
So, wow. Wow, man. Yeah. It’s, it’s interesting. So a lot of metaphor in that, not so
much agile practices. Well, I’ll, I’ll tell you, I’ll go ahead and mention the name of a
book I’m reading right now, because it, the re is because it’s causing me to think
about things differently. And so it may be interesting to folks in the audience to, to
know that as I’m reading this and thinking about, first of all, it is it’s pretty deep
and, and it is forcing me to sort of just think about things differently.
Adam Ulery [35:21]:
And I think that’s important for how whole, of what we’re talking about, right? Like
we’re talking about scaling an agile framework. We’re talking about organizational
change on this podcast all the time. And that often requires you think about things
completely differently than you did. So the name of the book is called thinking
Orthodox understanding and acquiring the Christian Orthodox mind. That’s the
name of it, kind of a long title. Interesting. Yeah, it is. It is interesting. It’s very
interesting. And it’s forcing me to think in a different way. And I think that being
agile in your thinking is important, right. Especially as modern businesses continue
to evolve. It’s just important to be able to think about things from different angles
and decide what to do with that. Hmm. Yeah. I think back to I took a Christianity
class in college way back in the day from a really cool professor.
Dan Neumann [36:23]:
And you know, you start thinking of the different secs within Christianity. Some of
them have a creed, here’s the stuff we believe, you know, and if you’re in the club
that you, you subscribe to that belief system, some of them don’t, and, and it, it’s
just really interesting. And you think about that with organizations and agility and in
all manner of things in life, what’s the belief system, how structured is it? How much
is enough or too much? And yeah, it’s really interesting stuff. I will stop myself from
going too far. We could have a whole, that would be a whole another podcast, but
there are patterns like, and, you know, talks about it. There are patterns in life and
we see ’em in organizations. And so navigating those patterns can be helpful. I may
have to get that book. Thanks for sharing Adam. Appreciate it until next time. Thank
you.
Intro [37:14]:
This has been the Agile Coaches’ Corner podcast brought to you by AgileThought. The
use opinions and information expressed in this podcast are solely those of the hosts
and the guests, and do not necessarily represent those of AgileThought. Get the
show notes and other helpful tips for this episode and other
episodes@agilethought.com slash podcast.
Share this content
Dan Neumann
Dan Neuman is the Director of the US Transformation and Coaching practice in the Agility guild. He coaches organizations to transform the way they work to achieve their desired business outcomes.
With more than 25 years of experience, Dan Neumann is an experienced Agile Coach with a deep knowledge of Agility at the team and organizational levels. He focuses on achieving business outcomes by shifting both mindset and practices, resulting in a disciplined, yet practical approach to solving problems.