Agile Podcast: Agile Coaches' Corner

Ep. 177

Podcast Ep. 177: How do I Scale Agile without using SAFe? with Adam Ulery

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

Transcript

    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.]

    ]

    ]

Speakers

Dan Neumann

Principal Enterprise Coach

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.

Related