Rob England ist als IT Skeptic weltweit bekannt und beschäftigt sich seit Jahren mit ITSM, Agile und DevOps. Wir sprechen über das schlimmste, was der IT passieren konnte: Projekt Management.
In dieser Folge des Podcasts „DevOps – auf die Ohren und ins Hirn“ sprechen die Gastgeber Alex Lichtenberger und Dirk Söllner mit Rob England, auch bekannt als der IT-Skeptiker, über die Probleme traditionellen Projektmanagements in der IT und die Vorteile des Übergangs zu DevOps und agilen Methoden. England argumentiert, dass traditionelles Projektmanagement oft ineffizient und ungeeignet für die IT ist, da es die Komplexität und Veränderlichkeit von Softwareentwicklungsprojekten nicht berücksichtigt. Er diskutiert, wie DevOps und Agile eine bessere Anpassungsfähigkeit, stärkere Teamdynamiken und kontinuierliche Verbesserung ermöglichen, und betont die Notwendigkeit einer kulturellen Veränderung in Unternehmen, um diese neuen Arbeitsweisen zu unterstützen.
Inhalt
- Einführung und Vorstellung von Rob England
- Kritik am traditionellen Projektmanagement in IT-Projekten
- Vorteile von DevOps und agilen Methoden gegenüber traditionellem Projektmanagement
- Diskussion über Dysfunktionen im Projektmanagement und ihre Auswirkungen auf IT-Teams
- Die Rolle von Automatisierung und kontinuierlicher Verbesserung in DevOps
- Notwendigkeit einer kulturellen Veränderung für erfolgreiche DevOps-Transformation
- Betrachtung von DevOps als globale Bewegung und ihre unterschiedliche Anwendung weltweit
- Abschlussdiskussion und Schlussfolgerungen zu DevOps und Projektmanagement
Transkript (automatisiert, daher keine Gewähr 🙂 )
DevOps – auf die Ohren und ins Hirn
Ein Podcast rund um DevOps
Von Alex Lichtenberger und Dirk Söllner
Herzlich willkommen zu einer neuen Folge des Podcasts DevOps – auf die Ohren und ins Hirn.
Mein Name ist Dirk Söllner und ich begrüße die Zuhörer und Zuhörerinnen auch im Namen von Alex Lichtenberger.
Unser Ziel ist es, spannende Interviews und Fachgespräche zu aktuellen DevOps-Themen zu liefern.
Wir möchten das Thema DevOps inhaltlich mit Praxisberichten und hörenswerten Folgen zu den vielen Themen bereichern, die in DevOps enthalten sind.
Wir liefern Vorschläge, Konzepte und Interviews mit Experten und Praktikern,
damit unsere Hörer und Hörerinnen inhaltlich, persönlich durchblicken und die Unternehmen erfolgreicher machen können.
Hallo und willkommen zu dem Podcast DevOps – auf die Ohren und ins Hirn.
Das heißt, DevOps durch die Ohren in den Gehirn zu bringen.
Mein Name ist Alex Lichtenberger und zusammen mit Dirk Söllner runne ich diesen Podcast.
Wie Sie hören können, ist das jetzt unser erster Podcast in Englisch.
Der Grund dafür ist, dass wir heute einen besonderen Gast haben, Rob England, auch bekannt als IT-Skeptiker.
Hallo Rob.
Hallo, freut mich, auf der Bühne zu sein.
Ja, danke.
Danke, dass Sie mitgekommen sind.
Es ist nicht nur speziell, dass es in Englisch ist, aber Rob ist auch auf der anderen Seite des Globes, also jetzt aus der europäischen Perspektive, in Neuseeland.
Das bedeutet also auch, dass die Zeit, die wir in dieser Session rekordieren, um 10 Uhr in der Nacht in Deutschland oder in der Schweiz ist.
Und Ihr Zeitpunkt ist jetzt 8 Uhr in Neuseeland.
8 Uhr, ja.
Unglaublich.
8 Uhr morgen, also ich kann Ihnen sagen, dass die Wetter morgen sehr schön ist.
Gut, ja.
Ich hoffe, dass es uns gelingt.
Also, wie es jetzt in Englisch ist, und ich denke, wir werden auch einige neue Redner haben, also ist es auch wert, kurz zu erklären, worum dieser Podcast geht.
Also unser Ziel ist es, interessante Interviews und Experten-Zweige über DevOps zu machen.
Und auch, weil es ein Podcast ist, also glaube ich, dass es auch sehr interessant ist, für Menschen, die eigentlich das Medium eines Podcasts lieben, also sei es im Zug, Bus, Auto oder auf der Fliege.
Heute geht es um das Thema Projektmanagement, das ist das schlimmste, was sich bei IT jemals passiert.
Eine sehr interessante These, denke ich.
Und bevor wir eigentlich in das Projektmanagement hineingehen.
Ein Thema und ein Thema von DevOps.
Vielleicht, Rob, können Sie sich kurz darüber vorstellen, was Sie als Person und was Sie professionell machen.
Ja, Rob.
Okay, also ich habe in Wellington, New Zealand, seit zwölf Jahren konsultiert.
Vor dem, als ich als Pre-Sales-Mann in Vendorland gearbeitet habe, habe ich mich für Lösungen konzentriert.
Und, äh, also habe ich mich für Lösungen konzentriert.
Und, äh, also habe ich mich für Lösungen konzentriert.
Und, äh, also habe ich mich für Lösungen konzentriert.
Und, äh, also habe ich mich für Lösungen konzentriert.
Und, äh, also habe ich mich für Lösungen konzentriert.
Und, äh, also habe ich mich für Lösungen konzentriert.
Ich komme aus einem ITIL und Service-Management und operatio-Besitz-Besitz-Beifragung, obwohl,
wenn Sie, Entschuldigung, wenn Sie sich tief hinschauen, dann war ich früher ein Code-Developer.
Und, äh, in diesem Zeitpunkt habe ich über Service-Management und Regulierung und Strategie
gewechselt.
Und ich habe ebenfalls einen kleinen Blog eingebaut, den ich 12 Jahre zuvor hatte, als das
eine novelte Sache war.
Und es hat ein bisschen eine Nachfolge auf dem ganzen Weltraum gegeben, was Spaß war.
Und es hat ein bisschen eine Nachfolge auf dem ganzen Weltraum gemacht.
me into a bunch of people so that along the road of agile and then later devops the blog was um
taking a very skeptical view of these things and throwing a lot of rocks and some of the leading
thinkers in the devops space worked on me over a period of years and slowly broke down all my
objections and turned me into a bit of a fanboy a bit of an evangelist for devops so
i’ve been trying to talk to people in wellington about devops for quite a long time and in recent
years it has exploded and now i work a hundred percent in devops consulting it’s all i do
and i work now with my partner in life and work dr cherry vu and we call ourselves teal unicorn
which is a a a bit of a trendy
brand but we we like uh riding on the wave of of fed energy so teal unicorn uh actually quite
proud of that one i think it’s quite a good brand for a consulting organization and so that’s what
we do we consult here in wellington we design and build games we deliver games such as the phoenix
project game from gaming works we go to conferences we speak we spoke at the devops enterprise summit
and um just immerse in all things devops it’s wonderful hello rob so thanks and it’s nice to
have you here in our podcast so like we do to all our guests um what would you say how would you
define devops so devops is whatever you say it is man you know it has no formal definition so it’s
wonderful that you asked that question of everybody and uh
i take the big picture definition so you know some people would say it’s somebody in a server
room automating a linux server and some people would say it’s continuous integration and
continuous delivery and continuous testing and the flow from development to deployment
and particularly the automation of that but i take the even bigger view of the alms
service and the sharing and applying those principles to all the value streams in it
not just the require to deploy value stream but anywhere where we can move to new ways of working
which is my preferred phrase for describing it so for someone like me the term devops is actually
more baggage than help these days because it’s very technical and it focuses on dev and ops
and it doesn’t really embrace all the principles of new ways of working which have emerged in this
space yes okay so um like you like alex and like me we all came from it service management so what
do you think what uh what’s the correlation between id service management and devops several decades
ago
but um
uh i think that that itsm is just part of the thinking and um
you know i’m a big fan of gene kim’s approach to that itsm is an integral part of all of this but
itsm needs to move its thinking forward just like every other aspect of it needs to so
that whole crossover and impact on itsm is a particular area of interest and study for me and
that’s what we presented on last week it’s uh we went kind of tribal for a while and the
agile slash devops community in the itsm community kind of got it opposite ends of the paddock and
threw stones at each other and it hasn’t necessarily been a constructive relationship but
um you know we’re seeing lately i think around the world that the two groups are now really
starting to think together and get together and cross over ideas and
devops and agile are bringing bringing new thinking into idle um hence idle practitioner
or as i prefer to call it idol 3.5 and um and hence the work on idol 4 and hence
verism as a framework and hence um uh finally some influence from thinkers like richard cook and
sydney decker and some of the new ways of thinking about error
and resilience and and particularly thinking around complex systems so all these ideas
are spilling into the itsm space at last and uh so i think that’s the relationship is that
we there has been a tribalism but we’re coming together and we should i’ve always advocated that
we just need to bring itsm along on the journey yeah yeah let’s hope i mean that uh future
versions of uh itel and also verizon
will will bring in these ideas and coming back to your definition also of devops uh i actually
as dirk said we ask that question every interview guest and each time it’s a little bit different but
from my point of view i liked uh that you’re actually holistic well holistic whatever but
holistic view so uh looking at the different aspects uh which are needed and especially the
the people aspect so um
as the people aspect um
so now you know sorry in fact now i’m trying to expand
to train myself to say new ways of working and managing
big because one of the strongly emergent themes in recent years has been that for
an organization to change the leaders need to change right and so all the talk around
servant leadership and transformational leader and and realizing that often agile and devops when we say solutions but we’re definitely trying to sell it into the community as well trying to create solutions in terms ofWhat should weglif if there’s a right path how to give to this learning path etc
and transformational leader and and realizing that often
agile and devops
fail, because the management
think it’s something you do
to fix their people, and that they don’t
need to change the way they manage it all.
We really need to break
that. Yeah, which
nicely brings us to the
actual topic. So you
talked about management,
so also
now talking about managing
projects,
and one of your,
I mean, the reason how
we got to that topic is
also, I mean, some of our
listeners maybe know
the blogs of Rob England,
always with very interesting
titles.
I personally like also the one
that was titled, like,
How DevOps Messes With Your Head.
But recently you wrote a couple of
blogs, like,
I have to look that up, but it was
like
10 Agile
Principles That Screw Up
Conventional Project Management,
or the latest
one was the Oxymoron of Agile
Project Management,
or an older one, Project Management
was the worst thing that
ever happened to IT.
So I think they all go into the same
direction. So Rob, maybe you can
just as an intro, you can also
shortly explain. So we did now for
decades, projects,
so now
you say that’s the worst thing ever happened to
IT. Can you please explain?
So
the way I
see it, somewhere back
in the 80s and 90s
as
the cost of IT escalated
in lots of organizations, generally
for very good reasons, because IT was becoming
more and more mission critical and more and more complex
and so the costs were rising.
And organizations
governed IT like a black art.
They really didn’t understand how it works
in the same way that they understand how
finance works or
people management works. So
it was just a black art. They didn’t
understand it. So they went, oh my god, we need
to get some control over this.
Let’s black box it. Let’s
define the inputs and measure
the outputs. And so let’s put
a project and program management framework
over it so that we can see that we’re
getting what we thought we were getting with our money.
And IT
being typical IT,
took an
intensive engineering approach
to project management and adopted
civil
engineering style project management.
And imposed
these strict
waterfall constructs
on us. And
as a result
applied a paradigm
that is completely inappropriate
in a software world.
And the reason I say
it’s inappropriate is
because of our understanding now.
So at the time, you know,
we didn’t know everything that we know now.
But we understand now that
what we build are not simple systems, they’re
complex systems, that
you can define a bridge down to the
last rivet and
girder and then
build the bridge
because it’s near to a
simple system. Whereas
a software system
is nothing of the sort. It’s a complex system.
Which means that we have
no idea when we start the journey
what it is we’re actually going to build.
And yet
project management perpetuates this myth
of
define once, execute perfectly.
Design what you’re going to do
and then do it.
And have
defined inputs and expected
outputs.
Great. So let’s go a little bit more into detail.
And just a few days ago
I read your blog article
about dysfunctions of
project management. And I think it’s
a good point to use it
for a podcast to talk about
some of your mentioned
points over there. So
what do you think, how much
responsibility is within
DevOps?
Yes, I put those 20 dysfunctions
out yesterday and it seems to have stirred up
a bit of a hornet’s nest. So I’ll be looking forward
to putting this podcast link out as a response
to some of that.
There’s some really major
dysfunctions that project
management thinking drives in IT.
I’m a people person
so I’m with you.
Anything that affects people is,
one of my primary concerns.
And so, you know,
the basic model for project management
is we bring the
team to the work.
So we define a piece of work
and then we draw together people to create a team
to execute that piece of work.
And then when the work is completed, we disband the team.
Which is,
flies in the face of everything
we know about human behavior.
That any team has to go through
the old forming, storming, norming,
performing cycle. They need to
take time to coalesce as a group.
And they’re only just getting into the
performance. Once you get into the performing phase,
you can then start optimizing how you work.
So they get into a performing
phase and they start optimizing
how they work. And the next thing you know, the project’s
over and the team’s disbanded.
And they all sent off in different directions.
So it’s a highly
dysfunctional way of managing
people.
Whereas, you know,
product management thinking is that you have
a standing product team.
That is as stable for as long as possible.
And has the time to get into a performing
and then continuously optimizing mode.
And instead of bringing the team to the work,
we bring the work to the team.
Yeah.
Yeah, I fully agree.
And there are like now two aspects you looked at.
One is the problem with the phased approach.
And
I’m also, I’m most of the time working as an agile coach.
And I agree that, you know, in the beginning, if you don’t
know exactly what the requirements are, there’s a complex system.
You have to make the experience first.
And anyway, the team is in a storming phase that you cannot be
sure what your performance is.
So you rather go an agile approach.
And the other thing is also what I really like and what I see
as well is so less now talking about projects, what’s more about
products and what, what I would be interested because how do you see
with you saying, okay, that’s actually the traditional or waterfall project
management doesn’t make sense anymore, but don’t we still have situations
in IT where, where it still would make sense.
So where we, where we actually, when we know where we exactly want to go
and requirements are clear from the beginning, so isn’t it rather
like, let’s say a typical consultant answer, like it depends.
So which approach we choose, you know what I mean?
I, I, I don’t, I don’t feel that way.
I know a lot of people do, um, for two reasons.
One is I challenge the assertion that we know our requirements
in any software situation.
Um, so we are always building a complex system.
If nothing else, every system we build has people in it.
And as soon as you have people in a system, it’s by
definition complex, people are never simple linear and predictable.
So, um, and all our systems have people in them.
We have to stop pretending that we build things that have no people in them.
So, so I challenged the assertion that wherever in a situation where we’re
about to build a simple linear system and, and, and we have a clear understanding
of the requirements for that simple linear system, I just don’t
think we’re in that situation.
So I think that’s one challenge to it.
And then the other challenge is the whole bimodal thing, you know,
even if, even if there was a situation where project management
was a usable approach, um, I see no reason why we should have two
ways of working in an organization.
It’s equally amenable to doing it in an agile way.
So, you know, let, let’s adopt a single way of working for the organization
that works in all situations instead of adopting a new way of working for
the situations where the old way of working doesn’t work and then still
dust off the old way of working and drag it out occasionally when it does fit.
Mm-hmm then as a, as a, as a consequence, this would mean that, uh, so
you, you say bimodal is not really an option.
So what, what would be the consequence for the, for the companies that
there is only one model of working?
The consequence of only one model.
Uh, so to, to flip that, I think, you know, the consequences of bimodal are
toxic mm-hmm and, and it’s,
it’s possibly the worst idea that Gartner have ever had, but there’s a lot
of comp, but there’s a lot of competition for that title from Gartner.
It’s, it’s, I mean, I, I, I also play a little bit the devil’s advocate.
So, and Gartner by was also, they were the ones who came up with, with
the successor of the bimodal, which was the, uh, uh, paste layered
application, uh, or what, how was it called?
You’re right.
Multi, multi-speed IT, isn’t it?
Mm-hmm yeah.
And, and, um.
And I’m an advocate of multi-speed IT mm-hmm only in the sense that whatever
one way of working we come up with, it needs to embrace multiple cadences.
So, you know, the pace layering model and the application of multiple cadences,
I’m fine, I’m down with, but that we can still do all of those different
cadences with the same way of working is the point mm-hmm and, and, you know,
Gartner have softened their bimodal stance a bit by talking about convergence as
well, but, you know,
a, but I think we, we, we should aspire to converge as fast as possible because as long
as you maintain bimodalism, whether it’s product versus project or digital versus industrial,
you know, agile versus waterfall, uh, you, you’re immediately introducing tribalism
into the organization.
You’re immediately driving the idea that we have two teams, we’ve got the cool new funky
kids and we’ve got the boring old farts.
And, and.
Yeah.
und du fährst sofort eine große Schleimhaut in die Mitte deiner Organisation.
Es ist ein wirklich, wirklich toxischer Weg, um zu arbeiten.
Welche Organisation möchtest du gehören?
Also wenn du die Leute fragst, wollen natürlich die Leute Teil der coolen Leute sein.
Also ja, wir fahren auch enttrennte Positionen, sodass andere Leute sagen,
hell nein, ich bin, du weißt, das ist nur verrücktes Cowboy-Stuff.
Ich bleibe hier in der sensiblen, solid,
prüfen Welt von, weißt du, du fährst enttrennte Positionen beide Wege, tatsächlich.
Also ein guter Punkt.
Schau einfach von Neuseeland nach Europa, in die USA und überall in der Welt.
Was denkst du, sind DevOps überall in der Welt gleich?
Wie Idle sollte gleich sein oder Scrum sollte gleich sein,
weil da sind einige Frameworks geschrieben worden.
Also was denkst du, sind DevOps überall in der Welt gleich?
Ich denke,
Well, actually, DevOps is all over the world different.
So that’s a good answer.
So one of the things we need to learn is,
and this comes back to the whole product versus project thing.
We don’t know where it ends.
Anytime we do any work in the real world,
I think outside of really strictly defined technological spaces,
because technology can be really tightly locked down to be near a simple system.
But any other area of the world,
which is why Agile thinking is exploding out into business now.
We don’t know where it ends.
So whether it’s a project or whether it’s introducing DevOps ways of working
or introducing Agile, or any change at all to build something or change the way we work.
We don’t know where it ends.
So that means that DevOps looks different in every single organization around the world.
The only thing that’s common is the fact that DevOps is different, but every single organization around the world.
The only thing that’s common is the fact that DevOps is different in every single organization around the world.
is the principles they applied in order
to move forward on their journey.
But the result of applying
those principles to a complex system is
random. It’ll be different in every single
instance. So you can start
seeing patterns across large amounts of
data to see common patterns that
emerge from organizations
that take these approaches.
But there’s certainly no one pattern that
emerges and there’s no one answer.
Every organization’s
DevOps journey or any journey
is unique.
This is also what, from my
point of view, makes it
very interesting.
Maybe we can also ask the question
a little bit differently.
I think you would agree that
DevOps is also very much
a movement. So as you said
also in the beginning, there is no formal definition.
So it’s a movement. I think
you travel a lot in conferences
and speak. So how do
you see, so which regions
also in the world, so where is
DevOps very much pushed
or influenced? Do you see some
patterns here?
I’m not sure
I have a sufficiently global
view to answer that well.
You’ve got London,
isn’t it?
Yeah, so there’s passionate support
coming in the UK and
Europe and
of course there’s an epicenter
of energy in the US.
In New Zealand, well certainly
Wellington seems to be rocking
even by a global standard.
People are always surprised.
My clients include the New Zealand’s
largest government department
and New Zealand’s tax
collector.
And all the major banks are on
this. The National Airline is on this.
The telcos are on this.
So all the big core
horses in New Zealand are
either way advanced
or at least have one
blue glittery leg on the horse.
They’re all
very
they’re all starting the journey
or well down the journey.
And so
one of the banks has completely
transformed itself. One of the government departments
has completely changed the way it deploys software.
So certainly it’s hot here.
But I don’t
have a good picture around the rest of the world.
I think that’s an interesting question. I’m always
fascinated by China.
So here you have
what is now one of the largest
economies on earth.
And it’s almost completely
opaque to us. We have very little
visibility for what’s actually going on
in China in terms of ways of working.
So I know
some people
go and do training and have exchanges
and work with universities in China
and have a small visibility of this.
And there’s some academic
exchange. But every time I try and
research, I find it
really quite opaque.
And I think that’s a really interesting question
because
you know,
China is on the cusp in the next
couple of years of being one of the
five most powerful
countries on earth.
And
will eventually, of course, be the most powerful
country on earth. And yet we have
very little idea what’s going on there.
Yeah, great.
So have a look on your 20
point list regarding point number
nine. I think it’s a great point.
That leads to the point
do we have product teams
or do we have projects? And I think
it’s a good point
over there. So what’s
the experience with automation
within projects? I would
say so within
a project you are not
forced to
automate the things. And within
product teams who build
it and who run it, they are forced and they
are pushed to automate their
work. Absolutely.
So what happens
is that
my rule of thumb is it costs about
three times as much to automate a test
as it does to execute
that test manually.
So if
you’re a project manager, you’ve got the option
of either doing all the testing
once manually at the end
or investing in
automation and doing it many times throughout
the project. And for
many old school project
managers who don’t get what this is all
about, they go, you can’t be serious. Why
would I triple my testing costs?
So
they have
and in terms of automating
continuous delivery and any
other areas, they’re only going to do it once.
They’re going to build the thing,
they’re going to deploy it, they’re all going to run away.
So, you know, why
would they be interested in automating deployment?
They’re never going to have to do it again.
Yeah.
So all the incentives
are wrong for project managers
and for people on projects. They’re paid,
they’re incented, they’re measured on
how
they’re going to do it.
So, you know, I think that’s a good point.
Quickly and
accurately, they deploy once.
And maybe
one interesting point
would also be so
now, let’s say having also some
insight
and seeing all the problems
with the traditional
phased project management
and the wish
of the companies
also change towards
DevOps, standing teams, doing
agile, you build it, you own
it.
But now, let’s talk about
transformation. So people
which were used
to work
20 or 30 years
the traditional mode and now
you want to move
and you want, I understand that you work
as a consultant, you support
companies in that transformation.
And I think it’s also a
mindset change. So do you have some
tips for us? How can
we, from your experience,
what are the changes?
What are the challenges
and to actually that people
change towards the new way of
working?
Many, many, many
thoughts on this. But
some of the core ones are
I’m highly amused when I see
organizations that announce that they’re
going to move towards agile ways of
working and they’re going to do that in a
big bang project because
apparently they missed
the agile class, you know. So we
have to move towards
new ways of working in an agile way, which means
we should iterate, increment,
experiment, explore, find
our way. Because again, we don’t
know how it lands. And
I get some really interesting
conversations with traditional
organizational change management people
who want to know what the target operating
model is. And
I say, well, I have no idea. And
anybody who tells you
they know what your operating model is going to look like
in two years time, you should show them the door
because they have no idea either. Can I
ask a question between you? So I’m
hearing now that actually also the transformation
itself, you can do it in an agile way,
right? Absolutely.
It’s essential to
move forward
incrementally and experimentally
to find out what works at your organization
right now at this
point in time. And
so another language that I use is
talking about navigational
stars as aspirations
that we sail towards.
In the northern hemisphere, you
talk about the pole star or the north star.
Well, that doesn’t
work, of course, down
here in New Zealand. So I
talk about Matariki, which is a
Maori name for the
Pleiades constellation,
the Subaru constellation,
which is a constellation they navigated
with, which is highly
significant to them. But I use
that language of a navigational star
that
the navigational star is
that we do everything in product teams
and we don’t
have any
project organizational constructs
and da, da, da, da, da.
But that’s a star that we’re sailing towards.
It’s not something we’re going to just
leap to overnight. It’s
the direction we should be going in.
Yeah, consent.
So let’s switch to another point.
I like to talk about the
word or the phrase
bimodal IT.
The IT with two speeds.
Or different speeds. What do you think
about that in the context of
DevOps? I think again,
many, many thoughts, but one of the core ones
again is that we must
create white space.
So
around any attempts to
work in new ways. So even though
I’m really down on the
idea of bimodal,
ironically
bimodal is essential
as a temporary thing
while you’re experimenting
with new ways of working.
In order to experiment with a new way of working
you have to give it
isolation, white space.
You need to decouple it from the rest of your system
so that it can move in new ways.
Otherwise it’ll still be locked into the old
system.
It’s a common joke amongst consultants.
You probably see the same thing yourself
over and over again. You go into organizations
and they say, oh we tried
agile and it doesn’t work.
And the moment you
probe that, you discover that they told a team
to be agile, but left them locked into the rest
of the machine. So it was impossible for them to be agile.
And the other interesting
thing I noticed was
self-fulfilling prophecy.
So if people say,
if they are really skeptical
or no-no’s
and say, oh this will not work,
then it actually will not work.
So coming back to that
I understand, so yeah
it’s the key to success.
It’s a journey to experiments
step by step
and maybe Biomodel is the first step
to actually the next step.
But how do you deal with
because each organization
has such kind of people
so the really no-no’s
or
in a negative sense.
So I think
of this in terms of the normal distribution.
And
there are those early adopters
and pioneers at the other end of the normal
distribution who are on board straight away.
So I like to say
work with the people who want to be changed.
If people are resistant
then I used to bang away
but my strategy now is if people are resistant
I just go find and I go somewhere else.
So find
the people who want to be changed, work with the people
who have the vision, who are the early adopters
are the pioneers
and create some proof points.
Because as soon as you do something
within the organization or very close
to the organization that works
then you start moving down that balcony
you start moving into the early majority
the people who just need to see it.
And as soon as they see it they go
oh it does work and they start getting on board.
And then as soon as the early majority starts
coming on board then the late majority goes
oh look everybody is going over there
and they come along as well.
And the naysayers end up
standing on their own wondering where everybody went.
That sounds pretty
impressive also.
What if people just change by themselves
or they want it by themselves.
Your say actually creates
some early successes
and if people see that
they want to move to that as well.
So another analogy
we’ve used is that
I just kind of run around an organization
with a blowtorch trying to set the grass alight
and
every now and then
we hit somewhere that is nice and dry
and eager to hear new ideas
and a fire takes off.
Other places nothing happens.
Well okay, fine. Just move on.
Concentrate on the areas where you are getting
a reception and get something going.
Get those proof points and then
later on you do have to
start addressing the areas of resistance
but if you’re already getting momentum
and if you’ve already got data and evidence
and proof points from within the organization
then you start going up the pole
to management going look do you want this or don’t you.
We need to work together to address
these other areas.
Yeah true.
Sounds really really good.
Now we’re talking about
I think half an hour about
your blog article
that sounds like a manifesto
against project management
and regarding the
DevOps philosophy.
So I think we should
minimize
projects and should build up
product teams.
The teams who deliver,
who build it, who run it.
What do you think about that?
I think we’re all familiar with the momentum
of projects that
I was just talking to
someone the other day about this
in the context of a very large project
where if you’re within
or even if you’re outside the organization
as a consultant, if there’s a whole lot
of money being sunk on a big project
then if somebody says
if somebody is a naysayer, if they say
oh look this isn’t going to work because
you’re just seen as
somebody who is trying to create a
self-fulfilling prophecy. You’re seen as somebody
who’s not on board, who’s actually working
counter to this important project.
And so you get the whole emperor’s
new clothes thing where everybody’s just
all smiling and nodding and saying how
fantastic this project is because nobody
wants to be seen to be the one
who’s
not supportive.
And so projects
just get this horrendous momentum
of their own.
There’s the sunk cost fallacy.
There’s the way they’re divorced from
customers so often
so the customers don’t even realize how off the
rails it’s going. All these things
are many different
causes but the pattern is that
projects get a life of their own.
I heard a wonderful story recently
about a project that had been
not killed off but just shut down
sort of put on ice and
then the organization discovered months later
that they were still paying a whole bunch of
vendors and consultants in the context of that
project and so while they thought it was
on hold they’d actually burnt the rest of the budget
for the project.
Which I thought was fun.
So, no, exactly.
And whereas the whole
premise of Agile is that you’re constantly
re-evaluating your assumptions, you’re
constantly re-evaluating whether or not you should
even do this thing and one of the
four options every time you evaluate
an iteration is to completely
abandon the
it’s continue,
deploy,
pivot or abandon, right?
Yeah, so now
honestly, because looking
now at Agile, because Agile
Manifesto, it’s 2001
and also I think
Scrum or other frameworks
are even older. If I
talk to developers they also say
yeah, we do that
actually since
a while already. So why is
it that now talking about
horses, why it took so
long until
they start
adopting, so not
only Agile but now also including
operations, so DevOps?
Well, actually
I don’t think it took very long. I think it only
took a decade or two. Okay.
Depends
on what you define longer.
Yeah, yeah.
You know, if we look at the rates of
how fast society can
change and how fast
whole industries can change,
then, you know, a
decade is not a long time.
And even though
technology is changing at a blinding
pace, it drives this fallacy in
thinking that individual
humans and teams and
organizations and industries and
societies can change at
the same pace. And they can’t. Humans change
at a remarkably
slow pace. I make the joke that we
have to wait for some people to die to see
change. Looking
at the watch, right?
Yeah, no, it’s
for me it was
very interesting, but I have no questions.
No more questions so far.
Thanks,
Alex, for that hint.
We should go to
come to an end for this podcast.
So thank you, Rob.
Thank you, IT Skeptic, for
having you here in our podcast.
Really the first one
in English. I hope it’s not
going to be the last one. And I
think thank you for your remarkable
ideas. Thank you for your
blog posting and all the things
you mentioned to
help us to build a better
IT, to make IT faster
and reliable, more reliable.
So thank you to have you here.
Oh, thank you. It’s been fun.
I’m happy to have been part of it.
Thank you for the opportunity. Yeah, thanks
also from my side. It was really a pleasure talking
to you.
Thank you.