Business agility is a set of organizational capabilities
behaviors and ways of working that afford your business.
The freedom flexibility and resilience to achieve.
Its purpose no matter what the future brings capabilities,
behaviors and ways of working many organizations will adopt
the ways of working, but they don't change the behaviors.
And they don't create new capabilities in the
organization. And so would say that they're
doing agile, not being agile. And that's unfortunately quite
limiting. So you need all three to be
effective. Hey everyone.
My name is Henry Surya with Robin.
And you're listening to the tekhelet Juno, the show will be
bringing you the greatest technical leaders practitioners
and thought leaders in the industry to discuss about their
Journey ideas and practices that we all can learn and apply to
build a highly performing technical team and to make an
impact in your personal work. So let's dive into our Journal.
Hello again, to all my listeners out there.
It's great to be back here again with another new episode of the
tackling Journal podcast. Thanks for spending your time
with me today, listening to this episode.
If you haven't, please subscribe to technology, you know, on your
favorite podcast apps and also follow our social media channels
on LinkedIn, Twitter and Instagram.
And you can also make some contribution to the show and
support the creation of this podcast by subscribing, as a
patron at pack leader. No dot f, / Patron, and help me
too. Producing great content every
week for today's episode. I am happy to share my
conversation with Evan laybourne.
Evan is the founder and CEO of business agility Institute and
international membership, body to both champion and support
next generation of organizations that are agile Innovative and
dynamic in this episode, haven't shared about the current
maturity of a jar. Adoption and how agile has
matured over the years by looking at three different
agility. The categories technical agility
process or operational, agility, and business agility.
Evan then explain further what business agility means and his
interesting story of why. He eventually started the
business agility Institute. He then explained in depth the
concept of business agility domains, which is a Model
comprising, 12 different interacting domains across four,
different dimensions centered around the customer.
We then discuss about his theory of age are constraints borrowing
from the original theory of constraints introduced by dr.
Eliyahu. Rat and in his theory of age are
constraints, even shared his insights on.
Why he thinks a jar and devops Transformations are currently
hitting diminishing returns and how we should address this
situation by continuously, finding the constraint to solve
within an organization in order to become truly agile during our
conversation. Evan also touch on and shared
about the recent business agility Institute, research,
finding on why many HR organizations.
Leslie fail to embed and support, diversity, equality and
inclusion, or DUI within the organization's an interesting.
Finding that look at the intersection between a gel and
d. I, I really enjoyed this
conversation with Evan and I hope you will enjoy this episode
as well. Consider helping the show by
living it a rating review or comment on your podcast app and
social media channels those reviews and comments are one of
the best ways to help me get this podcasts to reach more
listeners. And hopefully, they can also
benefit from all the contents in this podcast.
So let's get this episode started right after our sponsor
message. Are you looking for a new cool
swag tekhelet Journal. Now offers you some swags that
you can purchase online. These wax are printed on demand
based on your preference and will be delivered safely to you
all over the world where shipping is available.
Check out all the cool swag is available by visiting
technology. No, dot f / shop and don't
forget to brag. Self.
Once you receive any of those tracks everyone, welcome back to
another new episode of the package.
You know, today I have with me, everyone Laybourn Evan is the
founder and CEO of the business agility Institute, which is an
international membership body to both champion and support the
next generation of organizations, which are the
companies that are Asia Innovative and dynamic.
So today we are going to talk a lot about business agility and
things related to that. So Evan.
Thank thanks for being on the show.
Hoping to have a good conversation with you about
business agility. Thank you Henry.
I'm really looking forward to it.
It's gonna be a good conversation in the beginning
event. Maybe could you introduce
yourself for the audience who may not be familiar with?
You may be highlighting or turning points or major
highlights in your career. Of course, I'm currently living
in Melbourne, Australia, but that's a fairly new thing for
me. I have spent the last 15 17, 20
years working and Traveling all over the world.
Now, obviously, this is the tech lead Journal, it would be
worthwhile to share, where I started from a technical
perspective. I was a programmer web
applications primarily back in the late 90s and early 2000s.
PHP being my development system of choice.
I know it's not the most flashy programming languages, but it
did the job. This is like, packing like the
PHP 4 days. And so, let's be honest.
It did the job pretty badly. I think it's a lot better now.
Now. But in around 2003, I got
exposed to this thing called agile and I say that with a
capital, a scrum and XP primarily at the time and
started to use these techniques in the development of the
software products that we were building.
At this point. I transitioned into sort of
Information Management Systems data warehouses and web-based
data warehouses, which were their dime, a dozen these days,
but they were very new back then those really Citing, I don't
know if any of your listeners are really in the data
warehousing or business intelligence space, but I can
tell you that back then data warehouses and business
intelligence systems failed a lot companies would spend
millions and millions of dollars building these systems only to
get 0 return on them. And so, agile was seen as a way
of closing that feedback loop making it tighter getting more
insights from the data. Data quicker without necessarily
building everything all at once. And we did a pretty damn good
job. If we fast forward a little bit
to about 2008, at this point. I've joined the Australian
Public Service. There's a concept called the
Peter Principle, which is being promoted to your level of
incompetence that maybe a little bit of a joke, but this is where
I was, I became the director of business intelligence for a
government agency. I was a good team lead.
I was a good programmer. I was a good database.
Data, but I wasn't a good director.
There were skills there that I never learnt that you don't
learn in University. You don't learn when you're
building software products. And so I had an epiphany.
Well actually, to be fair, my boss pointed out that I wasn't
doing a good job. I can't say I had the Epiphany,
my boss pulled me into a room and it's like, you've got to get
better. Otherwise this isn't going to
work out. So I started thinking about the
challenges I was facing Seeing as a director around, getting
teams divisions and functions across multiple government
agencies, because we were doing a whole of government program.
Getting them to cooperate and collaborate with each other,
getting that coordination of work and budgets and all those
kind of things. But if you think about it,
cooperation, collaboration coordination, these are things
that agile. The capital A did really well,
obviously, in building software products, but I had this sort of
like a half moment. It was like, if these
principles, the agile, Manifesto the principles, the values and
the practices work, well to solve these patterns of
problems. Maybe they'll solve these
patterns of problems in another context, in which case, in a
business setting, long story short.
They did, that's sort of what got me into this space that we
now call business agility, back then to be honest.
It was more like agile business but in the intervening 12 13
years, I've been both holding my own I own skills and experiences
around business agility and helping organizations on that
same path. So, the most recent thing, three
years ago. I left the Consulting world and
co-founded the business agility Institute, which Henry as you
very nicely mentioned. We're a professional
association. We have members in 60-plus
countries. We don't do training.
We don't do Consulting but we do research to actually have 14
research teams, exploring different.
Assets of business. And I suppose what that looks
like. That was perhaps a long answer
to your question, but there's Evan in a nutshell.
So, thanks again for sharing your story.
I think one thing that I noticed is when you mention about a gel
with capital A, so maybe we can share a little bit.
What do you mean by Asia with capital A?
And is it common to say, Asia with lowercase a now when we say
a job with a capital, A we use that to refer to the agile
Manifesto and And the agile practices and Frameworks.
It is the thing called agile, the noun, whereas a draw with a
little a it's the verb. It's a thing that you are.
You have agility. You are agile.
You do Agile with that capital, A now.
Yes, there's a whole agile Manifesto, which is values and
principles is not as clean cut as that, but if we say agile
with a capital, A, we're really just referring to that broader
context the practices and so forth.
So you mentioned about all these experience that you have and you
also now have business agility. Maybe a nutshell.
What do you think is the current maturity of Asia adoption.
I mean, it's been around for, I don't know.
More than a decade. I would say probably.
Yeah, and what do you think is the current adoption of
companies familiar with it? They are able to introduce that
and be more jails. Let me separate this into three
categories of agile. This is just Evan how I see it.
This isn't some Vishal? How agile is defined?
But just for the sake of answering the question, let's
look at it in terms of technical agility, process or operational,
agility, and business agility. So technical agility is things
like XP back in the day. It's not the project management
rappers, but it's rather, how you write code.
It's devops. I remember back when I was a
techie. We didn't have continuous
deployment back then, but we definitely had continuous
integration. So this was a fundamental Part
of the agile work that we were doing.
We had to have this technical agility, this ability to create
products that were modular. So it touched architecture it
touched design, it touched delivery, the actual writing of
code. Now, I would say that over the
years. We have got very good at this in
part because it's something that can be repeated, devops as a
concept. I know some of y'all As May
object to me, linking devops and agile.
Because I know some people think that they're completely
different things. Hence why I'm using agility, not
agile per se, but devops and the professionalism around that
operational aspect of the business.
Actually. I think took this technical
agility into a high level of maturity, across most
organization. We all know organizations that
are struggling. If we look at the process
agility, the operational agility.
And this is the Frameworks around project management around
product development around portfolio management.
I think this is Scrum. This is safe.
This is disciplined agile, though.
Some of those do go down in that technical agility space as well.
Organizations are doing okay. We've been doing it for a long
time. But there are elements of it
that are particularly culturally hard for many established
organizations. It's Young organizations,
generally, with a younger management base without that
inertia, without that 1960s management model or that 1980s
management model. They do quite well with this,
but the larger more established organizations, there's almost a
generational change that is occurring.
So if I pick say two examples, an example like Microsoft.
Now, I'm an open-source person. I still have a bun to on my
laptop. I haven't logged into it for a
while, but I still have a bunch of my laptop.
I ran the open-source developers conference in Australia, back in
2008. So I've always been embedded in
that open source space so I can remember back in 2008, 2007
2006, Microsoft was the enemy, Microsoft was the big monolithic
in many cases, evil organization, but I look at
Microsoft today with nothing, but a sense of Say almost pride
and respect they have managed to turn their organization around.
Now. It's not perfect everywhere, but
they are doing some pretty amazing things and a large part,
it comes from that agility, that generational change the Old
Guard, moved out, a new generation moved in into those
leadership roles into those program and project roles and
they brought with them and almost native agility.
Microsoft has gone in Incredibly well, because of it.
If I look at another organization like IBM, its older
more established, but it hasn't had and its trying in all
respect to IBM. They are truly trying to be an
agile organization, but they haven't really had that
fundamental shift of culture and generational leadership across
all the different elements in all openness.
I actually used to work for IBM. So there are pockets of great
agility, some of the greatest thinkers.
Irene IBM. But the organization as a whole
doesn't have that they have pockets of agility whereas
Microsoft has pockets of an agility, so it's possible but
that's that difficult. And then the third space is
business agility. This is where we're looking at
everything from finance and HR and sales and marketing and all
those kind of things. The industry in general is
fairly low from our research and your listeners will be very
happy about this. The number one industry in terms
of business agility, adoption is Is the technology Industries
Financial Services firms are in the top.
They were in the top three. They dropped.
I think the number 4. Interestingly manufacturing
factories production firms are actually now in the top three.
So, it's been quite interesting to see how they have gone from
this lean perspective to this lean agile perspective.
And so they're growing, but still, very young industry.
It's sort of a while to go before before companies.
That shift effectively. So, thanks for sharing this
statistic. I mean, it's very interesting
for me. Personally.
I've worked in the financial services long way back.
I thought that they would be more mature in terms of
adoption. But you mentioned that
technology space and Manufacturing are in the top
three. So what is the other 10
consulting firms? That's an interesting space
because consulting firms. They often experiment on
themselves. I'll be blunt.
I don't mean the big ones. The really big for consulting.
Firms aren't agile. The slightest and you all know
who they are. So I won't say them out loud.
They have very limited agility. They'll do it to others, but
they struggle to do it to themselves.
But there are tens of thousands of small to mid-size consulting,
firms. I'm talking 10 people up to
about 150, 250 people. These firms are exemplars in
business agility, in many cases, because they do it to
themselves. They become Consultants to try
and help other organizations. Because they believe in it
because they believe in it. They're doing it themselves.
The big four consulting firms. Obviously that plays is that
Microsoft IBM game of generational change is going to
be required. So I think it's also a good time
now to move into the topic of business agility, which is the
main theme for today. So maybe if you can explain
again what is business agility in short and why did you come up
with the institution? It's pretty interesting to me.
What is business agility? Let me give you the definition.
And as we Define a business agility, is a set of
organizational capabilities, behaviors and ways of working
that afford your business, the freedom flexibility and
resilience to achieve its purpose no matter what the
future brings. So, let me touch into a couple
things capabilities behaviors and ways of working in reverse
order, the ways of working is what you do.
That have behaviors, is what you're expressing.
And the capabilities is what you've achieved.
If you've W those three, then you've got a good foundation for
business agility, many organizations will adopt the
ways of working, but they don't change the behaviors.
And they don't create new capabilities in the
organization. And so would say that they're
doing agile, not being agile. And that's unfortunately, quite
limiting. So you need all three to be
effective. The second point I want to
highlight, is to achieve, its purpose or to achieve your
purpose organizations. Exist for a reason and that
reason is sometimes very obvious.
We exist to serve a customer. We build a product.
We serve a customer in a particular way and some cases it
might be a little bit more hidden a government organization
or a not-for-profit. But there's a great quote by
Frederick lelou profit is like the air.
We do not live to breathe, but we do need to breathe in order
to live. So what does that mean as an
organization? Your purpose isn't to Make
money. Your purpose is to serve your
customers. Making money is how you know,
you've served your customers. And so we see a lot of
organizations get that round the wrong way.
The customer is secondary to making money in those companies
tend not to last more than five to ten years.
Those companies who get that customer centricity are the ones
who especially right now in a very Dynamic, very unpredictable
Market other ones who are doing quite well.
There's another concept called. Job to be done.
The concept of job to be done, is when you go and buy a drill,
you're not buying a duel because you want to drill, you're buying
a drill because you want to hole, and you want to hold
because you want to put up a set of shelves.
So that drill company isn't in the market of selling drills
there in the market of selling holes and helping you build
things. So, if there is some issue with
the sale of drills, for example, there are supplier problems, or
Three issues or the EU says, you can't sell to them anymore.
You can't import drills for whatever reason.
I know that's for silly example, but just bear with me those
organizations who see themselves as we sell drills have a
problem. Those organizations who the see
themselves as we serve our customers to create holes.
They're the ones who can then, look at that problem from a
different perspective and go. How else can we serve this
customer? How else can we sell?
Or what else? Can we do?
What else? Can we sell that in a Tables the
customer to do what they want to do without selling this drill,
that we can no longer sell for whatever reason.
That's a silly example, but there are real fundamental cases
where. That's true.
Look at Kodak, Kodak believed they were in the market of
selling chemicals and machines to print shops, to allow print
shops, to print your photos. And so the customer, the Kodak
was the print shops. Not the person who's taking the
photographs, they Forgot that they were in the market of
allowing people to capture memories that was in their
marketing that Kodak moments kind of thing, but their
marketing wasn't replicated in their business.
They invented the digital camera, but they were so tightly
bound to their existing markets, their existing customers, that
they forgot who they were in business for and they paid the
price for it. When you set up this bizarre.
At The Institute. What is the purpose behind it?
Why do you think an Institute would make a sense for people to
join and maybe learn from each other?
Of course. So I can never set out to create
the institute in 2016. I was in India.
I was speaking agile, India conference, and I was talking
about business agility, as it's what I talked about, what I've
always spoken about. I was with IBM at the time, but
afterwards, I was sitting down with a friend of mine and we
were talking about About the problems that we had with
existing agile, conferences, and do me wrong.
I love agile, India other than 2020, for obvious reasons.
I've been to that conference every year for almost 10 years,
but when you talk business agility half the time ever in
the room nods and goes. Yes, we need this, but they go
back to their offices and nothing changes.
And so I was the menteng I was very frustrated about this to my
friend and she said, well, why don't Don't you create a
business agility conference? That's like all right, I will.
So in 2017. We launched the first business
agility conference. This was in New York.
I was living in Singapore at the time.
I have to admit running a global conference.
Literally. The opposite site is a 12 hour
time zone difference. It was not pleasant, but I
walked into that room. I had a fairly arrogant
assumption. I assumed because I've been
talking about business agility for at that point.
Eight or nine years. I That I would know most people
in the room, 80%, I was wrong. I knew maybe 20%, maybe less,
maybe 10% of the companies and the people in that room.
We sold out by the way, it was a huge success.
What this exposed to me was that there was this untapped pain
people, wanted to talk about business agility.
They wanted a space to call their own, that wasn't in the
agile world. That wasn't in the technology
world. Old but we're a CFO and a chir
row and a transformation consultant, and people who were
wanting to see businesses change to create a space where by they
can have that conversation to the conference was a success.
And up the conference. We started planning the next
event, which was obviously a year away completely
coincidentally. I had to move from Singapore,
back to Australia for family reasons.
I do miss Singapore. I'd move back there in a
heartbeat if I could. Love sample, but so I had to
move back to family reasons. And so I had to resign from IBM
because I was employed by IBM. Singapore.
I'm there going. What do I do?
I've got to get back to Australia.
I could join. IBM Australia.
I am. Singapore was pretty good.
I enjoyed our AVM, Singapore. I didn't think I'd enjoy IBM,
Australia, or anywhere near as much as I enjoyed the work.
I was doing at IBM. Singapore.
Do I join another consultancy or do I join a firm like a bank and
help them with their transformation.
There was nothing in my heart that so went.
Yes, that's what I want to do. I kind of felt that part of my
career was over paid well, and I certainly was making an impact,
but I then thought about what I enjoyed and I thought about the
conference. I thought about the impact we
had I was talking to a gentleman called Achmed Siddiki.
I was saying it's like, I don't want to run events.
I'm not an event planner. The event is a means to an end.
It's a way of bringing people together.
Is it possible to create a business?
That brings people together? And that's where the Institute
formed from is to create that space for those conversations.
Now, I'm going to jump forward six months because when we
started, we had a particular Vision.
We were going to events around the world.
We were going to have a library of content and material to
inform people that business agility about six months later.
I was actually ironically at the same conference in India, where
this whole thing started. I was listening to a talk by a
lady called Linda Rising. She's amazing.
If you've never heard her speak, I suggest you check out some of
her YouTube videos. She got her PhD in information
technology. I think when she was 60 or
something, absolutely brilliant, and she said, ironically the
plural of anecdote is not data. Now, that's actually an
incorrect quote and there's a whole bunch of reasons why but
her point, which was very valid in the agile and in my case
business agility environment. So much of what we do is based
on an Don't it worked for me here.
Therefore it'll work for me there or it'll work for you
there and the assumption that because I've got it.
I've done it once. It must be true.
She was lamenting the lack of good evidence and research.
I realized at that moment in that talk that we were one of
the few organizations who could because we weren't selling
services. We weren't selling Consulting.
So if we were to do research, it could be trusted because We
would never sell Services based on that research with all
respect to a lot of the other organizations.
In this space. They're either selling
Consulting. They're selling certification.
And so they say agile is great. And then in the next email,
they're saying by our services or become a certified X.
The credibility isn't there. I'm not saying they're wrong,
but the credibility isn't there. So we decided that we would
become a research institute so we actually, Gear.
After about six months. This is what business agility
is. It's about changing, what you do
to better serve your customers. So we became a research
organization. So now we have that professional
association. We still have the events in New
York and we have a couple of others around the world, but
we've actually scaled back events actually.
Start scaling back events before covid, seems prescient.
Now, we now have 14 research teams.
We just launched our research on agility, on the relationship
between agility and diversity, equity and inclusion.
The problem with being a research organization is, if we
have negative findings, we still have to publish them.
Let us put this way. Agile organization, do not
score. Well, in general, in terms of
d&i in many cases, it's not because they're doing agile
badly. It's because of our job.
So there are things that need to be done to improve some of the
agile practices and Frameworks to embed DNA better into them.
Sometimes we have to publish things that actually say.
Hey, yeah, maybe we're not so crash right after all.
So, I'm pretty interested in why some of these agile
organization, not actually making good scores on the, what
are some of the hindrance in your research?
Probably if you can share with the audience.
Yeah, absolutely. So well, there's a couple of
things. First of all, de9 I is implied
with in agile, but it is not explicit.
So what does that mean? That means that we say
individuals and interactions over processes and tools but you
know what, we assume that it must be there, but it's not And
therein lies the problem. The second thing that we do as
the focus on transparency, the focus on rapid communication,
even practices like the daily stand-up.
It's designed for people who are neurotypical, they're able to
think fast. They're able to talk fast.
They're able to engage in a public social setting without
hesitation, whereas neuro-diverse people who may be
introverted. First people who may have that
kind of Social Challenges really struggle.
And now the issue is around the even, just a technology in the
tooling. One of the researchers have a
visual impairment actually, one of the things that we discovered
from this. His organization went through a
big agile transformation, and he ended up leaving the
organization because they went from MS project or whatever
else, which don't get me wrong. MS project is the worst my
project management days. I really hate that product, but
at least it's what a screen reader.
He could know what was going on because it would speak it out.
He could zoom in, he could see what little vision he had.
He could read and he could hear. Whereas when everything
transition to post it notes on the wall.
He can't read it. He can't see it.
So he can't actually do his job anymore and worse the
organization, because D, and I wasn't embedded in that as a
principle. It wasn't even considered.
We say individuals and interactions, but we don't,
there are also cultural issues. Let's be blunt.
Where do the agile Manifesto? So, come from 17 middle-aged
white men back in February, 20, 20.
I was in Nigeria launching the business agility conference in
Africa. There was a speaker there
talking about what African agility looks like because it's
really interesting and it's really challenging.
There's this huge culture of respecting your elders.
But what happens if you are a young scrum Master trying to be
a servant leader with developers or team members, who are Older
than you. There is this cultural conflict
that emerges that was never considered in the design of any
agile practice because that's really not a thing in America.
This is just some examples. There is a lot more in any of
your listeners. Can go to our library and
download the research report because all of our researchers
public. So you can find out more that.
I'll make sure to put it in the show notes later on.
So thanks for sharing the findings from your research.
Actually. It's pretty interesting because
now that I heard it completely makes sense to me because I see
some of the introverts may not be able to fully be embedded
inside of some of the practices of a child just like daily
stand-up or maybe retrospective. So I think yeah, it's pretty
interesting research. I'll also probably read up to
know more about this as well. The other thing about business
agility. I saw from your website is that
you come up with these domains so many different domains except
principal or The Guiding framework behind business
agility, and we can you share a little bit about those domains.
Yes. So the domains of business
agility, we're actually One of the very first things that we
published as a piece of research.
In fact, it actually wasn't meant to be research.
It wasn't meant to be something that we publish.
It started out as a blog post. I was just writing about what I
thought were the characteristics.
That the mains the business agility.
I finished the article. I just happen to be going to
surgery that day. It was just a surgery but I put
it up on LinkedIn to my followers and was like, Hey,
I've written this post. Here's a Google Docs link.
This is what I think the demands of business agility, our love,
your feedback. Can you follow the link?
Add some comments that kind of thing.
So I come out of surgery and obviously the first thing that
you do, when you come out of surgery, is check your email.
I have my email and I look at this document and there's about
60 people having a comment War about what business agility
meant. So what started as a blog post
effectively then turns into this big Community consultation which
then turned into a grounded research study on what are the
characteristics of an agile organization.
Now, when we look at this, there are Characteristics.
Now obviously this is a podcast so I can't show you the domain.
So I'll just highlight a few key points.
The first is at the very heart of the model, is the customer.
Now, there's a big argument as to who's at the heart.
Some people said it should be the customer.
Some people said it should be employees.
Some people said it should be shareholders and there's
Arguments for each shareholders, owning the business.
You look after your employees. They will look after your
customers. That's a pretty good train of
thought. But the reason we put customer
at the center was and I think I mentioned this earlier before
your customer is why you are in business.
Simon sinek Says start with Y because they represent the
purpose. The reason you exist.
We put them at the heart surrounding the customer are the
three domains that we call relationships, Workforce board
and partners. Workforce is an interesting one.
In an early version. We had employees, but the
problem is there's contracted. It doesn't matter what your
legal employment type is. You still need to be.
That that so Workforce is a generic term that encapsulates,
everyone who creates value the board of directors, because the
shareholders are important and they do represent agility.
They're also ironically the third this people from the
customer. So if they're making strategic
decisions around the organization, around the
direction, around the hiring of the CEO, all that kind of thing.
If they don't have some customer centricity of themselves,
they're going to be making poor misaligned decisions and then
partners because the Agility that you can express as an
organization, may be limited by things, outside your
organization, your suppliers or Distributors.
Let's say you have distributors or agents or vendors and so
forth. If they're the ones who are
talking to the end users and you get your feedback from them.
What's Amazon statistic, they can release a change into
production, every 11 seconds, something like that.
So gay for devops, but if you can release change every 11
seconds, but You can't get feedback or your Distributors.
Can't take that change. Give it to their customers and
give you feedback. If they can't do that quickly.
Let's say it takes them, six months.
Your agility is not measured in seconds.
Your agility is measured in months.
That's why Partners is one of the key, domains three
leadership, terrains, three, individual domains and three
operations. Domains the leadership domains
of people management one team and strategic agility.
These refer to To the capabilities of leaders and the
behaviors of leaders people Management's.
One that I take to heart in part because of my own personal
experience of being a bad manager, but we know that
management accounts for something like 70 to 80% of
Employee Engagement scores. We know that people leave
organizations because of bad managers more than anything
else. So management is such a vitally
important capability inside agile, organizations, but if we
think about Managers, what do we think about the managers from
Office Space or the office? We think about the pointy head
boss from Dilbert. Managers are at best incompetent
or at worst. Evil.
Everyone wants to be a leader. No one wants to be a manager and
unfortunately management is a skill and it is such a vital
skill. So we are on a quest to reclaim
management because management is good and it is important and
there are bad managers. Yes, but to all the listeners,
think back in your career, think back to the best manager.
You've ever had and the job satisfaction that you had there
and the opportunities that arose from that.
I think you'll find that. For most of you that good
manager is what makes such a huge difference.
The individual domains the growth mindset ownership and
accountability. And craft Excellence, for this
audience, craft Excellence is going to be, I think a Hot Topic
because I've seen a lot of organizations kick off an agile
transformation because they have a lack of Old in their
development teams, and they think that it's very expensive
to go and train everyone in the latest version of Java or
whatever else, hiring they hire cheaply.
And I'm sure you've all worked with people, where you look at.
Like, how did you get that job? You're not doing what you need
to be doing the issue isn't Jilla T.
The issue isn't scrum. The issue, is the fact that they
don't have the skill to do the job.
So that craft excellence and don't have to be development.
This is accounting. Or marketing, whatever the craft
is has to be done with an embedded sense of quality and
purpose, and then the three operational, domains process
agility, Enterprise agility, and structural agility.
Now, process agility is where most Transformations begin.
That's transforming a process. An organization is not just a
process, the software development process, great adopt
scrum, and that gives you an agile process around the
software. Life cycle, oh, agile marketing
around the marketing process or Beyond budgeting for the
budgeting process. This is where something like,
theory of constraints comes in. You've got other processes that
feed in, you've got recruitment. You got budgeting, you've got
deployment, you've got security. You've got pmo hundreds of
processes weaving in and out of various points in the software
development life cycle. And so Enterprise agility is
creating agility, not just in that process, but in the network
of processes and the Relationships between them and
then structural agility is around how an organization
creates agility in the way teams are formed.
Those of you who have had the misfortune to be part of an
organizational restructure around squads and tribes.
It's not a bad thing. It is actually an element of
business agility. A key element of structural
agility. Is this concept of no handoffs a
functional hierarchy where a June developer reports to a
senior developer who reports to a deadly to reports to a head of
development. That is nothing more than A
modern implementation of a thousand-year-old Apprentice
system where a Apprentice blacksmith apprentices to a
Master blacksmith to learn the skill because The Apprentice
system is designed is optimized for skills transfer.
So the functional hierarchy is optimized for skills transfer or
what happens here is that at a certain point I don't need a
cross-functional team of multiple disciplines to shoe a
horse. I need one blacksmith who knows
what they're doing. That's it.
But there is not a single modern product that I can think of that
can be done with one person with one skill.
It requires a team and a team with different skills.
Now, in software, we can figure this out because I haven't seen
an organization with a separate. Devon testing for 10 years and
that definitely was the case. But outside of software.
We still have these functional hierarchies.
So the value of structural agility is to reduce those
handoffs in the system to optimize for the Lower value
through the system, which then actually ironically sub
optimizes for skills transfer because there's always a
trade-off. So that's why Spotify has that
chapters and gills to try and counteract that sub optimizing
for skills. The problem is that many
Transformations. They forget, they start adopting
scored some tribes and they restructure.
But they don't really look at why they're restructuring.
They're doing it because they think they should.
They're doing it because everyone else is and they
actually end up designing a system that is No better.
You may have all pivoted 90 degrees but still got the same
number of handoffs between you and the customer and so no
agility is actually been created, so it can help.
But two blunts more often than not.
It doesn't, that's pretty much the domains and there's a lot
more to it. Obviously we think of this as
it's not a framework, you can actually create a framework for
business agility. This is a characteristic model.
I think of it. As the don't forget model, if
you're going to change an organization, these are Things
not to forget. Thanks for sharing all these.
There are a lots of the concepts inside.
All the domains definitely for people who are interested.
I think you can refer to the website and find out more.
I'll also put it in the show notes.
One thing that probably we can go deeper because you mentioned
a couple of times. It's about your theory of age
are constraints. Actually you wrote about it a
few years back if I'm not wrong. So maybe you can explain to the
people here. What is theory of constraints
for support? And why do you come up with this
theory of Of age are constraints.
The theory of constraints comes from a book called, the goal by
Eli Gold rap. It's very simple pattern.
It says that in any process, There's a constraint to the
process. Let's say that you're a
production line building cars and it takes you five minutes to
install the engine and that's the slowest part in the system.
That's the constraint. So it means that cars can roll
off, that production line, every five minutes.
You can't roll them off any faster.
It means that if you try and optimize or transform any Seemed
like the wheel team. You're actually not going to get
those cars rolling off the production line, any faster.
So you transform the engine team.
So now it takes three minutes to install an engine.
But the thing is, the theory of constraints, the corollary is
that there is always a constraint.
And so, the constraint is, let's say, it takes four minutes to
put the wheels on. Now, that takes three minutes to
put the engine in the car is not rolling off in three minutes,
the cars running off in for because the new constraints of
the wheel team. Is what's limiting in it?
So there's always a constraint to the system.
Now with apologies, that your leg old Route, I talked about
Evans theory of agile, constraints.
That is that in any organization, There's a
constraint to agility and that's probably not it anymore.
I'm going to take you all back to the 60s.
I think it was 1969. The first conference was a
conference on software, engineering at the time.
There was a thing, called software crisis, and this was a
crisis of identity, a crisis. Faith.
We're all of these developers and programmers didn't feel like
they were being taken. Seriously.
They looked at the professions engineering and law and they
looked at how professional those industries were and said, we
want some of this. So, as part of this, they
created this software engineering concept, which takes
let's be honest, a a glorified version of engineering and
applied it to software to Evelyn what they took wasn't even
reality for engineers. It was this hyper formalized,
the pendulum swung too far for that way.
So what happened was that fast forward to about the 80s and the
constraint to agility, was the software teams because it would
take three, four, five years to bring a product to Market first,
then fast forward to about the 80s, the 90s and 2001.
It's very logical for Capital, a agile to emerge in the software
world. Was that was the constraint to
agility software, teams could move faster.
That's what agile was meant to do, create those feedback loops
create better products. Get the first version to Market
in a matter of months. Not in a matter of years.
But remember, there's always a corollary to theory of
constraints. Late 90s, early 2000s.
You have agile and this is where I come into the world.
As I remember. I was a techie back in 2003
signed to use agile. So I started using scrum
fantastic, I could have Ave potentially shippable product
increment, every two weeks. Fantastic.
Where did it go? Because didn't go to the
customer because we had a release window and that release
window is a minor release every three months and a major release
every six months. And for those of you old enough
to remember what released windows were like.
Oh, that was fun. I say that.
No, it wasn't. It was not fun at all.
So even though we were able to create, this potentially
shippable product increment, every two weeks.
We couldn't actually deploy them until six months later.
Our agility, it was known as measured by years, but it wasn't
measured by weeks. It was now measured by months
because operations became the constraint.
Devops really became a thing after Tech.
Stop being my day-to-day job. The devops was the way of the
industry, addressing the constraint to agility in the
system. So now we have Amazon statistic,
every eleven point, three seconds or whatever it is, so we
can deploy change. Now in seconds, but remember the
corollary there is always a Restraint, if you can create a
shippable increment, every two weeks, if you can deploy in
seconds, but it takes you three or four months to hire the right
person. It takes you nine months,
either. Budget change approved.
It takes you six or seven months to get a vendor engage.
You have to wait for the next project control board to approve
the next phase gate, or whatever process project that you're
running. Despite the devops, despite the
agile. Your agility is By HR or Finance
or the pmo or compliance or wherever happens to be inside
your organization? So a large part of business
agility is actually just finding the constraint figuring out
where to apply or create agility within the system because it's
what stopping your teams from going faster.
This is why business agility is so important.
Even for Tech teams right now. Agile transformations in devops.
Transformations are hitting diminishing returns.
All because the investment in the transformation is no longer
at the point of the constraint. So for you and your teams for
all the listeners out there for you, to actually run at the
speed that, you know, you can run at.
We have to address the constraint to agility in the
system, not necessarily in your team more, devops more capital.
A agile is in many organizations, not going to help
because that's not where the constraint is.
It's like optimizing the wheels. When the engine team is the
constraint, so that's pretty much sum up.
All the latest that we have in this world.
Probably also in the software development, or the devops will
things are pretty great because we have new techniques, new
tools, new practices, whatever that is, but I hear what you say
is that from other parts of the business, like the hiring, the
budgeting the procurement approval, probably also need
some kind of new practices, theories or tools, and all that.
So that wraps up our discussion about business agility due to
time. But before I let you go Evan, so
I have one question for all the guests, which is about three
technical leadership wisdom. So, can you share?
What are your three technical leadership wisdom for us?
So, first is I define success in business, and in technology,
with three things, competence, empathy, and confidence.
I'm assuming most of you, as listeners are competent.
You're good at your jobs. You wouldn't be listening to
this kind of podcast. If you want, you're there,
you're trying to learn empathy. Is just as important because
competence without empathy is arrogance.
So you need to listen to others, listen to your customers, put
yourself in their shoes, think about others, from their
perspective. And the last is confidence,
which is the ability to stand up and stand your ground.
The ability to say, I've got an idea and as about and the
empathy, lets you say, oh my idea was wrong, but the
confidence is what puts you forward.
And if you have those three things competence, confidence
and empathy. And then that is how you're
going to be successful in any role that you take on.
Those are the three things. Those are three skills that you
all need to develop. Well, it's short concise and
pretty insightful actually. So I agree with the confidence
part as well because sometimes you may be competent and you
probably have good empathy. But if you never speak up or
give it a try, at least you probably won't go forward as
far. Yes, you can.
It's actually worse than that competence and empathy without
confidence. You may be trustworthy, but
people may not trust. You.
Humans, We Trust confidence. We shouldn't because often
confidence and empathy without competence is fraud.
Let's say we see that in a lot of politicians, but if you have
competence empathy and confidence, you will be trusted.
You'll be seen as trustworthy. But if you only have two of
those and Missing the confidence, then the people
around you, your bosses their bosses.
Maybe your boss. Knows your peers.
No, but your boss's boss and your boss's boss's boss.
They either won't see you or they won't be able to build that
personal sense of trust with you.
Not because you're not trustworthy just because you're
not expressing it. Pretty insightful.
Reminder, for actually all of us, especially the pakis.
Some of us probably are not the most confident individuals in
any Company, so when you get a chance, maybe you should step up
and be more confident. So that like just what happened
said, many more people will be able to put their trust on you.
So thanks everyone for spending. Your time is really great.
So where can people find you online or about the work about
the research that you've done? So check out the business
agility Institute website is business agility dot Institute.
I'm still amazed at how many top-level domains there are.
In fact that dot Institute is a top-level domain.
Look me up on LinkedIn. My My only request is, if you're
going to connect with me on LinkedIn, tell me that you heard
me on this podcast. I get hundreds of LinkedIn
requests every week and I don't connect with people.
Unless I know who they are. I know how they've found me.
So tell me that you heard me on this podcast and I'll connect
with you. Thanks for sharing those tips.
So, thanks again, everyone. I wish you good luck with all
your business agility, you know, research and also, you know
trying to revolutionize so to speak the other parts of the
company that has not been Into more a gel thank you.
It's been a great conversation, and I hope I can impart some
good ideas. So thank you very much.
Thank you for listening to this episode and for staying right
till the end. If you highly enjoyed, please
share it with your friends and colleagues who you think would
also benefit from listening to this episode.
And if you're new to the podcast, make sure to subscribe
and leave me your valuable review and feedback.
It really, really helps me a lot in order to grow these podcasts
better. You can also find the full show
notes of this conversation on the episode page at tackle, the
journal, the death website including The full transcript,
interesting quotes and links to the resources and mentions from
the conversation. And lastly make sure to
subscribe to the show's mailing list on technology.
No, the deaf to get notified for any future episodes.
Stay tuned for the next technique Journal episode.
And until then. Goodbye.