Folge 66: Bryan Finster on SAFe at Walmart, and the downsides of SAFe [EN] 2/2

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In this episode, Bryan Finster shares his insights into implementing continuous delivery and DevOps at Walmart. He talks about the transition from traditional development methods to agile and DevOps practices, emphasizing the importance of customer feedback, team autonomy, and breaking down large applications into manageable services. Brian criticizes the SAFe framework for its rigidity and advocates for a more flexible, iterative approach to software development. He also discusses the challenges of adapting DevOps principles in different contexts, such as hardware and safety-critical systems, and the importance of a culture shift towards continuous delivery for improving software quality and team morale.

Inhalt

  • Introduction to Brian Finster’s background and expertise.
  • Challenges and experiences of implementing continuous delivery and DevOps at Walmart.
  • Critique of the SAFe (Scaled Agile Framework) and its limitations.
  • The importance of customer feedback in the development process.
  • Adapting DevOps practices in different contexts, including hardware and safety-critical systems.
  • The shift from traditional development to agile methodologies and its impact on software quality and team morale.
  • The role of team autonomy and breaking down large applications into services.
  • Continuous delivery in challenging industries, such as satellite technology.
  • The formation and goals of the MiniumCD community project.

Shownotes

SAFe is not Agile

Doing Agile vs Being Agile

Information for decision-makers considering the SAFe framework

Backwards Bicycle

MinimumCD: Minimum Viable Continuous Delivery

The Scaled Agile DevOps Maturity Framework (SAD MF)

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

DevOps – auf die Ohren und ins Hirn
Ein Podcast rund um DevOps
Von Dierk Söllner, Falko Werner and Luca Ingianni.
Welcome to a new episode of DevOps auf die Ohren und ins Hirn, or in English, DevOps from your ear straight to your brain.
Usually, this is a German-language podcast, but we sometimes make exceptions for international guests.
Today is one such exception.
And in fact, it’s a double exception, because this is the second part of a very long interview that we started in the last episode of this podcast.
Our guest is Brian Finster, who is an enterprise software engineer, very knowledgeable about SAFe,
and somebody who is quite critical of SAFe, just because…
I guess he has seen how it can go wrong and found ways to apply agility in a more effective way in the corporations he worked with and works with now.
And this interview was so exciting and so long that we ended up splitting it into two episodes.
So today you’re going to listen to the second part of this same interview.
And since we didn’t actually plan on it going this long,
the start is going to be a little bit jarring, I apologize for that.
But we’re going to essentially just jump right into the middle of it and continue where we left off roughly two weeks ago.
Enjoy.
So if I look on the requirements flow, requirements are at team level, so teams know what is expected.
They have a product owner to talk to, to clarify things.
It’s not the way that you said, you’ll figure it out during development, but someone who really answers questions of the developers and everything else with continuous delivery is in place and working fine.
How do we get the customer in the loop?
You mentioned having direct connection to the customer, giving some ideas, and a few days later you gathered feedback with an implementation for that idea.
How do we get the customer in the loop? You mentioned having direct connection to the customer, giving some ideas and a few days later you gathered feedback with an implementation for that idea.
How do we get the customer in the loop? You mentioned having direct contact with an implementation for that idea.
How do you get that in an organization with, I don’t know, a few hundred people?
A few hundred people?
Yeah, a few hundred, yeah.
Well, I think it depends on who your customer is.
You know, in that situation, we were delivering to internal customers, so it would be, you know, an hourly associate in a warehouse just in a warehouse for Walmart
and
you know, we were trying something
knew and we just got them slack accounts so that we could have conversations with them but
that was you know post implementation before that we had you know the the business people
we were working with as we were starting this stuff up um and it was a lot of not just with
them with a dba area operations all these different areas we had to go and sit down and have
conversations with them and and convince them that what we were going to do was better and in
some cases we just we had to bypass them because they wouldn’t collaborate with us because it
didn’t meet what they had written down somewhere in other cases you know it just took convincing
and demonstration that we this this was actually better because of course business didn’t trust us
why why should they every time we installed anything it blew up because you have quarterly
giant terrible things and so you had to go and and and do the legwork and communication to build
that trust up and show hey there’s a small experiment we can run let’s try this let’s
show you what we’re capable of doing in a way that can’t possibly impact you and then just
keep doing that and keep building that trust
okay so internal customers so um how would you suggest to go on and extend this uh process
then is in time course and then overall um to the end there you know for you to
whether or not um we can operate as um credit issuers just as a result of a failure of this
price and uh it can be um just it can be cynical um without doubt um certainly um
um um or even even if you don’t use some of these insights um or just because um yeah if people think
type of setups where you have this i don’t know support organization in between or something like
that well hopefully it’s not a well we can have a whole other podcast about uh support models but um
if uh you know it depends on the context your application uh so for example let’s say that
you’re delivering a platform tool okay i know i know you guys don’t know anything about that at
all but if you’re delivering a platform tool um do you want to go and ask the people you know how
happy they are with their platform on every build i mean that would really annoy me i think that
nps is something people talk about but i honestly i got mixed emotions about that because i very
rarely give feedback on anything if i’m asked it actually annoys me i’m just tired of being asked
how i like things what is nps uh net promoter score oh and all right nps yeah yeah so yeah so
the the constant nagging for me to give feedback on stuff means that i i hate you
and even if i like your product i’ll just get annoyed i have to really like your product to
give positive feedback at this point because it’s just become so ubiquitous across the industry
how do you get feedback well there’s a there’s a couple of good ways are people buying more of it
uh and what’s our defect rate how many complaints are we getting because people will always
complain right they’ll always tell you that it’s terrible but they won’t always tell you it’s great
yeah so you can’t you can’t feel good because people tell you it’s great
um you just really need to look at are we able to sustainably deliver this are we
making a profit on it are we growing
our customer base. And not only that, are we keeping our current customers? So it’s not good
enough that you’re gaining new customers? Or do we have loyalty from our old customers? Do they
still enjoy our thing? Or do they buy it and then throw it away? Right? I mean, you need to look at
the utilization metrics around that. It’s similar to, you know, when I moved to platform, we talked
about how do we get feedback on the value of the tools for building the platform? Are they being
used? Don’t ask people how much they like them. Are they being used? How many tickets are getting
opened internally for problems? You know, just look at that. And if we have a new feature that
we’re trying to release, you release a small experiment on that feature and say, okay, are
people actually wanting to use this feature? They want to expand on this? Or is it just completely
unused cruft that we have to support forever? But we thought it was cool, so we added it.
So you’re measuring…
The use of those tools, are there any practices or good hints that you want to share?
Well, I’m not a mobile developer. You know, my work’s all been on platform or an internal
product. But, you know, there is feedback mechanisms available to people to get those,
the usage metrics back.
I’m wondering though, how do you do this in maybe more challenging contexts? Like this year,
I had a customer who built transformers for power stations. So like things that I imagine are as
big as a house. How do you gather feedback in such an environment? How do you…
Feedback on a transformer?
Exactly. How do you iterate on your product?
You know, in such an environment that is, you know, both big and safety critical.
That’s a, that’s a hardware problem.
No.
I mean, the transformer didn’t explode. Some, nobody else can build it cheaper. I, you know,
there’s, it’s, I would probably have to come up with different things, but I haven’t thought
through how to get feedback on the value of, you know, the customer’s perception of my
transformation.
I think not catching fire is a good one.
Yeah, true.
Yeah, it’s probably not feedback on one transformer. You might also not gather feedback on just one feature and then you’re done, but you’re gathering feedback on a product or let’s say a series of transformers with different customers.
Yeah.
Things like that, some ideas not thought through.
Yeah, I don’t know. You’re, you’re, you’re reaching far outside my, my domain.
Okay, fair enough.
Didn’t mean to put you on the spot.
But this is the thing that always pops into my head. If somebody says, oh yeah, you need to go for faster feedback. And I’m thinking, well, I come from the embedded side of things. I come from the safety critical side of things.
If I build my product.
People will die. So how do I use this principle of fast feedback and short iterations in this context?
You, you need to have some sort of double of your embedded system, including having an having the hardware in your pipeline. If you, so if you’re gonna do a continuous, so your software to embedded systems, just means that our, our test infrastructure looks different.
And it’s honestly not too much different from what I used to do because I used to deploy straight to metal.
So if you’re gonna do continuous, so you have software to embedded systems just means that our, our test infrastructure looks different. And it’s honestly not too much different from what I used to do because I used to deploy straight to metal and it’s maybe not far away from where I am right now.
I think so, yeah.
It’s definitely not so much.
In my case, I’m not sure I don’t realize it yet.
in a distribution center i mean sure it’s not a microcontroller it’s a linux box but still it’s
it’s hardware and if you wanted to run a good microcontrollers these days are also linux boxes
fair enough but you you still had to have hardware in your pipeline to validate that you know it’s
just that you had to do more work around keeping things up to date on that hardware than you would
if it was you know kubernetes container uh of course you know like you know i’m doing a lot of
work with the air force right now and they’re they’re delivering all sorts of embedded systems
with kubernetes at this point so but you need to have uh your you know your pipeline architecture
that includes things in there to give you a high level of confidence that you can deploy now can
you deploy to production to a bunch of distributed disconnected embedded systems no not necessarily
the system might be off i mean we’ve had to do handheld flashes before and we’ve got handhelds
that are not plugged into the cradle so you can’t flash the handheld right but eventually you can
but the the goal is to get feedback on on is it releasable it’s not necessarily continuous deploy
it’s is it releasable and you know that fast and so for example i know one company that builds
satellites and they use continuous delivery to deliver changes to their satellites all the time
and they have that
haben einen Satelliten in ihrer Pipeline, einfach auf dem Boden, den du auswählen kannst.
Oh ja, ich brauche diesen Test, um durch den Satelliten zu laufen.
Das ist, wie du das tust.
Du kannst nicht einfach ein paar Unit-Tests auswählen und dann…
Um ehrlich zu sein, das ist genau so, wie ich mich damit fühle.
Wie, weißt du, gib mir keine Ausreden.
Sag mir nicht, oh, du weißt, es ist in der Software einfach, aber für uns ist es nicht möglich.
Wir können es nicht. Blablabla.
Ja, du kannst es. Du musst nur kreativ sein.
Du musst nur, wie du es gesagt hast, Brian,
den richtigen Ziel behalten,
nämlich, dein Produkt zu validieren, um ein genügend Vertrauen in dein Produkt zu erhalten.
Und wie du das herausfindest, weißt du…
Ich denke, es beginnt mit dem ersten Aspekt,
wenn man feststellt, dass etwas falsch ist.
Etwas, was wir gemacht haben, ist falsch.
Und wir brauchen einen Weg, um schnell herauszufinden, ob das wahr ist oder nicht.
Und zu deinem Punkt, es ist nur ein Ingenieurproblem.
Das ist alles.
Es gibt Lösungen in jedem Kontext.
Es ist nur ein Ingenieurproblem.
Du bist kein besonderer Schneefleisch.
Danke.
In unseren Vorbereitungen und auch im Laufe der Session,
hast du Walmart erwähnt und gesagt, dass du SAFe da implementiert hast.
Da war ein Leben vorher, und dann hast du das Leben danach weggezogen.
Wie hat SAFe Hilfe oder blockiert?
So vielleicht kannst du uns ein bisschen deine Erfahrung über die Flur der Dinge geben.
Ich würde sagen, das eine, was es gemacht hat, war, dass es allen eine gemeinsame Sprache über Scrum gab.
Nun, natürlich ist der Nachteil davon, dass jeder dachte, dass Scrum agil war.
Und Scrum ist nicht sehr agil.
Es ist mehr agil als ein Wasserfallprozess, wenn du das tatsächlich machst.
Eines der Dinge, die ich auf der Weg fand, war, dass wir nur werden, dass wir einfach mal so was machen.
slide into a continuous flow and move away from sprints because sprints become artificial roadblocks
sprint duration feature duration and delivery duration those timelines don’t ever line up so
why don’t we just focus on delivering features as a continuous flow of very small changes you know
but but it did give everybody a common language to to at least within the context of that
organization talk about um but it also you know hurt because you had to you had another yet
another thing to unlearn that had been learned and when you have been taught and had it pounded in
your head that that we have to manage our dependencies with process we have to link
these teams together and we all have to do two week sprints and the story point has to be this
big and this is how you this is how big a story has to be before you slice it and this story
is too big and this story is too isn’t you know whatever right they have all these process rules
and you come in and you say okay now we need to deliver daily um and you’re gonna have to change
everything about how you think to get that done um it’s uh it it takes time to then go again
and learn all those things this is why i’m a much better bigger fan of we need to start where we
want to end we need to start with that goal in mind and talk about how to get there and not teach
people an intermediate
step that they then have to unlearn how often did you did you deliver or release before the safe
thing in walmart oh well so i was there for like 19 years i don’t know how often did you did teams
it varied quite a bit when i got there it was very much like the company i’d come from before
we delivered when the feature was done uh and that could be tomorrow uh it could be in two weeks
could be you know a big project we decided to do um there was there was no you have to understand
that it was there was no structure around it it’s just we need to get stuff to the business
right definitely you know as fast as possible uh then they brought in safe in you know an agile
and then it became two week well i’m sorry then they brought in project management and
we delivered like the end of the project so that could be anywhere between a month to six months
in one case we delivered after um like a little over a year you can imagine what that first
install looked like yeah um for people who can’t imagine it was a complete nightmare with months
of 24 7 support after that first install um so it was awesome what time was that uh 80s you’re
talking like two thousand and uh 2007
and eight to the morning um then they then they brought in safe and then you had sprints but
those weren’t delivery sprints so those those were just sprints because then you also had to
have your hardening sprint because that’s that’s a thing apparently is a hardening sprint that
wasn’t safe yeah in a testing sprint so you have a testing sprint in a hardening sprint
and then and then you deliver and then it was just we’re delivering quarterly
and so that just became the thing uh we we we did improve the fact that instead of having seven
hundred independently versioned applications we had one version of the product uh that made it
was made up of like 700 big applications um but then we were delivering that once a quarter with
nightmarish support after every delivery and then you know moving from that to multiple times a day
on per team was awesome uh you had 700 applications that were independent and whenever
each of those applications got a new feature you didn’t have to do anything else you had to deliver
that and we’re done no no no so independent would be too strong a word we had uh uh we had between
700 and 800 deployables okay now and those were nothing like services these were uh either batch
applications that would run on cron jobs or they would be like full user you know three tier
applications right uh for different functions
of the warehouse management system, but they’re all
coupled to a database with hundreds of
tables with no
delineation between business function at the database
because the database had been evolving over
20 years and it was just a nightmare
of complexity. I mean, to give you an example
of that, and this isn’t true
anymore, but at the time
if you wanted to
indicate
that something was a full palette
pick versus a case pick
because database change
had been so hard when they had written that
functionality because you had to go through
so many hoops and open so many
tickets and wait.
Instead of
getting a new column added to indicate that,
they just overloaded the last
four characters of a 30-character
column with
P-A-L-T to indicate
that it was a palette pick.
And then you just had to know that that was it because the
column name had nothing to do with that.
You just had to know the substring
27 through 30 of that column
meant palette pick or not.
So you had very
good documentation, I suppose.
Oh, excellent documentation.
No.
Yeah, all the documentation was in there.
Everyone had to read the code.
Yeah, you just had to read the code.
But I mean, there’s a lot
to unpack there, right?
The
organizational drag impacted
the application so much that
it was just incredibly fragile. But it was
a giant monolith
made up of
big, you know,
seven to eight hundred big programs,
not like microservices
by any means.
Did you break that down
in the time after?
That’s what we were working on, right?
We were working on strangling that out and pulling that apart
into discrete business
capabilities with interfaces between
with decoupled
independent databases.
We weren’t aiming for a
microservice architecture. I think that
people, well,
I guess,
it depends what you call a microservice.
We were aiming for services
that did one thing well.
And, you know, teams owning theirs
and having external interfaces between teams.
But that’s what we did was we started using
a reverse Conway maneuver.
We built the teams around the architecture we wanted
and then talked about the interfaces between those teams
and gave teams the freedom to own how they implemented
things as long as they met the contracts between the teams.
So you also mentioned domain driven design.
That’s it, right?
Yes, that’s what we started with.
And we started with strategic domain driven design.
We started decomposing it.
We literally, we drew a box on the whiteboard
and set the called warehouse management system
and then started drawing boxes for each of the business capabilities,
had lots of debates about what belonged where,
came up with a disciplined approach of categorizing those things
and then drew out what the interfaces, you know,
how those would interconnect with each other
and then started building teams around those capabilities.
And it was very effective at coming up with it.
You know, you don’t want to start bottom up with that.
You want to have a high level idea of what is it you’re trying to build
based on the knowledge you had.
We already had a full fledged system, so we had a lot of knowledge
and we had deep business expertise in the engineering teams
because we’ve been in that domain
delivering that business problem for so long.
Coming back to Walmart and safe implementation, you said asking the question,
why, what was the answer about the question, why safe from business or whoever answered it?
So someone had to answer it because he or she had decided to go that way.
Oh, no, I never asked why safe.
Once we found that life can be so much better,
never looked back and told everybody else they should abandon it as well.
Okay.
Yeah.
But.
You know, from other people’s anecdotes.
Why safe?
Well, because you’ve got this easy thing that all you have to do is just buy this,
teach everybody this one process.
They all do this one process and now we’re agile.
As I feel, usually that’s a decision, centralized decision somewhere.
Oh, yeah, yeah, yeah.
Fairly high, fairly high management.
Yeah, yeah, fairly high management in the organization
who can say other organizations do that.
As well.
And that works.
And that’s why we do it as well, because then we get it.
Yeah.
But, you know, strangely, nobody can point me to a very successful organization,
you know, high performing, able to rapidly pivot on customers demands.
No one can point me to one of those that use the skill agile framework.
I know Google and Amazon don’t use skill agile framework.
Well, maybe they should.
No, no, I don’t think so.
You know, Amazon, I was talking, I was I was talking to Alistair Cockroft about this
while back, and he told me that after he joined AWS, that it was the company that was best
organized to scale rapidly, better than any other company, because every other team, he
told me, every team at Amazon was.
A business unit.
Basically, they had each team had their own P&L.
They were fully encapsulated everything they needed.
You know, they would consume platform services for other teams, right?
They didn’t have to own all of that.
But for the business capability they were responsible for, they had
they were fully encapsulated with everything they needed, including budget.
Of course, they also had to deliver value or they,
you know, or the team would just get shut down.
Right. But you could just cookie cutter that across business capabilities, just build a team
around a business capability and just scale horizontally as fast as you want.
All right. So, so two pizzas is still a good guideline.
Yeah. I mean, it comes back down again to a communication structure.
And if the team gets too big, it’s very difficult to communicate.
And on the first pilot team that we were working, that I was working directly with on CD, it was we had 15 people, including the product owner on the team.
And that was a lot of communication that came up to date with that was that was twice too big.
And if you know, if I were to do it again, if I had the option to do that, because I didn’t have all I didn’t have control over who was going to be on what team.
We just had a we need a team for this.
Definitely would have broken that team up into at least two teams.
It’s easier to coordinate.
I mean, the more the more the more moving pieces you have, the more communication, coordination cost you incur.
And so how do you.
you make it so you don’t
have to coordinate so much.
Okay. Do you have a hint for
breaking up such big teams
into smaller ones? Oh yeah,
is find a business
domain boundary within that team
so that you don’t have any
weird coupling between components
and then divide
the team on that business domain boundary.
I’d advise against
trying to do a front-end-back-end sort of thing
because then you’ve automatically coupled
two teams together. You can
deliver those individually
but it’s more difficult to deliver a feature
than if you had discrete feature
a full
stack slice.
There’s trade-offs.
There’s not a right and wrong answer
but it’s just better
if you don’t have to separate front-end and back-end.
But finding those
again using
the intended architecture application
to find the dividing line and then split the team.
I’d recommend, in my
experience, teams that are less than
four people are not sustainable
and four is right on the boundary line.
I think
five to eight people is a really good team size.
Alright.
On our preparation sheet I see
two things that
I would like to mention.
We talked about the
dojo topic in Walmart
and I read the
word safecracker.
Can you tell us
about that? Oh yeah, for
sure.
That’s
what we jokingly called ourselves
the dojo because we
couldn’t come into an area
and help a team do continuous delivery
while they were still doing safe.
And so in the process of teaching them
continuous delivery, all the things that they were taught
they were supposed to do under safe, we would
just have to gut
and just destroy that. It just wouldn’t work.
We’d have to explain to them
what we needed to change. We didn’t tell them
we were burning safe to the ground but we were burning safe
to the ground.
And we were doing it quite intentionally
because all of us had
suffered under that regime in our old areas
and we wanted it to
go away because we knew that
having the approach
we were taking was far more effective.
Both better for the teams and better
for customer outcomes. How many people
objected to you burning
safe to the ground? We didn’t tell them.
And they didn’t realize that that was what you were doing.
The
leadership in that area,
wanted teams
to deliver better. The teams
wanted help
in delivering better
and believed us. We said it was
going to be better for the teams. And so
we just said, okay, this is what we need to do.
They didn’t say, oh yeah, we’re going to burn safe to the ground.
It’s like, oh no, but you just need to operate this way.
Like, oh, okay.
Yeah, setting a goal and
giving a few hints
and at least giving freedom to
get teams
to find a way to the goal.
Yeah, it’s amazing how much happier teams
are when they’re able to actually deliver
things. Yeah, if you see
that you achieve something, that’s always a
good thing. It’s
motivating, that’s allowing
for feedback, that’s allowing for improvement.
It’s getting really
close to Daniel Ping’s
motivators, intrinsic
motivation topics, mastery,
purpose. No, and this is important
because what we discovered, we actually,
a teammate and I, gave a talk at DevOps
Enterprise Summit 2017 about this experience.
It’s called
a continuous delivery
solving the talent problem.
And the thrust of that was, number one,
you already have the talent, you don’t need to hire
different people or
you just focus on solving a problem
and the talent will solve the problem.
But the other, we had a slide
with like this pulsing heart on it
that said it made us love development again
because it became addictive. You deliver
and you get this
endorphin hit every time you deliver.
And
you know,
we’ve not been doing that for so long
that some people had never
done that. They got hired
in under this, we’re delivering every quarter.
Some of us had just forgotten how much fun it was.
But if you’re only
delivering every quarter, every six months
or every year,
it’s incredibly demotivating.
Yeah, I know organizations
that deliver once a year
but do that for the last,
I don’t know, 20, 30 years
and they have
all the pain with that.
But the developer experience
doesn’t mean pretty UIs for developers to stare at.
It means that we make it easier for them to flow ideas
to the end user and get feedback.
That they have a joyful work experience
that allows them to focus on the problem they’re solving
and not how the hell am I going to solve this problem
with the current way that we do things.
All right.
The last thing I see on our schedule
is the MiniumCD org community.
Is that something that’s spun out of,
um, your work around Walmart?
Is it, is it a part of Walmart?
What, what is it?
No, MiniumCD was just a, a, a project
that we brainstormed around the virtual bar
at DevOps Enterprise Summit last year.
That we’d seen all of these reports from people
talking about how continuous delivery
had been banned in their organization.
Or yes, we deliver continuously on,
I mean, no, I’m sorry.
We deliver on demand once a month.
That’s no, that’s not, it’s not CD, right?
Uh, and so we’re seeing people, um,
putting out anti-patterns, uh, seeing people actually,
you know, developers actually getting hurt.
Um, and we knew that if you actually did CD,
that you would really see the benefits
that they talk about and accelerate.
They talk about it, continuous delivery improves
delivery pain and organizational culture
and all these things.
That those are real if you’re really doing CD,
if you actually solve that problem.
So we came up with a, this idea,
what if we came up with a list
of things that are true in every context
where they’re delivering a web app to the cloud
or to an air-gapped environment, you know,
to, you know, embedded systems, no matter what.
What if we came up with a list of things that are,
these should all, these things need to be achieved
for you to be doing continuous delivery.
Just the minimum set of things.
And we came up with a very small list of things
that are true in all environments.
And we were pretty brutal about cutting some things too.
Cause people was like, oh, we should have this on list.
And, and it was like, yeah,
that’s a really good idea, highly recommended,
but it’s not true in every context.
And it doesn’t actually,
isn’t required to safely do continuous delivery,
but it’s a great idea.
So let’s put it on a list of, you know, after the minimums,
but let’s get people to that list of minimum things.
Took us about three days to hammer that out.
And then we started collecting signatures at the conference.
So, hey, do you agree with this?
Would you sign on?
And we had, you know, some, some, some names
from the conference who were involved
with the bar discussion, you know,
cause we kept telling people, hey, we’re next break.
We’re talking at the bar about this, come join.
All right.
Just pulling in as many people,
Rosalyn Radcliffe was on there,
giving her feedback from a mainframe perspective, you know?
And then after the conference started soliciting signatures
from other people in the industry.
So Michael Nygaard signed onto it
and then sent it to Dave Farley.
He submitted a pull request to tweak some of the language.
And so he’s a contributor to it.
And at this point, you know, if I pull it up,
I can pull some stats for you.
We’re sitting at 39 contributors from across the globe.
We’ve got translations into multiple languages.
The first translation was actually Finnish
because one of the contributors,
Ferek Sovis, is in Finland.
I was shocked to discover, there’s no German in the mix.
I was shocked to discover there’s no German in the mix.
I was shocked to discover, there’s no German in the mix.
German translation. Well, it’s because
nobody from Germany has translated it.
So, you want to be… So, Luca, how about
we do that? Yeah. I was just going to say.
But so, yeah, we’re in
Spanish, French,
Italian, Portuguese and Finnish.
We’ve got
124 people signed on to it so far.
So,
yeah.
And that’s all well and good,
cool, nice hobby, bro.
But we are, I keep getting feedback
from people that they are starting
to use this as a
roadmap to help improve things
because we literally have a section
called Starting the Journey that
kind of walks through some of the common struggles
that people have going down this journey
to give them hints and try this
and try this, try this, see if
this works. And we keep
trying to expand some of the information out here,
but it’s an open-source
community project. How do we
help each other?
No, no. I like it.
And also, I like that it’s
delightfully blunt. There’s no
you know, no humming and hawing
about it. It’s like, all feature work
stops when the pipeline is red.
Yeah. That’s nice and
straightforward and very shocking
to many people, I think. Yeah, no.
And because those are core
behaviors that are really important
for the culture we want.
If we can’t deliver, nothing
else matters. And
which, you know, brings you back to
what’s our very first feature on any product.
The pipeline to deliver,
the product. That’s the very first feature
because it’s like, I explained
to somebody once that it’s like adding
linting to a JavaScript project when it’s
done.
Right? The pipeline
is your verification
that we’ve done things correctly.
Right? And you don’t want to bolt that on at the
end. And every line of code that
we write that we can’t deliver
is risk.
You know how I got into
DevOps? When I started
to be a freelancer, I thought I
was going to be a QA professional.
You know, I like testing. I’m good at it.
You know, this is fun to me.
Until I realized that
I couldn’t actually be a QA person
successfully without taking control of
the entire value stream.
And that is
how I accidentally ended up in DevOps.
You know how I learned how to test?
Because, you know,
I spent years working in a language
that didn’t, there’s no, I’m not even
aware a testing framework exists for it.
Right?
The way I learned how to test was, hey, we’re going to
do this continuous delivery thing. I’m like, oh, hang
on. That means that I’ve got
to push
code every single day to production.
You know,
we’re manually testing.
We can’t ship untested
code. So we have
to, and this was not just me, this was like
the entire area, right? We have to learn
how to test.
And so, and then, but then you start adding
rules to it because of continuous delivery.
Well, our test architecture has to
meet the requirements of
no human touch after commit.
So we have to architect all
of the, you know, all of the
verification with that mindset that I can’t
hand it off to somebody else. Can’t happen
afterwards. A pipeline has to verify every
line of code. So that means all of the
tests have to be written and versioned
with this commit. Right?
And so it starts changing your mindset about
how you architect tests.
And a lot of people struggle with that. And they’re like,
oh no, this is how you test. Oh no, that’s how
you test. But that’s not how you test
for continuous delivery.
Wonderful. I don’t think, I don’t think we
can get any better than
this for a nice ending for
this recording, can we?
That’s for you to say.
No, but this is,
this I think has been an awesome episode.
I think I learned a lot.
And we are running
way over time anyway.
Yeah, I’m happy with it as well.
So, very great job
you did, Brian. Thanks
for all the
ideas and things you
shared. Not making
it a rant only,
but also
good, positive
ideas
and
experiences.
Yeah, and just FYI, I’m
feeling a little under the weather today, so
I’m a little spacey, so
some of my answers
might be a little…
But
no, I think that’s one of the things that
we were really trying to pull off, by the way, you’re talking about
how just direct it is, is that this is an engineering
discipline. This isn’t
hand-wavy, agile-y,
coach-y,
you know, whatever, right?
This is an engineering discipline.
And so we can just be, this is,
there’s something,
things that are, should always be true
and there are other things that it depends,
but this is what it is.
And as engineers, we shouldn’t have to sugarcoat
it. This is something
that I always find interesting about those
agile conversations. Just like you said, Brian,
that this is
just good, solid
engineering craft.
When I was at
university, my,
so I’ve got a degree in mechanical
engineering, and my professors would bang on
about what is called in German
Ingenieurmäßiges Vorgehen,
an engineer’s approach,
or the engineer’s approach. And that was
just be iterative. Think of
something, form a hypothesis,
find a way of falsifying
it, and then move on depending
on what you observe. So by
no means software-specific. This is
by no means new. Like, I can guarantee
you, I wasn’t there, but I
can guarantee you that the wheel wasn’t invented
in a waterfall process.
I mean,
they didn’t have a finalized
idea for a wheel before they started.
No, I agree.
I think that
there’s so many people
out there who just
think that this is an art form.
And say it’s not engineering.
Well, engineering includes art. The Chrysler
building required engineering, but
it’s also art. But it’s well
engineered. It’s not just kind
of random throw shit together and see
if it works. Right?
And this whole idea that, oh, this is
just something that we just kind of
do, and it’s… No, no, no.
We need some discipline and rigor
around this if we’re going to do this well.
And we owe that to ourselves
because it’s a better way of working.
This is not a hobby. If you want to do
hobby coding, do that at home.
Yeah. Agreed?
Fine. So it
sounds like we’ve got the final word
after the final word.
Oh, that was
my post-recording rant.
It’s still recording, though.
Okay.
All right.
So in that case, let’s just
wrap this one up.
I was going to say,
Sofalco, how
hard did Amadeus rock you?
I don’t know. I was rock…
As a baby, I was rock very good.
I really
like Amadeus.
I also love
that Austrian singer
you’re referencing.
Oh, there’s one other thing
to add, which is there’s
a parody site that
you might enjoy.
Scaled Agile DevOps
Maturity Framework.
Yeah, we’ll be sure to put that into the show notes.
Yeah, I’m not the…
That was an idea that came out of the
Dojo Consortium.
I didn’t invent…
I’ll say that the title
came out of the Dojo Consortium.
But that’s been a labor of love over the last…
Oh, 18 months or so.
It’s beautiful. It is absolutely beautiful.
All right. So, Brian,
thank you so much. This was a very
enlightening conversation, and I hope
we can have another one another day
when you’re better rested.
Yeah, I’m sorry I’m a little lightheaded today,
but thanks for having me. It was fun.
Okay, so goodbye, everybody.
Bye-bye.
Bye-bye.

Folge 65: Bryan Finster on SAFe at Walmart, and the downsides of SAFe [EN] 1/2

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In this episode, the speakers delve into the complexities of implementing the Scaled Agile Framework (SAFe) in large-scale projects, particularly in the context of a large organization like Walmart. They discuss the inefficiencies and drawbacks of SAFe, highlighting how it often leads to increased bureaucracy and fails to address core engineering and delivery problems. The conversation shifts to emphasize the importance of continuous delivery, effective team structures, and engineering excellence. Real-world examples from Walmart’s transition away from SAFe to a more effective agile model are used to illustrate these points.

Inhalt

  • Introduction to SAFe and its implementation in large organizations
  • Critique of SAFe: Increased bureaucracy and inefficiency
  • Importance of continuous delivery in agile transformation
  • Shifting focus from process to outcome in software development
  • Walmart’s experience moving away from SAFe
  • Emphasis on team structure and engineering practices
  • Introduction to Enterprise Dojos for effective learning
  • Role of behavior-driven development in clarifying requirements
  • Discussion on continuous improvement and agile mindset
  • Conclusion and teaser for the next episode

Shownotes

SAFe is not Agile

Doing Agile vs Being Agile

Information for decision-makers considering the SAFe framework

Backwards Bicycle

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

DevOps auf die Ohren und ins Hirn.
Ein Podcast rund um DevOps
Von Dierk Söllner, Falko Werner und Luca Ingianni.
Okay, and why is that necessary?
Like, why do we
need to scale? What is scaling in the
first place? Well, I don’t think
honestly that we do need to scale, but
scaling would be, you know, we’re all
instead of having a
team trying to deliver
something, you’ve got
a much larger group trying to
deliver things and
scaling the
agile process up to
a level above those teams.
So you wind up with, instead
of a team scrum, you have a scrum of scrums
where you have, you know,
the teams have their stand-up
and then you have a stand-up of stand-ups.
That sort of thing.
You have things like, oh, we’re all going to have
standardized story points so that
the project manager knows how big
a story point is from team to team to team.
You know, we’re going to
do these things
at a scaled-up level.
Okay.
Which sounds like it’s actually
quite necessary. Like, I can’t imagine
delivering a
product that’s this, you know,
a car, let’s say. You know, something as
complex and big as a car
without having to scale up and
having to coordinate between potentially
hundreds of thousands of engineers.
But, you know, all those parts that were built for the car
were all built independently on their own
schedules and then
assembled.
You know, the first
well, and let’s just back up, you know, the
first experience I had with SAFE as I was working,
on one of these giant things.
We’re talking about, you know,
a warehouse management system that’s 25
million lines of code that’s built by
about 400 developers scattered across
multiple teams.
There was no boundaries
between teams at the
code level. We were basically
feature factories. Here’s a feature for this
team, feature for this team. We’re all touching all the
same code. You’ve got
branches that last for like a quarter
that get integrated once a quarter.
And so what obviously
what we need is SAFE to
coordinate all this effort. Strangely,
no, that didn’t help.
But we did have more meetings
and
more roles for more middle management.
So we acquired
that. But,
you know, there’s deeper levels
of problems there that you can’t
fix with process. You can’t just scale
agile
and add this process on there
to overcome the
fundamental problems of the architecture,
the team structure was terrible.
You know, we didn’t have
the right organization
actually deliver in a truly agile
manner. It was basically
waterfall with agile bolted onto it.
Okay, so
that was a fairly big word,
truly agile. What
is true agility?
True agility is the
ability to continuously deliver value to
your end user. I honestly don’t think
there’s lots of people who claim they’re agile,
My firm belief is if you can’t deliver on demand today, which you made changes to today, then you’re not Agile.
I mean, the fact of the matter is, is that the purpose of the whole Agile thing isn’t stand-ups, isn’t two-week sprints.
The purpose is to get feedback on what we’re delivering to find out if it’s the right thing to deliver.
I’ve got to, I try to pare things down to make them easy enough for even me to understand.
And one of those is Agile mindset.
And you hear about people talking about Agile mindset all the time.
It’s like this, it’s like this vague culturally thing, but it’s not vague.
Here’s the Agile mindset, really, to me, all right?
The requirements are wrong.
If they’re not wrong, we’re going to misunderstand them.
And if we don’t misunderstand them, they’ll change before we can deliver them.
And so we are trying to deliver things in such a way that we’re minimally wrong.
We have a value hypothesis that we’re trying to implement.
Okay, cool.
We think if we deliver this, we’re going to get this value.
Now, what’s the core of that?
What can we deliver, the smallest thing possible, to invalidate that hypothesis?
Let’s not build the whole thing and cross our fingers.
Let’s build small pieces, ship them frequently, get feedback, and then adjust the implementation as we go.
And if I’m doing quarterly PI planning for all of the things we’re going to deliver,
that means that I’m going to get indications of my value hypothesis.
At the end of the quarter, or even at the end of the sprint, terrifies me.
That’s much too much change.
I want to know tomorrow about what I built today.
What do you need to get this working if it’s not a framework, descriptive thing, bringing roles and processes and so on,
and prolonging the time for feedback in such a setup that you explained or described earlier?
We have 400 or several hundred people working together on a big chunk of code.
So, we went through the effort of saying, okay, we’re not meeting our goals.
We weren’t meeting our goals before we tried SAFe, and we met them even worse when we implemented SAFe.
And so we said, okay, what we need to do to meet our goals is we need to figure out how we can,
instead of delivering every quarter with, you know, giant war rooms at the end of every delivery,
because we’re going to break things, we want to deliver every two weeks.
That was the ask, was every two weeks.
And so our SVP,
told us, you know, the group of senior engineers in the area, how do we do this?
And so instead of bringing in, you know, an agile coach and saying, what we need is better agile process,
he just left it to the engineers, how do we get this done?
And so we got copies of continuous delivery, poured through them.
We had done some looking into domain-driven design, and we had these goals, you know, the team we need to be able to deliver continuously.
Every team needs to be able to deliver independently of every other team in any sequence.
Because at 3 o’clock in the morning, you can’t couple two teams together.
And let’s say with SAFe, you have release trains to couple teams together to manage that all of those dependencies as one thing.
Well, if they’re one thing, they should be in one team.
So what we do is we re-architect the application so that they’re not one team.
So we started carving out business domains, assigning those business capabilities from the warehouse management system to teams, created real product teams,
who owned that product.
eine bestimmte Fähigkeit, die Kontakte zwischen ihnen erstattet haben, Domain-Diagramme
innerhalb des Teams und über alle Teams, so dass wir wussten, wo all diese Interfacen
waren, so dass wir sehen konnten, was die Architektur sein wird, um sicherzustellen,
dass wir keine seltsamen Abhängigkeiten zwischen diesen Teams hatten, und dann
Dinge apartieren begonnen haben.
Und so konnten diese Teams sich unabhängig von einander erledigen, so dass wir de-skalierten.
Und das Team, das ich an diesem Versuch leitete, das eine Entwicklungs-Team, das wir
an einem Zeitpunkt 5-10 Mal pro Tag erledigt hatten, musste keine Verabschiedung von
einem anderen Team bekommen, musste nicht zu einem Release-Train-Ingenieur gehen.
Wir bauten Jenkins Pipelines, wir hatten ein sehr kleines Plattform-Team von ca.
vier Leuten, das Jenkins Pipelines templatiert hat, damit es so war, dass wir
wiederholbare Dinge hatten, die es schwer gemacht haben, Fehler zu machen.
Und dann haben wir einfach geschickt.
Es war liberierend.
Okay.
Ist all das, was du gemacht hast, verboten von SAFe?
Oh nein.
Nein.
Also, du kannst all das mit SAFe machen, es ist nur so, dass du SAFe tun musst.
Aber das Problem, das ich mit SAFe sehe, ist, dass es so eine schwere Liste ist, um alle
auf dem Rahmen zu trainieren.
Also was ich von SAFe-Mitgliedern immer höre, ist, dass, naja, das Ding, wo ihr
angefangen habt, das ist einfach, das ist Shoo, das ist für Shoo-Hah-Ri, das ist
deine Apprentiss-Level-Dinge.
Okay, aber du trainierst.
Ja.
du weißt, tausende Entwickler auf deinem Apprentice-Level-Ding,
der Preis für Training auf diesem Niveau bedeutet, dass nichts verbessert wird,
weil es in der Form ist, und du hast Jobs geschaffen,
du hast einen Release-Train-Ingenieur geschaffen, der nicht ein Job sein sollte.
Ich habe Pipelines dafür, aber du hast einen Job für einen Release-Train-Ingenieur geschaffen,
was bedeutet, dass es sehr schwer ist, davon wegzukommen, weil du jemanden’s Paycheck nimmst.
Ich sehe das, aber ich sehe auch die aktuelle Transformation,
wo ich von Waterfall, von Agile Teams, von vielen anderen Start-Ups sehe und versuche sie zu verstehen,
was andere Leute machen, organisieren, kommunizieren, und von diesem Punkt aus
versuchen wir es immer noch zu machen.
Und um Agile Mindset in Ordnung zu bekommen, müssen wir immer noch die Rollen abschneiden,
um zu dem zu kommen, was SAFe vorgibt.
Wir geben also keine neuen Rollen hinzu, wir müssen wirklich darüber nachdenken,
nicht nur die Rollen abschneiden, sondern auch die Leute abschneiden,
die im aktuellen Waterfall-Line-Management und Flow-Organisation-Management
um zu dem zu kommen, was SAFe vorgibt.
Ist es nicht vielleicht eine gute Sache, viel Überprüfung zu reduzieren, um zu diesem Eingang zu kommen?
Und vielleicht einen nächsten Schritt zu gehen, was du auch vom SAFe aus sagen würdest,
zum Intermediaten?
Aber anstelle von Leuten zu sagen, was der nächste Schritt ist, weil, ja, das wäre eine
Verbesserung.
Aber anstelle von Leuten zu sagen, was der nächste Schritt ist, warum sollten wir nicht
einfach nur unseren Zielern sagen und dann den Weg mapieren?
to get there.
I’ve frequently had this conversation
with people. It’s like, I don’t know, we need to meet them
where they are. Of course we need to meet them where they are.
But meeting them where they are,
the argument I get is
from people is that we just need to tell them
what SHU is.
Tell them where the next step is.
No. What if we just told them
I can deliver daily
in any architecture,
on any platform,
if I have everything in place to get that done.
And that includes the right
tooling, the right processes
and the right people’s mindsets
and the right architecture of the organization.
I can do that.
This is where we are today.
Now what’s our roadmap to get to that?
Because, you know, honestly
I’ve heard people tell me they don’t need
to deliver continuously because their
customers don’t want features that frequently.
They definitely want fixes that frequently.
If something’s broken, they want it fixed
now, not on your next monthly
release. Yeah, but they don’t also
care if that’s tested, but
and working the same process,
the same pipeline
as a release, they just
want it fixed. So hot fixes
with little or to
no testing would
be sufficient. Yeah, I mean, if it’s
a dumpster fire, the thing we want to do
is throw a bottle onto
it and hope it’s not gasoline and
hope it’s water, right?
And we’re just praying, but that’s
just no. I mean, we want
to be able to quickly
fix vulnerabilities,
you know, we’ve discovered a vulnerability
that’s leaving us at
high risk for a data breach.
You know, do we want
to hot fix that in there? Do we
want to have a safe process that we
understand works every single time to get
that done? Now,
going back to your question, though, does
the safe, you know, the scale agile framework,
does it prevent these things? No. You know
why it doesn’t? Because they
cargo culted all of the ideas from
everybody. If you go and look at
all of the information that’s
in there, that’s good, all the good
information, it’s all from
other sources
on how to do these things.
Yeah, it’s from DevOps,
even
technology,
value stream
management.
Design thinking,
yeah, that’s what I usually
call safe as a vacuum cleaner.
But the problem that I
have with it is there’s lots of really
bad ideas.
If you don’t have the experience
to know how to tell
the difference between the good ideas and the bad ideas in the
framework, you’ll just get hurt.
It’s like the
analogy I gave one time was you have a
recipe book, right?
And some
of the recipes include cyanide
in them, but you don’t know cyanide’s
bad. And you’re just like picking
recipes and then hoping you don’t
get one with cyanide in it. A feature team
is a really good example of a recipe with
cyanide in it, right? It’s just a team that
runs around delivering features for other teams.
That’s not a good idea. It’s terrible for
the architecture. If you
do know what the bad ideas are,
you don’t need the framework as a
clearinghouse of, you know, as a smorgasbord
buffet of good ideas
because you already know what the good ideas are,
right? I don’t need certification
in it. I just
need to understand what the good ideas are.
All right. So what are the
good ideas of safe? So the good ideas
in safe, right?
Improving value streams,
value stream mapping is an important
thing. You can read them all about it in
continuous delivery and a whole bunch of
other previous literature.
The ability to deliver
continuously.
Safe has included that.
Organizing teams, but
although if you ask the authors of team
topologies, they’ll tell you that they have
modified their
ideas on team topologies
to make it more in line with what safe
wants to do instead of more in line with
effective delivery.
Right. And so sometimes they’ll just bring
things in verbatim and sometimes they’ll twist
them to make them more appealing to people that
are in a waterfall mindset,
which doesn’t get us to the next step.
It gets people to fake agile.
So yeah, there are good ideas in there and
they, they, they, I know where they took them
from the original sources are.
Yeah.
Yeah. Original sources is always a good thing
to know them, to get in touch with them.
Um,
we also had one of those authors in our podcast,
didn’t we?
Which one Manuel or
no, we, we try to, uh, in the end somehow the
communication fizzled out.
I, I really need to reach out to him again.
Uh, but yeah, well, I, I would love to talk to
that, to one or both of them.
Yeah.
It was ironic.
There was a medium post that, uh, uh, safe
filed at a, uh, a DMCA.
Uh, because they used, uh, and they gave credit.
They had a picture of the, of the diagram for safe.
And it’s, it’s just ironic that they’d file a DMCA
takedown on somebody referencing their stuff.
Yeah.
Yeah.
So you talk about the good stuff in safe, which, and I
don’t think they’re hiding the fact that they, you know,
they are taking good ideas from elsewhere.
You know,
sure.
I mean, we all do.
Oh,
of course it would be, it would be terrible if we
didn’t didn’t right.
But, uh, so what’s the cyanide you already told us you
don’t like feature teams.
Um, but what, like what’s, what’s the worst idea in, in
safe that you’ve, uh,
Oh, well, I, I think, you know, worst ideas is difficult.
Uh, I think it depends on what you’re trying to do right
that moment that’s impeding me from delivering value.
Um, but I, I think feature teams is.
A big one, the having somebody responsible for release instead of
having pipelines for release is a bad idea.
Uh, uh, the, um, release trains is a bad idea.
We should architect and re-engineer to not couple teams.
Right.
And we should go down that journey and get it done instead of codifying a
release train engineer to manage release trains.
That’s that’s just, you, you don’t wanna get locked into that.
It’s ties you to the slowest process on the, and makes delivery.
It makes delivery incredibly expensive and risky at the same time.
Those, those are bad ideas for sure.
Um, I didn’t prep with a list of other bad ideas off the top of my head.
I’ve, uh, I have a list of somewhere of things I really, really hate.
Well, if you find that list, um, like if it’s in an article or something,
we can link in the show notes.
Yeah.
And I do have a, a, a blog post called safe isn’t, uh, and I’ll send that to
you.
Oh, wonderful.
That sounds great.
So.
But yeah, so it, it’s, it’s interesting.
Maybe, maybe instead of being very general about it, maybe you can tell us
the story of what happened, uh, at Walmart, where you introduce safe and
then moved away from safe again.
Um, a couple of times, but maybe, you know, give us, give us the entire
trajectory.
Yeah.
And you have to understand when you’re talking about an organization like
Walmart, there’s not a monolithic, this is what happened because, uh, you know,
when you have.
Like 18,000 plus developers scattered across multiple VP areas, and you’re in an
organization with a culture of a lot of autonomy at the, at the director level, not even at
the VP level, uh, directors have a lot of power to decide what happens in their areas.
Um, and so there was, you know, people say, well, you just had a bad implementation of
safe.
Well, there wasn’t a implementation of safe.
There was multiple areas with different implementations.
And so I, there’s stuff that can be covered in the development of safe that I could go and witness.
So the, you know, the, the thing that, that I’ve was under personally was they, they brought
this in and they sent us all through training to learn how to do, you know, all
the themes, all the ceremonies for safe.
And we had a lot of ceremonies and we had a lot of, of, uh, of not breaking things down
small and delivering things fast.
It was just, okay, we’re gonna make things bigger so we can.
and have a bunch of meetings to make sure we have all of the dependencies mapped together
and we know that everything’s, you know, this feature has to release with this feature
and coordinate all of that and just do massive coordination.
You had, you know, retrospectives at the organization level once a quarter,
which didn’t make anything better.
You had a lot of very confused and demotivated engineers, you know,
software engineers trying to do work, but, you know, we’re focusing on all these meetings
and how to do SAFe correctly and trying to get better at that
because we’re told if we get better at SAFe, we’re just going to deliver better.
And, you know, we didn’t know any better because we had just come from a process
where they sent us all through PMI training to become project managers.
All the senior engineers, they gave us project management training so we could manage projects better.
And then they gave us SAFe, right?
And it’s still just PMI.
And it wasn’t until we actually started focusing on the CD that you could actually see,
oh my God, there’s like a totally better, different way to get this done.
We didn’t expect that it was going to be that much better.
We just thought it was going to be, we were able to deliver more quickly.
We were just trying to meet a business need.
But the fact that we were able to not only meet the business need,
but do it with higher quality, with better team morale and get faster feedback on things
and make it less expensive to try new ideas.
I mean, what?
You can get a Slack message from a distribution center to try something
and then spin around in a couple of days from their idea and to deliver back a result and say,
hey, what about this?
Do you like this?
Not even bug defects.
I mean, bug fixes, but it’s actually just ideas, right?
When you see that dramatic change from focusing on the engineering and focusing on the outcomes
instead of focusing on the process, and you’ve been living under that process for so long,
you kind of developed hate.
I don’t think hate is too strong a word.
Later on, when we started up the dojo and we were starting to work with the teams
that helped them with continuous delivery, and we’d walk into some areas,
weren’t using SAFe, they weren’t using anything.
They had teams just doing Scrum, and we’d help fix that so that they could actually deliver.
But then there’s some areas that are using different implementations of SAFe still at the time.
And you’d see things like quarterly planning, where people were listing out all of the stories
that were going to be delivered.
And which?
Which month of that quarter.
I mean, sorry, which week of which month of that quarter.
And it’s just, it was straight up waterfall without the discipline of a Gantt chart.
You know, it was just bad waterfall.
You had release train engineers who were blocking things because, you know, you’re stepping
on my toes.
Well, you shouldn’t have toes to step on because we don’t need release train engineers.
We need pipelines.
We need teams who understand how to deliver quality.
And so, but I’m still told that those.
Those are all just bad implementations of SAFe.
And I’m like, well, it’s incredibly easy to make a bad implementation of SAFe based off
of anecdotal evidence that I hear about and also direct evidence that I have.
I’ve never seen a good one.
And every time someone’s claimed to see a good one or implemented a good one, it’s like,
well, I mean, we just use the stuff that worked.
Cool.
I mean, I do that too, but we don’t call it SAFe and we don’t have PI planning.
Is there another thing that you…
That you would suggest to look at if it’s not safe and pick out the good things out
of SAFe or reading, you mentioned continuous delivery from Bay Farley or other sources
that you would prefer to start off with?
You start off with the problem.
I mean, SAFe is the solution to something.
Okay.
But what’s the problem we’re trying to solve?
And let’s go back to the definition.
So DevOps, the union of people, process, and product to enable the continuous delivery
of value to the end user.
All right.
Well, number one, we need to focus on why can’t we continuously deliver value?
Okay.
We also need to focus on the people, right?
How do we make it better for the people?
What in the system is hurting the people so that they can have better lives and focus
on continuously delivering value to the end user?
Do we have the right products?
You know, do the people have the tools they need?
And how do we…
How do we lean out the process?
You know, how do we look at every single process that we’re doing and say, is this
process actually adding value to the end user?
And, you know, can we deliver sustainably?
You know, the thing that I found most effective is just why can’t we deliver continuously?
Why can’t I deliver today?
And starting with why can I integrate working code to the trunk today?
When you start peeling apart those problems and trying to solve them, you’re not going
to solve those problems.
Then you find the, you know, the tooling and process solutions that you need to solve
those problems.
You start looking at your team structure and how the people are organized and say, okay,
well, this structure is poor for what we’re trying to do.
We have too much coupling here or too many handoffs.
You know, we’ve got a testing team.
Well, that doesn’t work at three o’clock in the morning.
So we don’t want a testing team.
We want the tests to be happening concurrent with the code to make it pipelines effective
at preventing…
We need to get better at doing that.
You know, when you start finding these problems, well, why can’t we do these things?
You focus always on the outcome you want, not focus on, hey, we need this heavy process
and we might get this outcome.
No, why can’t we get the outcome?
Fix those.
It’s just like any other engineering problem.
And so when you do that and you start peeling these things apart, you find the problems
in your context that you need to fix.
We actually, last year, DevOps Enterprise Summit created minimumcd.org.
Several of us were talking about people doing CD in ways that were causing them pain.
It was dangerous.
CD was getting banned places because they just said, hey, we’ve got a Jenkins pipeline.
We’re doing CD now.
And so we put together this list of problems to solve that either we can do this or we
can’t do this.
It’s not subjective at all.
That’s your minimum to safely do continuous delivery.
But the point isn’t CD.
The point is using CD to improve your organization.
And there you see architecture.
There you see then things that come out the other end of Conway’s law and whatever.
Then you look into all the different ideas.
You might get inspired by frameworks, but you don’t say, for example, less is a better
way to start or EAD or whatever.
Yeah, I would just look at what problem do we need to solve and then go and hunt down
some solutions to that problem.
When we started with why can’t we integrate code at least daily?
And the problem we had to solve is the requirements were unclear.
And so because the requirements are unclear, the tests are difficult to come up with, which
means we have to do a lot of exploratory coding to find out if it’s the right thing
and then do a test after instead of test during.
And so we had to go find a solution.
So we went, okay, what’s the solution to that?
And then we ran across behavior-driven development as a way to clarify things and make that a
disciplined approach to getting testable acceptance criteria out of a story instead of just it
should do some things and then go figure it out.
You guys can figure it out during coding.
I hated that.
You ask a product owner, oh, you’ll figure it out during development.
No, that’s not the way quality happens.
But things like that.
You know, it’s like, okay, we have this problem.
We need to come up with a solution for it.
And the solution isn’t more process.
The solution is better engineering.
But CD is an excellent way of shining a spotlight of what those problems are.
You quickly uncover things like the team structure is wrong.
Let me ask you how that feels.
If I’m trying to implement CD, how can I see that it’s shining a light on my team structure
as opposed to, I don’t know, my code perhaps or my CD pipeline?
Maybe my CD pipeline is just terrible.
I don’t know.
Well, I mean, your CD pipeline could be terrible.
Yeah, that’s a safe bet.
Hopefully, you’ll be in a better shape than we were when we started.
We had to just go and read books and figure it out.
And if you don’t have anybody who has any experience that you can call on, which gets
easier now, but back then it wasn’t.
If you don’t have that, you read books and figure it out.
So if, you know, you can tell your team structure is bad.
If you have things like there’s, you know, Bob owns that service and Bob’s not here,
so nobody can make changes to that service, right?
Or no, we can’t actually deliver to production because it has to go to the testing team
for them to validate it and then tell us whether or not it’s good or not.
So now you have an external handoff for delivery instead of having a deterministic pipeline.
The pipeline’s not deterministic.
You have tests that are flaky and you don’t trust your tests, but you ship anyway.
Okay, well, that’s terrifying.
You have to fix that because that means you’re going to be having to do a manual step.
Any manual step between commit and production is something to fix.
That’s a bad pipeline problem, right?
And so, or I have to wait two days to get information from a product owner because the
product owner is not part of the team.
They’re separate in the PMO.
So we have a poor communication structure in the organization.
I can’t deliver that way.
You just value stream map.
I mean, that’s the core tool right there.
If you map every single step from idea to delivery in that value stream, and I would
start at the team level and work up.
Other people prefer to go top down, but I found that if you start at the team level
and you start finding the impediments that a team has, then you can start building and
linking up to bigger value stream maps to find out.
It’s more of a graph, really.
To find out where the value stream is.
To find out where those problems are.
And then you can start looking at that and visualize, hey, this is a terrible structure.
How do we improve this to flow things better?
But don’t you have to do that with every team then?
And doesn’t it take too much time?
And maybe do it repeatedly with every team in a similar way and learn the same things?
No, every team turns out to be pretty different in the experience.
In the dojo, we would value stream map teams.
Either as part of an engagement or just to, hey, would you like a value stream map done?
Because it might help you.
Every team learns something.
There’s some similarities.
Everybody does requirements, coding, building, delivery.
But the details of that fluctuate wildly.
I had several value stream maps that would show me exactly why it is that you don’t want
an external testing team.
I actually have a blog post out there somewhere where I talk about the fact that, let’s go
back to Agile.
The Agile mindset, the requirements are wrong or they’re misunderstood.
Okay, well, so if the requirements are wrong, then you have a testing team and a development
team, each building their own code, because the testing team is either writing a manual
script or testing automation.
That’s code either way, whether or not a human is running it or not.
And the development team is coding, but they’re both coding based off of poor requirements.
So there’s not a lot of value there.
But worse is the requirements are fine.
But each team has their own code.
And the development team misunderstood them differently.
And what you see at the end is that the two come together and then there’s a triage process.
I saw this repeatedly on multiple teams.
There’s a triage process.
Is the test wrong or is the code wrong?
Now, for some reason, people have this bias to thinking the testing team is correct.
And then, you know, in that case, the development team has to prove that they’re not incorrect
because the testing team are testers.
So the test is correct.
But the test is based off of the same poor misunderstanding as the development team.
A different misunderstanding.
And then you go through the triage process.
You kind of get back to the product owner.
You cycle back.
You try to figure out which is right.
Then you deliver it and find out that everything is wrong.
And the end user needed something else entirely.
And people wonder why delivery is so painful and slow.
You know, it’s like reporting.
If you have two reports, one of them is wrong.
Always.
So let’s just bake it in so we have one report and get faster feedback on how wrong we are and fix it.
You’ve been mentioning this dojo.
What?
What is that dojo you were talking about?
Oh, yeah.
Thanks for asking.
So the enterprise dojos are something that Target started up back in 2014, where what they would do is they would bring a team into the dojo and help the team learn how to improve how they deliver in the team’s context with the team’s work.
So it wasn’t like some contrived classroom thing.
It’s like, okay, what we’re going to do is we’re going to bring you in.
We’re going to use immersive learning, where we’re going to use your work and we’re going to, instead of having a two-week sprint, you’re going to have a two-and-a-half-day sprint.
We’re going to deliver twice a week so that we can get rapid feedback over the next six weeks of what needs to be improved so that we can just keep snowballing that improvement.
In the context of Walmart’s dojo, we were focused on continuous delivery.
That was an enterprise goal we had to use CD to improve engineering excellence across the organization, improve delivery.
And so we were focused on CD, so it was basically, you know, why can’t we CD, let’s value stream map you, and then let’s work with you for the next six weeks with your code, in your context, in your area.
We, like, embed in that team for six weeks.
It wasn’t drive by coaching.
It’s like, oh, your tests are terrible.
Hey, let’s get in with you and let’s see how we can help improve those tests, teach you how to test better.
You know, you’ve got pipeline configuration issues here.
Let’s help with that.
Use Git flow.
That’s terrible.
Let’s help you learn how to do training.
We’ve got things like trunk-based development, right?
And hands on.
So it wasn’t like the hand wavy agile coachy thing that a lot of people suffer with.
There’s something else that I’m really curious to hear about.
And I wonder whether you, you know, you were part of those conversations.
Which is, how did that actually, how did that conversation actually go at the higher levels of management at Walmart?
At first, you know, introducing Safe.
But then later on saying, you know, this was a terrible idea and we need to roll it all back.
So we were really fortunate in the logistics area because our SVP was a really forward thinking guy.
He had been a software engineer for a number of years.
And I think leaving Walmart and coming back helped give him some perspective as well.
He’s the one who gave us that mission of how do we do this every two weeks.
And he basically gave us a blank check to do what we needed to do.
And so when we came to him with, okay, this is how we need to organize the teams.
And here’s the first teams that we should organize that way.
We need to make sure that they’re not going through a release train because the release train breaks the model we’re after where they can deploy independently of each other.
And he was like, okay, let’s do it because we’re not meeting our business.
We’re not meeting our business goals the way we were doing it before.
So you don’t just do it harder.
You need to change something.
And he supported us.
And not only was it just like, yeah, you should do that.
But, you know, he’d have biweekly meetings talking about things that people were improving in the area.
He was, I don’t know if you guys have seen the Smarter Every Day video with the reverse bicycle.
He had one built.
We had a reverse bicycle built to talk to people about mindset.
Change, right?
What’s the reverse bicycle?
So on Smarter Every Day on YouTube, they have a thing where the guy built a bicycle where if you turn the handlebars left, it turns the wheel right.
So you put a gear train on the on the on the handlebars and then demonstrated that you could learn how to ride that.
And in fact, it would adjust your brain so much after you got good at riding it, that you’d have a hard time riding a normal bicycle again until you readjusted your brain again.
It’s similar to I’ve seen experiments.
It’s where people put prisms on on glasses where you see upside down and eventually your brain adjusts.
And so he was using that to demonstrate, you know, the level of mindset change required.
That’s actually what you do is you see upside down and the brain adjusts so that it relates to everything is the other way around.
So it’s quite nice to see that the brain is that flexible.
But it really takes a lot of time.
Yeah.
Yeah.
Yeah.
It really takes a lot of time to unlearn if you already know how to ride a bicycle, a normal bicycle, to have this capability to ride the reverse bicycle.
And that really took took a lot of time.
And the same thing was what your ways of working that you have in an organization, the culture, the structures.
Those are the things if you want to get improvements.
Yeah.
Improvements.
Then you have to do change and you always have a lot of energy to put into to change something.
And the problem we have, though, and it’s coming back to safe is, hey, we’re going to we’re going to now we’re going to use safe.
Okay.
Why?
What problem are we trying to solve?
The issue is that you can’t change.
Culture is an outcome of change.
It’s not something you change.
And you don’t want to just change process because how do you know you’re doing the process?
Better or worse?
What we want to do is we want to focus on those outcomes.
What is the outcome we want to achieve?
Are we achieving it?
Okay, now let’s keep changing and improving things.
And then the process we use is an outcome of us improving our outcomes.
We don’t just dictate process.
We we focus on outcome and it involves, you know, on the the first team I was on, you know, I made a rule on the team is like we have all this all this scrum process we’re supposed to do.
I said, Well, no, we don’t have to do that anymore.
What do you mean?
No, no, no.
We’re we’re focusing on.
Continue.
So we’ve got this goal of delivering at least daily from this team.
So we’re going to do is we’re look at every process we do and make it prove that needs to exist.
We don’t do it, you know, stand ups taking too much time while we we trim them down.
Stand ups not delivering value.
Okay, we just won’t do that, right?
If we’re always if we’re sitting in the same area talking all the time, you know, do we need a stand up in half?
We’re visualizing if we’ve got a Kanban board up in the area, do we need to stand up?
You know, if we’re all focusing on that teamwork thing, then we’re a team.
What’s the point?
What’s the point of doing the stand up?
You know, we said we’re going to have retrospectives.
We’re going to do it much more frequently.
Because why can’t we every single day is like, why can’t we integrate code today?
What’s stopping us from doing continuous integration?
And then what’s stopping us from delivering every single day, multiple times a day?
And yeah, just focus on that.
Just make things better.
Hello, dear listeners.
It’s me again.
So this is the end of the first part of our interview.
And please look forward to the second half of it.
In roughly two weeks time.
See you then.
Goodbye.

Folge 64: Peter Lange zu DevOps im Infrastruktur-Betrieb 2/2

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Zu Gast haben wir Peter Lange, Geschäftsfeldleiter und DevOps Coach bei der PROFI Engineering Systems AG.
Mit ihm sprechen wir über DevOps aus der Sicht des „Endes der Nahrungskette“: dem Infrastruktur-Betrieb.

In dieser Folge des Podcasts werden die verschiedenen Aspekte von DevOps im Kontext des Infrastrukturbetriebs vertieft. Der Gast Peter Lange teilt seine Einsichten über die Bedeutung von Visionen und sinnstiftenden Momenten in der DevOps-Transformation, die Herausforderungen in der Zusammenarbeit zwischen verschiedenen IT-Bereichen und die Notwendigkeit einer kulturellen Veränderung. Es wird die Rolle neuer Technologien wie Kubernetes und Cloud-Infrastrukturen diskutiert, wie sie die IT-Landschaft transformieren und den Weg für eine zukünftige Entwicklung ebnen, die einen stärkeren Fokus auf Automatisierung, Plattformdenken und Produktdenken legt.

Inhalt

  • Einführung und Vorstellung der Teilnehmer
  • DevOps im Infrastrukturbetrieb: Grundkonzepte und Bedeutung
  • Herausforderungen bei der Implementierung von DevOps in Unternehmen
  • Die Rolle von Vision und sinnstiftenden Momenten in DevOps-Projekten
  • Technologische Aspekte: Kubernetes, Cloud-Technologien und deren Einfluss
  • Kulturelle und organisatorische Veränderungen in der IT durch DevOps
  • Zukünftige Trends und Entwicklungen im Bereich DevOps
  • Abschlussdiskussion und Ausblick

Shownotes

Peter hat zwei Buchtipps für uns:
The Other Side of Innovation
Team Topologies

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

DevOps. Auf die Ohren und ins Hirn.
Ein Podcast rund um DevOps.
Von Dierk Söllner, Falko Werner und Luca Ingianni.
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts DevOps auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Ingianni, Dierk Söllner und Falko Werner.
Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung.
DevOps umfasst für uns kulturelle, organisatorische und technische Aspekte.
Und letztes Mal haben wir uns mit so viel Spaß mit Peter Lange unterhalten
über verschiedenste kulturelle, organisatorische und technische Aspekte von DevOps im Infrastrukturbetrieb,
dass wir gesagt haben, wir machen einen zweiten Teil dieses Gesprächs daraus.
Und insofern ist auch heute wieder unser Gast Peter Lange. Willkommen zurück, Peter.
Hallo, auch willkommen. Vielen Dank für die erneute Einladung.
Sehr schön. Nachdem es uns ja etwas unsanft, das Netz uns etwas unsanft aus dem Gespräch des ersten Teiles gerissen hat.
Womit wachen wir denn weiter, Peter?
Mir ist im Nachgang, ist mir aufgefallen, auf deine Frage, wie das denn so abläuft.
Das war zwar richtig, aber ein bisschen inkomplett. Das würde ich gerne noch ein bisschen ergänzen.
Das letzte Mal haben wir davon, habe ich davon gesprochen, dass wir sinnvollerweise einen Sinnstifter finden,
wo die unterschiedlichen Teams sozusagen zusammenlaufen, der da auch eine Verantwortung hat.
Und dass es sehr wichtig und wirkungsvoll ist, wenn der die Vision für so ein DevOps-Projekt formuliert.
Damit ist es natürlich nicht zu Ende.
Also zum einen hat man dann natürlich die Herausforderung, einen Wertstrom auszuwählen.
Tatsächlich gibt es natürlich Produkte, die sind geeigneter, andere sind weniger geeignet.
Das ist wichtig. Dann ist es wichtig, ein Team zusammenzustellen, das man gegebenenfalls auch ergänzen kann.
Aber auch da, das Produkt, der Wertstrom und das Team müssen einfach sehr gut zusammenpassen.
Ja, nachdem man dann den Wertstrom schon mal hat und vielleicht auch ein erstes Mal visualisiert hat,
wenn es ihn schon gibt oder wenn es ihn noch nicht gibt, also ein Zollwertstrom,
dann geht es natürlich darum, über Architektur zu sprechen.
Eine Architektur zu definieren oder zu erarbeiten, was natürlich auch ein ganz wichtiger Part ist.
Zum einen ermöglicht es allen, mal über den Tellerrand hinwegzuschauen und das Gesamtgebilde zu verstehen
und ein gemeinsames Verständnis zu schaffen.
Ja, und dann geht es natürlich in Richtung, was wollen wir eigentlich für uns?
Welche Prinzipien brauchen wir? Welche Richtlinien brauchen wir für uns in diesem Projekt?
Ja, das ist natürlich auch ein ganz wichtiger Part.
Und wo müssen wir eigentlich für uns? Welche Richtlinien brauchen wir für uns in diesem Projekt?
Ja, und wo müssen wir eigentlich für uns? Welche Richtlinien brauchen wir für uns in diesem Projekt?
Und wo müssen wir Dinge vielleicht auch schon anders machen als bisher?
Genau, das sind so wichtige Anfangsbausteine, mit denen es typischerweise losgeht in einer Startphase von vier bis sechs Wochen.
Das wollte ich noch ergänzen.
Okay, also die Startphase ist aus deiner Sicht wirklich erstmal so ein bisschen eine Bestandsaufnahme, ein Klarstellen irgendwie?
Ja, das ist zu schaffen und tatsächlich auch zu schauen.
Dass das Produkt beziehungsweise der Wertstrom und das Team zusammenpasst.
Dass wir uns dann anschauen, was gibt es eigentlich für Architektur, Bausteine?
Vielleicht gibt es ja schon was.
Und auch den ganzen Kontext zu beleuchten.
Haben wir regulatorische Anforderungen?
Wie schaut eigentlich das Business aus?
Welche Akteure gibt es?
Eben nicht nur Menschen, vielleicht gibt es ja auch Computer als Akteure.
Welche APIs brauchen wir nach außen?
All dies in einer frühen…
In einer frühen Phase zu erarbeiten und auch für alle klarzumachen.
Das ist super hilfreich.
Und naja, ich plaudere mal so ein bisschen aus dem Nähkästchen.
Das Feedback der Teams ist, mein Gott, Peter, ist das trocken.
Und es ist zum Teil vielleicht auch schmerzhaft für die Leute.
Im Nachgang, manchmal Jahre danach, bekomme ich dennoch zu hören Mensch, Peter, es war zwar super trocken.
Und ich habe wirklich mit mir kämpfen müssen, aber es ist hilfreich bis heute.
Ja, es ist nervt, wenn man nicht endlich ins Machen kommen darf.
Jetzt reden sich alle irgendwie heiß über Kubernetes und was es so alles gibt und möchten gerne mal tüfteln.
Und dann kommst du und redest über, ich weiß auch nicht, Projektstrukturen oder so.
Ja, über Projekte, über Teamstrukturen, über regulatorische Anforderungen.
Softwarekomponenten, Hardwarekomponenten.
Alles, was man so…
In dem Werkzeugkasten, Togaf und andere Architektur-Frameworks halt hat.
Das kann bis runter zum Glossar, den wir in der letzten Folge angesprochen haben, gehen, wo man halt sagt,
okay, wie sieht denn jetzt wirklich unsere Sicht auf Begriffe wie Deployment oder Server oder was auch immer alles aus?
Und das kann natürlich echt trocken sein.
Ein bisschen interaktiver wird es, glaube ich, an den Stellen, wenn man dann in Richtung Wertstrom,
Wertstromanalyse, ist Wertstrom, wo können wir dann optimieren und so kommt.
Und ja, wenn man dann…
Wenn man dann echt in die Umsetzung geht, dann ist natürlich Bewegung drin.
Aber ohne das Fundament zu haben, ist es häufig nicht ratsam, gleich in die Umsetzung zu gehen, weil sonst macht man es halt drei- oder viermal.
Genau.
Und das ist halt auch einfach eine hervorragende Gelegenheit, für dieses gemeinsame Verständnis zu schaffen.
Also ich vergleiche das dann gern mit einem Architekten, der Häuser baut.
Es ist natürlich schon gut zu wissen, bauen wir ein Büro?
Ja.
Ein Haus oder ein Parkhaus oder ein Einfamilienhaus.
Und je früher man das gemeinsam festlegt, desto besser ist dann nachher auch das gemeinsame Verständnis.
Und desto besser kann man auch gemeinsam an dem Wert arbeiten.
Und dann kann man ja iterativ gut vorgehen, ne?
Ja, ganz genau.
Ja, ich finde, das ist eigentlich ein ganz tolles Bild.
So habe ich das noch gar nicht gesehen.
Aber es kommt nicht darauf an, wo die Steckdosen sind oder sowas.
Aber wir müssen uns wenigstens mal darüber im Klaren sein.
Brauchen wir einen Kuhstall oder brauchen wir keinen?
Wäre zumindest hilfreich, wenn man darüber ein gemeinsames Verständnis hat.
Und meine Erfahrung über die, ja jetzt ja schon Jahrzehnte ist, dass das manchmal in manchen Projekten, war das eben nicht klar.
Und dann gibt es Konfusion, babylonisches Sprachgewirr.
Und man wundert sich, warum Dinge nicht so funktionieren, wie sie eigentlich funktionieren sollen.
Weißt du, was ich glaube, Peter?
Ich glaube, es ist sogar genau umgekehrt, sondern es ist der Normalfall, dass diese Verwirrung besteht.
Und eigentlich ist es die bessere Situation, wenn das den Leuten wenigstens bewusst ist, dass sie dann auch keine gemeinsame Sprache haben.
Viel schlimmer ist es, wenn die Leute denselben Begriff für ganz verschiedene Sachen verwenden, so wie wir es im ersten Teil haben.
Was ist denn mit einem Server gemeint?
Ist das eine Softwarekomponente oder ist das ein Stück Blech im Keller?
Beides gleichermaßen legitim, aber wir müssen schon wissen, wovon wir eigentlich reden.
Da ist mir auch so wahnsinnig in Erinnerung.
Ich habe mal etwas, was ein Freund von mir mal erzählt hat, der, was war denn, ein CTO oder sowas von einem Hosting-Unternehmen.
Und der hat mal seine Teams gebeten, ihm ein Architektur-Diagramm zu malen von dem, was die da so machen.
Und kein Team konnte ein vollständiges und korrektes Architektur-Diagramm dessen malen, womit sie sich tagtäglich befassen.
Keiner von denen.
Interessanterweise die, die es am besten hingekriegt haben, waren zufällig die UXler.
Die wie?
User Experience.
Oder was heißt UX an deiner Stelle?
Genau.
Das ist, glaube ich, der Normalfall, dass es da ein gewisses Maß an Grundmissverständnis gibt.
Genau.
Und dann hilft es natürlich, da sind wir wieder bei Sprachaufhänden und Zusammenarbeit und Co.,
die Leute in ein Boot zu setzen, in einen Raum zu sperren und zu sagen, okay, jetzt mach das mal zusammen.
Dann können nämlich auch alle verschiedenen Sichten zusammenkommen.
Und nicht nur die Spezialisten im Diagrammezeichen, die UXler,
bringen ihren Anteil, sondern auch diejenigen, die letztendlich aus ihrer, keine Ahnung,
teilweise wahrscheinlich Silo-Sicht heraus auf das Gesamtprodukt schauen.
Das ist natürlich spannend.
Klar?
Absolut.
Und ich sage mal, so ein Kontext-Diagramm ist natürlich auch extrem hilfreich.
Wir haben das letzte Mal davon geredet, dass sich Teams auch verändern.
Es kommen neue Leute rein.
Da ist natürlich eine Architektur-Dokumentation, in der man beschrieben ist, um was geht es hier,
was ist der Kern, was ist außerhalb, was ist der Kontext, aus welchem Baustein besteht,
besteht das Ganze extrem hilfreich.
Und etwas, was ja typischerweise auch nicht jeden Tag angepasst werden muss
und damit auch vom Aufwand her überschaubar ist.
Du hast vorhin am Anfang des Podcasts, wie geht es dann so in so einem DevOps-Projekt los,
über einen Sinnstifter gesprochen.
Was kann ich mir da unter vorstellen?
Was ist so ein Sinnstifter?
Ja, das Thema Sinnstifter wird immer wieder nachgefragt.
Ich sage mal, wenn ich Menschen motivieren, zu einer Veränderung motivieren will,
dann ist der Sinn, also der Sinn der Veränderung extrem wichtig.
Also das haben wir auch, im Moment wird das auch allen halben kolportiert.
Wir brauchen einen Sinn, Purpose.
Das ist einfach nicht zu unterschätzen.
Und wer ist denn der gemeinsame Sinnstifter von Dev und Ops?
Irgendwo läuft es ja zusammen.
Wenn ich die Gräben nicht größer machen will, dann ist es tatsächlich hilfreich,
ich suche den, wo die Dinge zusammenlaufen und lasse den mal die Vision kommunizieren,
warum es jetzt hilfreich ist, anders zusammenarbeiten als zuvor.
Das ist dann aus Erfahrung jemand, der in einer Hierarchie im Unternehmen recht weit oben sitzt,
weil Entwicklung häufig aus anderen Budgettöpfen bedient wird
und in anderer Verantwortung liegt, als das beim Betrieb der Fall ist.
Kannst du das bestätigen oder hast du da andere Erfahrungen gemacht?
Oft ist es so, kommt auch auf den Kontext an, manchmal ist es auch ein Gesamtprojektleiter.
Ist ja auch möglich.
Also wenn es im Projektkontext ist, ist es manchmal auch ein Projektleiter.
Das ist sehr unterschiedlich.
Das kann auch ein Inhaber sein.
Im operativen Geschäft überhaupt nichts zu tun hat.
Den gilt es halt zu finden oder jemanden finden, der diese Rolle gut ausfüllen kann.
Und was sind so Beispiele für den Sinn einer DevOps-Transformation, DevOps-Projekt?
Beispiel, das mir noch einfällt, konkret war ein Projekt.
Da ging es eigentlich um ein Großprojekt, wo klar war,
dass die anfallenden Arbeiten auch infrastrukturseitig, manuell überhaupt nicht zu stemmen sind.
Und wir ein hohes Maß an Automatisierung brauchen, eigentlich diese 100%-Automatisierung.
Genau. Und dann war halt die Ansage, wir brauchen 100%-Automatisierung.
Wir haben sehr viele Entwickler, die müssen ad hoc Systeme,
ganze Applikationslandschaften bereitgestellt bekommen.
Und dafür brauchen wir die Infrastruktur.
Und eure Aufgabe ist 100%-Automatisierung und im besten Fall schon in einem Vierteljahr.
Wie lange hat es gedauert?
Deutlich länger. Nach einem Vierteljahr war es ausreichend gut.
Aber ich sage mal, wir reden hier über DevOps.
Das ist eine Reise, die hört nie auf.
Ich vergleiche das gerne mit Automobilherstellern.
Wann haben die angefangen?
Mit Toyota Production Systems?
Ich glaube, Ende der 40er des letzten Jahrhunderts.
Und die verbessern heute noch.
Nach 70 Jahren sind die immer noch dabei, Dinge besser zu machen.
Und so wird es auch dort sein.
Aber es ist natürlich wichtig.
Ja, der wichtigste Schritt auf dem Gipfel ist der erste, nicht der letzte.
Ja, die sind sehr weit gekommen.
Jetzt sind wir sehr, sehr weit gekommen und es geht kontinuierlich weiter.
Manchmal ist das sinnstiftende Moment, wir brauchen mehr Kundenzufriedenheit.
Wir wollen mehr Qualität.
Mhm.
Ja, das kann ja auch.
Das kann auch ein sinnstiftender Moment sein, all die Werte, die man mit DevOps erreichen
kann oder will.
Aber das klingt jetzt irgendwie, muss ich schon mal sagen, nach einem ganz schön dicken
Brett.
Und ich frage mich, Stolperfallen gibt es mit Sicherheit zuhauf, aber was sind denn
so die gemeinsten oder die verbreitetsten, wenn man sowas tatsächlich ernsthaft anfangen
möchte?
Ich denke mal, die wichtigste, die haben wir letztes Mal schon angesprochen, es ist
einfach die Manpower.
Ich glaube, der Betriebsaufwand, also das gemeinste ist eigentlich, dass der Betriebsaufwand
so hoch ist, dass ich mich um die Verbesserung von Arbeit nicht kümmern kann.
Ja, so dieses berühmte Beispiel von der stumpfen Säge, der keine Zeit hat, weil er Bäume fällen
muss oder derjenige, der ein Auto an der Tankstelle vorbeischiebt und keine Zeit zum Tanken hat.
Das hört sich blöd an, ja, ist aber so.
Und der Weg dort raus ist meiner Meinung nach, ja.
Ich muss natürlich temporär.
Ich muss da Zeit zur Verfügung stellen und dafür ist es halt hilfreich, auch mit extern
zu arbeiten oder so man sich dann bekommt, neue Leute einzustellen.
An der Stelle ist aber, finde ich, auch wichtig, also ich sage mal, Externe bringen halt nicht
nur, ich sage es jetzt mal, Ressourcen mit rein, sondern halt auch andere Sichtweisen.
Die Gefahr ist, und das ist, denke ich, auch ein wichtiger Aspekt, dass, wenn ich nur mit
intern arbeite, dass die mir das Gleiche nochmal in klein aufbauen, dass die wirklich,
dass die wirklich innovativen Dinge nicht passieren, dass nicht aus dem eigenen Kasten
herausgeschaut wird, ja, weil das haben wir schon immer so gemacht und dann sind die Ideen
vielleicht nur, nur halb so gut, wie wenn ich ein gerüttelt Maß externe Sichtweise
habe.
Das ist dann vielleicht auch eine Berechtigung für externe Berater oder Coaches.
Ja, also es kann schon echt hilfreich sein.
Ja, das stimmt, aus meiner eigenen Sicht als tatsächlich eben externer Berater ist es dann
auch einfach häufig so, gar nicht mal so sehr, dass man eine andere Sicht bringt, sondern
vielleicht auch einfach nur mal Mut machen muss und sagen muss, ja, ich habe das anderswo
schon gesehen und die haben das gekonnt und ihr könnt das auch.
Und dann hat man natürlich auch einen Kristallisationspunkt, wenn ein Externer da ist, dann auch zu sagen,
okay, der Externe.
Ich möchte jetzt mit jemandem aus einem Infrastruktur- oder Applikationsbetrieb sprechen, ich möchte
mit euch über Architektur reden, wir brauchen auch ein paar Entwickler am Tisch und dann
vielleicht auch die Karte, naja, das kostet ja sowieso Geld, ich bin ja jetzt nicht umsonst
hier, dann lasst mal alle, die eh da Kosten produzieren, mal ruhig mit mir zusammen an
einem Tisch sitzen.
Gibt es andere Wege, so eine positive, wohlwollende Atmosphäre zu schaffen, damit man auch in
Richtung Erfolg kommt?
Also was Luca schon angesprochen hat, ist auch einfach davon erzählen, wie es bei anderen
ist.
Also ich sag mal, das ist eigentlich der Klassiker, dass ich am Anfang gesagt bekomme, typischerweise
aus der Mannschaft heraus, manchmal aber auch aus dem Führungskreis heraus, ja, das mag
woanders funktionieren, aber bei uns funktioniert das nicht.
Ist ja so der Klassiker.
Und dann ist natürlich gut, wenn man vielleicht sogar aus der Branche kommt.
Ja.
Und dann kann man dann auch, wenn man im Führungsbereich noch Fragen hat, dann kann man halt auch da
nach dem Führungsprogramm, da kann man dann auch auf die Beispiele kommen, da kann man
mal sagen, ja, das wurde mir dort auch gesagt, und heute stehen wir aber an einer ganz anderen
Stelle.
Die sind nicht zu Ende mit der Reise, aber sie haben schon diese und jene Ziele erreicht.
Und ich kann euch sagen, wie wir da vorgegangen sind, wir können das auch hier mit dem oder
einem ähnlichen Weg versuchen.
Das bringt dann Vertrauen, das bringt dann ein bisschen Selbstsicherheit auch, um den,
ähm, den Wunsch zu erreichen.
Ja, klar.
Und das ist auch ein sehr guter Schritt.
Ja, klar.
Ja, klar.
Ich hoffe, das ist ein sehr guter Schritt.
Ja, klar.
den doch recht langen und häufig auch steinigen Weg der Transformation dann anzutreten.
Also den ersten Schritt, den du vorhin erwähnt hattest, auf dem Weg zum Gipfel auch wirklich zu gehen.
Ganz genau. Und ich sage mal, wenn wir jetzt schon bei der Metapher sind vom ersten Schritt,
hilfreich ist natürlich auch mal das Erreichen des ersten Basislagers sozusagen.
Also früh erste Erfolge zu zeitigen und die dann auch zu kommunizieren.
Und wenn denn erste Erfolge da sind, die kommuniziert sind und die dann auch angenommen werden,
dann wird es oft sogar ein Selbstläufer.
Übrigens auch nicht nur Erfolge, ich weiß nicht, zu kommunizieren, sondern überhaupt erst mal als Erfolge zu erkennen.
Das ist etwas, was ich ganz häufig habe, wenn es darum geht, zum Beispiel Testautomatisierung einzuführen.
Dann sagen die Leute, oh Mann, wir haben erst einen automatisierten Test.
Und dann sage ich, merkt ihr eigentlich, was ihr da geleistet habt?
Das war der schwerste.
Ihr habt eine Testinfrastruktur aufgesetzt, ihr habt euch Gedanken über Tests an sich gemacht.
Ihr wisst jetzt, wie man automatisierte Tests einerseits schreibt, andererseits ausführt.
Und wahrscheinlich sogar 90 Prozent des Weges sind geschafft.
Und die anderen 10 Prozent macht dann sowieso nebenbei, nämlich kontinuierlich den Testset aufbauen.
Klar kommt irgendwann nochmal so eine Phase, wo vielleicht nochmal ein Refactoring oder so notwendig ist,
wo man vielleicht nochmal die Regressionstests oder andere,
Testsets ein bisschen zusammenstutzt oder ähnliches.
Aber ja, das ist auf jeden Fall ein extrem wertvoller Punkt.
Und ich denke, Basislager 1 auf jeden Fall an der Stelle.
Ja, und das ist, denke ich, auch ein ganz wichtiger Punkt von zum Beispiel einem DevOps-Coach,
dass er in Retrospektiven das immer wieder hervorzieht, immer wieder die Leute darauf fokussiert,
was sie denn schon alles getan haben.
Genau.
Jetzt gibt es ein Architektur-Diagramm.
Wir brauchen jetzt einen neuen, der kann sich leichter einarbeiten.
Das sind ja alles auch echte Werte, die dort geschaffen werden.
Also sogar bevor es in die Umsetzung geht, werden ja Werte geschaffen.
Und das zu fokussieren und da immer wieder darauf hinzuweisen, ist, glaube ich, auch ein ganz wichtiger Erfolgsfaktor.
Ja, wir hatten ja zusammen in einem Projekt gearbeitet.
Und was mich so ein bisschen…
Was mich so ein bisschen überrascht hat, ist, dass häufig in den ersten Retros dieses
Wir haben uns zusammengesetzt und ausgetauscht über die Silo-Grenze hinweg.
Und wir haben ein besseres Verständnis geschaffen.
Wirklich die treibenden Erfolgserlebnisse der Teilnehmer waren, wo man sagt,
Okay, das ist ja jetzt eigentlich nicht wirklich ein Hexenwerk.
Also das macht doch mal ein Meeting und ladet mal jemanden aus Dev und Ops zusammen ein.
Ist häufig wirklich ein guter erster Schritt auf dem Weg zu
Wir haben einen gewissen Erfolg erreicht.
Und man wundert sich, aber miteinander reden hilft.
Ja, tatsächlich.
Also ich sage mal, am Anfang fängt man an, miteinander zu reden.
Und irgendwann arbeitet man sogar zusammen.
Das ist halt der erste Schritt.
Aber es ist ja auch schön, dass wir da an der Stelle immer wieder hilfreich sein können.
Weil es ja offensichtlich im Alltag gar nicht so einfach ist, zusammenzuarbeiten.
Aber es ist ja auch schön, dass wir da an der Stelle immer wieder hilfreich sein können.
Weil es ja offensichtlich im Alltag gar nicht so einfach ist, zusammenzuarbeiten.
Aber es ist ja auch schön, dass wir da an der Stelle immer wieder hilfreich sein können.
Okay, für uns warst du gerade kurz weg.
Aber nichtsdestotrotz, wir waren gerade bei dem erfolgreichen ersten Schritt.
Was sind denn die größten Herausforderungen auf dem Weg zum Basislager 1?
Oder vielleicht, wenn das zu kleine sind, die größten Herausforderungen auf dem Weg zum Gipfel?
Also was ich als eine große Herausforderung sehe, ist,
wir haben ja oft fragmentierte Organisationen, die sogenannten Silos,
wir haben ja oft fragmentierte Organisationen, die sogenannten Silos,
mit sehr unterschiedlichen Zielvorgaben und die Veränderung der Inzentivierung der Ziele.
Und das ist eine große Herausforderung, weil da brauche ich eben das Management.
Ich brauche das Management bei Ihnen, das erfordert auch Mut.
Ja, das ist eine der großen Herausforderungen.
Und dann die Entwicklung tatsächlich einer gemeinsamen Verantwortung.
Für die Beteiligten.
Auch ein großer Schritt, der halt aufgeteilt werden muss in viele kleine.
Und da ist es auch einfach sicherlich hilfreich, das auch mal transparent zu machen.
Also mal transparent zu machen, wo liegt Verantwortung, wo werden Entscheidungen getroffen
und an welcher Stelle ist es hilfreich, Entscheidungen abzugeben oder gemeinsam zu treffen.
Meiner Meinung nach auch ganz wichtige.
Ganz wichtige Aspekte, denn diese unterschiedlichen Ziele führen natürlich zu diesem Silo-Denken ganz stark.
Also mein Storage ist okay, der ist grün, also kümmert mich die Performance der Anwendung nicht.
Um es jetzt mal ganz platt zu sagen.
Ja gut, aber wenn man solche Messdaten, Messwerte erhebt, sind die natürlich dann, wie du sagst, Silo-bezogen.
Hilft das dann kundenfokussierte?
Kennzahlen zu erheben, also Kundenzufriedenheit wäre so ein Thema.
Oder andere, vielleicht auch unternehmensspezifische Richtung, keine Ahnung, Umsatz oder Gewinn oder Marge oder ähnliches?
Ja, natürlich. Das ist absolut hilfreich, ist aber gleichzeitig auch so ein Stück weit die Königsdisziplin.
Ich denke, da sollte man auf jeden Fall hinkommen.
Am Anfang steht, denke ich mal, die Silo-übergreifende, die cross-funktionale Sicht auf,
zum Beispiel Messdaten, aber mit Gipfeln sollte das natürlich in Business-relevanten Rundmeldungen, Feedbacks letztlich.
Weil am Ende sind es ja die wenigsten Firmen, die das Geschäftsfeld darin besteht, Storage zur Verfügung zu stellen, Server zur Verfügung zu stellen.
Die allermeisten Organisationen wollen etwas anderes.
Die Versicherung will Versicherung verkaufen.
Die Bank will Geld verwalten.
Der Maschinenbauer will Teile verkaufen.
teilen, produzieren.
Dann sind wir wieder bei dem, was du
einleitend als deine DevOps-Definition
genannt hast, diesen Wertfokus,
wie auch immer er sich dann konkret
darstellt.
Ja, natürlich, da muss es
hingehen und das ist schon auch,
weil ihr das vorher gefragt habt, ist schon
auch etwas, was nicht
von heute passiert, diese
Fokussierung der Leute
auf den eigentlichen Wert fürs
Unternehmen. Da kommen viele
Ideen und wenn du dann fragst,
okay, inwiefern
trägt das zu einem Mehrwert
bei? Das muss ja nicht
immer direkt ins Business gehen.
Manchmal ist es auch ein Mehrwert, wenn ich
regulatorische Anforderungen erfüllen kann.
Das kann durchaus
auch ein Mehrwert sein, aber
diese Fokussierung auf
Mehrwert, das ist
etwas, was nicht von
heute auf morgen geht und sicherlich
einer der spieglerischen
Komponenten
Tätigkeiten.
Und gleichzeitig
einer der wirkungsvollsten.
Vielleicht wollen wir ein bisschen die Richtung
ändern des Gespräches,
denn jetzt haben wir uns sehr viel auf
der kulturellen Ebene
aufgehalten, oder ich nenne es mal
pur kulturellen Ebene aufgehalten.
Solche Themen wie Wertfokus beispielsweise,
wie wertschöpfende
Kommunikation miteinander und so.
Und wir nennen es ja auch
DevOps im Infrastrukturbetrieb, das ist die
Überschrift über diese Folge.
Aber trotzdem frage ich mich,
wie kommen da jetzt eigentlich
neue Technologien, all das, was
auch viele Leute unter DevOps verstehen,
in diesem Thema
vor? Was ist denn mit
Kubernetes, sagen wir mal, oder mit
Docker oder mit Cloud
und all diesen Dingen? Wie hängt das
denn damit zusammen?
Das sind natürlich
viele der Dinge, die du
angesprochen hast, können
hilfreiche
Bausteine sein, ob sie es denn tatsächlich
sind, liegt natürlich,
liegt natürlich mal wieder
am Kontext. Also,
sag mal, sowas wie Containerisierung,
ja, ich weiß noch,
wie das damals mit, losging
mit der Hardware-Virtualisierung,
ja, also früher die
Emulation vom Betriebssystem,
wirklich Wine, etc.,
das war ja wirklich schmerzhaft.
Dann kam auf einmal Frau M. Währungs-Eck und hat
gesagt, wir machen alles anders und wir
virtualisieren die Hardware.
Auch da habe ich,
damals war ich sehr aktiv in diesem Bereich,
und habe sehr viele Widerstände.
So, jetzt haben
wir aktuell mit der
mit der Containerisierung,
legen wir die Abstraktion
wieder eins höher,
zu dem Anwendungsprozess,
und das ist natürlich
ein wichtiger und
hilfreicher Schritt.
Ich sag mal, ein Großteil,
ein großer, nicht zu unterschätzender Teil
der Betriebsaufwände liegt einfach
darin, Betriebssysteme
zu managen, zu patchen,
Sicherheitspatches, etc.
Leider Gottes auch
viel Produktionssysteme
anzupassen, ja, und dann zu hoffen,
dass es danach so gut funktioniert
wie zuvor. Also, insofern,
ja, diese Technologien sind
hilfreich, aber
nicht jede Technologie
passt in jeden Kontext,
und Technologie
allein schafft halt keine
Fähigkeiten.
Ich brauche die Prozesse dazu,
ich brauche die Menschen dazu,
mit den entsprechenden Skills,
wenn die Technologie allein
hilft halt nicht. Also, ich kenne
Situationen, da wurden Container,
Plattformen aufgebaut,
und die wurden halt einfach nicht angenommen.
Ja, und dann, also
der Mehrwert war praktisch null.
Ja, im Gegenteil.
Es wurde Geld ausgegeben,
ja, und
das war pure Verschwendung.
Ja, und da sind wir wieder
bei dem Teil,
wer ist eigentlich der Kunde?
Und dann können solche
Technologien natürlich total hilfreich sein.
An der Stelle, wir
haben September
2022, wir haben
ein Energiethema,
natürlich sind mit solchen
Technologien auch solche
Herausforderungen vielleicht besser zu stemmen.
Natürlich, wenn ich
Anwendungsinstanzen, die ich aktuell
nicht brauche, problemlos runterfahren kann
und problemlos wieder hochfahren kann,
dann kann ich natürlich auch
unglaublich viel Energie sparen.
Also, man glaubt ja nicht, wie viel
im Rechenzentrum im Kreis rumdreht
und Strom
in heiße Luft verwandelt,
ohne dass es benutzt wird.
Also, da sehr viel
Potenzial mit dem Hinweis,
die Technologie allein macht es nicht.
Und ob eine Ressource
bei mir im Rechenzentrum idelt oder
beim Cloud-Betreiber,
spielt an der Stelle
natürlich auch keine Rolle.
Ja, das stimmt. Ja, ich, ähm,
ich verwende da immer ganz gerne so ein Bild,
so wie,
wie wenn ich was anpflanze oder sowas.
Es geht mir nicht ums Substrat,
es geht mir nicht um die Erde, aber es ist halt nur mal notwendig,
dass die Tomaten wachsen können. Und ich glaube,
so ähnlich ist das auch mit all diesen
Plattform-Dingen, nicht wahr? Die sind
nicht hinreichend, aber durchaus notwendig,
damit ich die Früchte ernten kann, um die es mir
eigentlich geht.
Absolut. Absolut.
Mir fallen da andere Dinge ein, die vielleicht
noch notwendiger oder früher
notwendig sind, wie zum Beispiel
gemeinsames, gemeinsames Git.
So,
da,
da gäbe es schon, oder eine gemeinsame
Wissensplattform,
da gäbe es schon Dinge, die mir noch vorher
einfallen, ja, und die ich für
mindestens so, so wichtig
empfinde. Aber
du hast natürlich Recht, diese Plattformen
sind äußerst hilfreich
und in vielen Kontexten
auch das Mittel der Wahl.
Ich sag mal, Cloud wird da oft
insbesondere von den Anbietern als
Heilmittel dargestellt und
immer wieder werde ich
noch gefragt, ja, was ist denn jetzt eigentlich
Cloud und ist das denn immer Public
und da gibt es erschreckend
wenig Wissen eigentlich.
Ja, und
die Idee, dass es am Ende ein
Bereitstellungsmodell ist,
ist erstaunlich
wenig verbreitet. Ich ziehe dann oft
die Analogie zum Strom, also von der Erfindung
des Stroms bis zu dem
Zeitpunkt, zu dem er aus der Steckdose
kam. Ich glaube, das waren
20 Jahre, wenn überhaupt.
Beim Compute
hat es 100 Jahre gedauert.
Tatsächlich wird es
nach wie vor schlechter adaptiert.
Wer würde schon,
es gibt nur wenige,
die Strom produzieren, um ihn zu
nutzen. Tatsächlich
produzieren aber ganz viele
Compute, um es zu nutzen.
Aber es ist ein Bereitstellungsmodell und
das kann natürlich hilfreich sein,
muss es auch nicht und manchmal ist es so,
sogar gar nicht möglich aufgrund von
regulatorischen Vorgaben.
Das bedeutet ja nicht, dass ich
keine Cloud mache, sondern dass ich
vielleicht eine Cloud selber mache.
Das ist aber,
das ist etwas, das muss man sich halt
im Einzelfall anschauen,
aber es sind super hilfreiche,
super hilfreiche
Technologien oder im
Fall der Cloud Bereitstellungsmodelle
für solche Herausforderungen,
wie wir sie im DevOps-Umfeld erleben.
Mhm.
Dann ist das jetzt vielleicht ein guter
Zeitpunkt, um auch mal ein bisschen
aus der Vergangenheit oder der Gegenwart
sich zu lösen und mal ein bisschen in
Richtung Zukunft zu denken.
Wenn du jetzt mal so
extrapolierst die Reise, die du
und deine Kunden gemacht haben
über die vergangenen Jahre und Jahrzehnte,
was denkst du denn, wohin diese Reise
weiterhin gehen wird und wo siehst du denn
die aktuell größten Herausforderungen
oder die spannendsten Spielfelder?
Also
ich glaube, die Reise
geht gerade im Bereich
der Infrastruktur,
des Betriebs, noch
sehr viel mehr in Richtung
Plattform und Produktdenken.
Also die Zeiten,
in denen IT produziert
wird, wie in einer Manufaktur,
ich glaube, die werden
immer schwieriger.
Es wird mehr und mehr ein
Plattformdenken geben. Personen
werden sich auch umorientieren,
also nicht nur vom
reinen Denken, sondern auch von den
Skills. Die
Rechenzentren sind eher API
driven. Es wird immer weniger mit
der Maus am Arm
umgesetzt. Genau, das
ist einer der Dinge,
die ich sehe.
Die Art und Weise der Zusammenarbeit,
die wir heute
teilweise
schon sehen zwischen Entwicklern
und Anwendungsbetrieb,
das wird auch mehr und mehr
nach unten wandern in Richtung
Infrastruktur.
Die Methoden,
mit der wir arbeiten, die Werkzeuge,
mit denen gearbeitet wird,
das wird sich meiner Meinung nach
mehr und mehr angleichen.
Schon in vielen
Organisationen auf dem Weg,
aber mehr Unternehmen
noch nicht auf dem Weg und
das wird sicherlich ein
Teil des
Wandels.
Das ist dann das, was man
landläufig GitOps nennt, oder?
Ja, ich bin
gespannt, was nach GitOps kommt.
Was mich immer so ein bisschen fasziniert,
weil ich hätte irgendwie gedacht, dass das
schon immer gelebte Praxis war.
Ich möchte
wetten, dass zum Beispiel die Mainframe-Jungs
das vor 40 Jahren auch schon
von den Ansätzen her ganz ähnlich gelebt haben.
Vor 40 Jahren war ich
noch nicht in der IT, aber ich gebe dir natürlich
Recht.
Die haben das früher viel deutlicher
gelebt. Es gibt ja
neben dem Mainframe auch noch so
Midrange-Systeme, damals
hieß es AS400, heute glaube ich
i-Series. Dort waren
viele
Kompetenzen gebündelt.
Man hat sich eben nicht nur um die
Hardware gekümmert, sondern natürlich auch um den
damals Direct Attached Storage,
was wir heute teilweise auch wieder sehen,
über die Datenbank, die drauf ist,
bis zu den Anwendungen.
Das war alles in einem
Team. Und ja,
damals waren wir aus heutiger
Sicht weiter.
Lustig, oder? Ich finde,
das muss irgendwie so
sein in der IT. Das Pendel schwingt immer so ein bisschen
hin und her. Zuerst hatte man
Zentralisierung, dann hatte man Dezentralisierung,
jetzt hat man wieder Zentralisierung in Richtung
Cloud, jetzt kommt dann vielleicht wieder eine Dezentralisierung.
Und so ist es mit vielen anderen
Sachen auch, oder? Ja, mir fällt
dazu ein Geschäftsführer ein,
der tatsächlich einen IT-Hintergrund
hatte, neben seinem kaufmännischen Hintergrund.
Und der hat mir genau das
gesagt. Damals ging es
um Terminal Server,
und dann hat er gesagt so, ah, nee,
Herr Lange, ich beobachte
das jetzt schon seit langer Zeit,
seit 40 Jahren, das geht immer hin
und geht immer, und geht dann
wieder her. Und diesmal
setze ich einen Zyklus aus.
Kann man eben eigentlich nur
gratulieren zu dieser
Einsicht, wobei
was ich ganz klar sehe,
ist, dass DevOps
und DevOps
Vorgehen meiner Meinung nach
das IT-Produktions-
Modell der Zukunft darstellen. Davon
bin ich fest überzeugt.
Ja, es gibt ja auch nicht wenige, die sagen,
das ist die
Professionalisierung
letzten Endes endlich mal der IT,
dass man mehr
in Richtung nicht mehr Handarbeit
geht, wie du vorhin gesagt hast,
mit der Maus irgendwie in den Betriebssystemen
rumfuhrwerken, sondern in Richtung
einer Automatisierung,
einer Industrialisierung im weiteren Sinne,
dass das jetzt
die industrielle Revolution der IT ist irgendwie.
Ja, natürlich auch
der Digitalisierung. Mein Geschäftsfeld
heißt ja Digitalisierung und agile
Methoden, wie ich vorstehe und das ich
verantworte. DevOps ist natürlich
auch ein Stück weit die Digitalisierung
der IT-Produktion.
Und wenn wir uns
das anschauen… Was so lustig widersprüchlich
klingt, ne?
Ja, sollte man meinen. Und wenn man genau hinschaut,
dann ist es gar nicht so widersprüchlich.
Also, wenn wir uns anschauen,
die IT-Abteilungen dieser Welt
haben in der
Produktion, also die letzten
Jahrzehnte, den
produzierenden
Abteilungen enorm geholfen
weiterzukommen im Bereich der
Digitalisierung, im Bereich von
Lean-Production.
Diese ganzen Vorteile
und wenn man sich dann anschaut,
wie viel davon sie für sich selber
adaptiert haben, kann man ja
schon auch demütig werden.
Viele Erfahrungen, die
es in Organisationen gibt,
mit dem Thema, insbesondere
mit dem Thema Lean, kann man jetzt
natürlich auch für die
IT mitnutzen.
Wir fangen da ja nicht von…
Wir müssen das nicht
von Neuem erfinden.
Ja, und ich finde, das ist auch eine ganz gute
Nachricht, weil es
zeigt halt auch irgendwie, schlussendlich geht’s
ja um nichts Neues, um nichts anderes.
Wenn man ehrlich ist, zum Schluss geht’s
wahrscheinlich um Menschen, ne? Und Menschen
sind halt irgendwie immer Menschen.
Ja, das stimmt.
Wobei ich würde es ergänzen, es geht nicht
nur um Menschen, es geht natürlich auch um Prozesse,
es geht auch um Technologie,
neue Technologien zu adaptieren.
Aber der Mensch ist
natürlich ein ganz, ganz wichtiger
Player in dem Spiel.
Und der, der es
ermöglicht oder entmöglicht.
Genau.
Das klingt fast wie ein tolles Schlusswort für
eine Folge,
die sich ja nennt, DevOps im Infrastrukturbetrieb,
dass wir es auf diese Weise wieder
den Bogen zurückspannen.
Gibt’s noch was Wichtiges, was du loswerden
möchtest? Haben wir was vergessen?
Gibt’s was, was du noch genauer beleuchten
möchtest?
Ich weiß gar nicht, ob ich’s
ob ich was vergessen hab. Man kann
natürlich über DevOps, kann man ja reden,
Tage und Wochen lang.
Aber was ich schon nochmal
adressieren möchte, ist
die Veränderungen, wie sie
DevOps mit sich bringen, sind
ohne sinnstiftendes Moment
schwer umsetzbar.
Das ist wichtig.
Und ich hab’s schon
angesprochen, so eine Vision
und ein klares Commitment vom Sinnstifter
sind nicht zu unterschätzende,
äußerst kraftvolle Werkzeuge,
die Enormes
bewirken können und die man nutzen sollte.
Naja, und der Rest ist
harte Arbeit, Schweiß,
Tränen und sehr viel Lernen.
Und an der Stelle möchte ich auch
alle Zuhörer motivieren,
das ist es wert, weil
Arbeit wird dadurch eben nicht nur besser,
sondern auch schöner.
Ja, ich glaube, das hast du schön gesagt.
Das ist etwas, was ich auch als sehr wichtig empfinde.
Ich finde, Peter, das war ein tolles
Schlusswort und
wir haben ja jetzt auch schon wieder
mit Fug und Recht eine neue Folge
draus gemacht. Insofern danke
ich dir an dieser Stelle nochmal
vielmals dafür, dass du uns so viel von deiner
Zeit und von deinen Erfahrungen geschenkt hast.
Falls Leute noch Fragen haben,
dann können sie mit Sicherheit
einen Blick in die Shownotes werfen
und dort Wege finden, um mit dir
in Verbindung zu treten, um mit der profi AG in Verbindung
zu treten. Das Buch, das du erwähnt hast,
das packen wir natürlich auch in die Shownotes rein.
Und alles, was uns jetzt vielleicht auch im Nachgang
noch einfällt an Dingen, die wir als
Wichtige erachten für euch
liebe Hörerinnen und Hörer. Auch im Namen
von Falko, der jetzt irgendwie schon weghechten
musste, möchte ich mich
also nochmal ganz herzlich bei dir bedanken, Peter.
Und ich wünsche dir einen ganz tollen Tag.
Sehr gerne, gleichfalls. Vielen Dank
für die Einladung.
Vielen Dank.
Vielen Dank.
Vielen Dank.

Folge 63: Peter Lange zu DevOps im Infrastruktur-Betrieb 1/2

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Zu Gast haben wir Peter Lange, Geschäftsfeldleiter und DevOps Coach bei der PROFI Engineering Systems AG.Mit ihm sprechen wir über DevOps aus der Sicht des „Endes der Nahrungskette“: dem Infrastruktur-Betrieb.

In dieser Podcast-Episode sprechen die Gastgeber mit Peter Lange über die Integration von DevOps in den Infrastrukturbetrieb. Sie erörtern die Notwendigkeit, Infrastrukturteams frühzeitig in Projekte einzubeziehen, um Probleme zu vermeiden und effizientere Arbeitsabläufe zu ermöglichen. Es wird diskutiert, wie traditionelle Betriebsmodelle und die Kultur in IT-Abteilungen durch DevOps-Prinzipien verändert werden können. Besonderer Fokus liegt auf der Bedeutung von Kommunikation, gemeinsamen Regeln und einem veränderten Mindset. Beispiele aus der Praxis und mögliche Lösungsansätze, wie die Automatisierung von Prozessen und die Bildung cross-funktionaler Teams, werden hervorgehoben.

Inhalt

  • DevOps im Infrastrukturbetrieb
    • Integration von DevOps-Prinzipien
    • Herausforderungen für Infrastrukturteams
    • Bedeutung frühzeitiger Einbindung in Projekte
  • Kommunikation und Zusammenarbeit
    • Entwicklung gemeinsamer Sprache und Regeln
    • Bedeutung von cross-funktionalen Teams
  • Kultureller und organisatorischer Wandel
    • Veränderung der Betriebsmodelle
    • Einfluss von DevOps auf die Unternehmenskultur
  • Praktische Ansätze und Lösungen
    • Automatisierung von Prozessen
    • Rolle von Architektur und Design
    • Sicherheitsaspekte in DevOps (DevSecOps)
  • Ausblick und zukünftige Themen

Shownotes

Peter hat zwei Buchtipps für uns:
The Other Side of Innovation
Team Topologies

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

Hallo und herzlich willkommen zu einer neuen Folge des Podcasts DevOps auf die Ohren und
ins Hirn, gestaltet und produziert von Luca Ingianni, Dierk Söllner, Falko Werner, ich
sozusagen. Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung. DevOps umfasst für
uns kulturelle, organisatorische und technische Aspekte. Wir freuen uns heute auf das Thema
DevOps im Infrastrukturbetrieb. Zu Gast haben wir Peter Lange, Geschäftsfeldleiter und DevOps-Coach
bei der Profi Engineering Systems AG. Er ist seit 1999 in der IT. Angefangen als Security-Admin,
dann BSI-Grundschutz, das was man heute unter ISO 27001 kennt, Virtualisierung, Storage,
Netzwerk, Data Center Design, ToeGraph-Architekt bis zum Thema Agile und DevOps, mit dem er sich
seit 2015 am liebsten und leidenschaftlichsten beschäftigt. In unterschiedlichen Organisationen
hat er einen starken Infrastruktur-Hintergrund und meint, DevOps-Kultur gehört auch dort mehr
etabliert. Lieber Peter, wir haben in diesem Podcast die Tradition, alle unsere Gäste nach
ihrer persönlichen Definition von DevOps zu fragen. Wie sieht es denn von deiner Seite aus aus?
Ja, hallo erstmal. Ja, DevOps- Definition, da gibt es so viele. Irgendwie sind alle richtig
und alle auch irgendwie inkomplett. Ich bin dazu übergegangen,
mehr darüber zu beschreiben, was DevOps eigentlich tut. Und meiner Meinung nach verbessert DevOps die
Produktion von IT-Produkten und IT-Services in Bezug auf die Durchlaufzeit, die Qualität und
ganz wichtig, den Betriebsaufwand, mit dem Ziel, die Bedarfe der Kunden optimal zu erfüllen.
Also so eine ganz klassische Wertperspektive eigentlich, ganz wunderbar.
Genau, also willkommen auch von mir, Peter. Schön, dass du da bist. Möchtest du denn noch
was hinzufügen?
Also, kann ich da noch was hinzufügen zu dieser Vorstellung, die wir, die wir da gerade haben,
zuteilwerden lassen? Oder ist alles richtig gesagt?
Alles Gesagte ist richtig. Vielleicht findet sich im Rahmen des Gesprächs noch Dinge, die wir
hinzufügen können. Für den Moment, glaube ich, passt es.
Wunderbar. So, ich bin neugierig. Du sagst, dass die Infrastruktur Teams oft irgendwie so
am Ende der Nahrungskette stehen und man weiß ja, den Letzten beißen die Hunde, die, sagen wir mal,
Sie sind vom Business sehr weit weg, von den Entwicklern womöglich.
Sag mal, muss das so sein, Peter?
Das ist leider Gottes so. Es sollte meiner Meinung nach nicht so sein.
Daraus ergeben sich natürlich Konsequenzen, Probleme, die es nicht gäbe, wenn Sie ein bisschen näher dran wären.
Sag mal, oft entstehen ja Projekte im Fachbereich oder durch Bedarfe von Kunden, interne, externe.
Diese Ideen werden dann gerne auch in Software gegossen, umgesetzt.
Die Entwickler sprechen vielleicht noch mit dem Anwendungsbetrieb und der Infrastrukturbetrieb bekommt dann ganz spät etwas mit.
Vielleicht ist er ganz am Anfang mal irgendwo in der Planung mit drin.
Ja, und dann bekommt das über die sprichwörtliche Wall of Confusion geworfen, gerade so wie auch Anwendungsbetrieb.
Und das führt natürlich zu Ungemach, zu Verzögerungen.
Und das muss tatsächlich nicht so sein.
Meine Erfahrung ist zumindest, dass überall dort, wo es gelungen ist, den frühzeitig einzubinden, es deutlich besser läuft.
Zumal ja die Infrastruktur auch noch so Herausforderungen hat, dass Beschaffungsprozesse oft Wochen oder sogar Monate dauern.
Oh Mann, da weiß ich jetzt schier nicht, wo ich anfangen soll.
Du hast jetzt ein paar Themen, in die ich gerne einsteigen würde.
Aber vielleicht fangen wir einfach mal bei dem letzten an, was du gesagt hast, nämlich frühzeitig einbinden.
Was heißt denn frühzeitig und was heißt denn einbinden?
Tatsächlich miteinander reden, Collaboration.
Ich hatte in einem eurer Podcasts mal gehört, DevOps lässt sich auch mit Zusammenarbeit übersetzen.
Und das finde ich eigentlich ein ganz schönes Bild dafür.
Tatsächlich früh einbinden, im möglichst frühen Status der anzugehenden Projekte und dann auch sehr umfassend,
sodass die Kompetenzen…
Die Kompetenzen aus dem Betrieb, auch aus der Infrastruktur, letztendlich auch zum Gelingen des Projekts beitragen können.
Ich weiß nicht, ob ihr das seht, oft passiert das sehr spät und dann sagt der Infrastrukturbetrieb so, halt, stopp mal.
Und das wird dann oft so als Widerstand wahrgenommen.
In Wirklichkeit sind das natürlich auch, kommen die Widerstände natürlich auch aus Kompetenzen heraus, die die Infrastruktur hat.
Und wo sie genau wissen.
Da lohnt es sich, früh drüber zu reden.
Und diese Kompetenzen verhindere ich natürlich, wenn ich sie nicht mit einbinde.
Ja, klar.
In der Hinsicht finde ich das übrigens auch interessant.
Wir hatten, das muss Episode 44 oder irgendetwas gewesen sein von diesem Podcast,
hatten wir mal einen Site-Reliability-Ingenieur von Google zu Gast, der lustigerweise exakt dasselbe gejammert hat.
Der hat gesagt, ja, meine Applikationsentwickler, die kommen dann irgendwann ums Eck.
Und schmeißen mir irgendwie einen neuen Container über den Zaun.
Und ich darf dann schauen, wie ich den auf meinem Fuhrpark am Laufen halte.
Also selbst in den schicken, funkelnden Unicorns ist offenbar in der Hinsicht nicht alles Gold, was glänzt.
Wie kann man es dann besser machen?
Wenn es selbst bei Unicorns oder bei, ich weiß ja nicht, was das für Unternehmen sind, von denen du redest, Peter.
Sind das auch Groß-IT-Getriebene oder sind das eher Unternehmen mit IT-Abteilungen,
die irgendwo außerhalb der Geschäftsprozesse irgendwelche IT-Wertströme betreiben?
Meiner Erfahrung nach lässt sich das nicht so klassifizieren.
Das findest du in allen Größen, tatsächlich auch in Organisationen, die sehr abhängig sind von der IT
und wo die Werte tatsächlich durch IT generiert werden.
Also das ist tatsächlich, durch die Bank findet man es.
Durch die Bank gibt es natürlich auch…
Ausnahmen.
Welche Zusammenarbeitsstrukturen funktionieren denn aus deiner Erfahrung heraus am besten,
wenn man versucht, das Thema DevOps-Zusammenarbeit möglichst frühes Einbinden
oder möglichst frühes Einbinden der betriebsverantwortlichen Teams
in die Projekt- oder Produktentwicklungsstrukturen zu ermöglichen?
Also wie funktioniert es am besten?
Meiner Erfahrung nach funktioniert es am besten, wenn gerade im Rahmen von Projekten,
vielleicht auch von größeren Projekten, dedizierte Teams geschaffen werden.
Denn der Betrieb ist ja auch im Bereich der Infrastruktur typischerweise so geschnitten,
dass er die alltäglich anfallenden Arbeiten sehr gut und kosteneffizient umsetzen kann.
Zusätzliche Arbeit ist schwierig.
Insbesondere, wenn es dann…
Wenn es dann…
Wenn es dann…
Innovationscharakter hat.
Das ist schwierig in der Bestandsorganisation des Infrastrukturbetriebs
oder überhaupt des Betriebs umzusetzen.
Und am erfolgreichsten ist meiner Meinung nach, wenn das über dedizierte Personen,
die dann tatsächlich auch die Zeit haben, sich um diese Themen zu kümmern
und die dann früh in das Gesamtprojekt mit einzubeziehen
und dort dann tatsächlich cross-funktional mitzuarbeiten.
Also dediziert klingt für mich immer so.
Dediziertes Netzwerkteam, dediziertes Security-Team,
das halt an einer Komponente im IT-Wertstrom dediziert arbeitet.
Du hast aber gerade auch cross-funktional gesagt.
Also ein cross-funktionales Team ist ja genau das Gegenteil von dem, was ich gerade zuerst gedacht habe.
Wenn wir von dediziert reden, ist das der Ansatz, Teams so zu schneiden,
dass sie einen Produktfokus haben mit dedizierten Teams,
mit Mitgliedern für bestimmte Aufgabenbereiche,
zum Beispiel Applikationsbetrieb hast du genannt,
zum Beispiel Infrastrukturbetrieb hast du genannt,
aber genauso auch Entwicklung oder wie sieht es mit dem Drummaster aus?
Vielleicht auch sowas, ne?
Gut, dass du es ansprichst.
Ich wollte so verstanden werden, dass die Personen dediziert diesem Projekt zugeordnet sind.
Keine zusätzlichen dedizierten Silos, bitte nicht.
Weniger davon, sondern natürlich mehr cross-funktionalität,
um dann dort auch bis runter,
in die Infrastruktur eine Sicht zu schaffen,
wo eigentlich das übergeordnete Ziel ist, um was geht es eigentlich?
Was ist eigentlich der Vorteil für den Fachbereich, für das Business, für den Kunden und wo sind die Herausforderungen?
Also sowas wie ein produktfokussiertes Team, das eine Ende-zu-Ende-Verantwortung hat,
sowohl mit Betriebsaufgaben als auch mit Entwicklungsaufgaben.
Genau.
Oft ist es ja so, dass sich im Rahmen solcher Projekte heraus,
dass wir eine Plattform brauchen,
dass dann sozusagen die Entwicklung oder auch der Anwendungsbetrieb sich an so einer Plattform bedient.
Und solche Dinge, dass wir natürlich wollen, dass ein Entwickler kurzfristig ad hoc eine Testumgebung bekommt,
sind natürlich so aus dem Standardbetrieb heraus sehr schlecht umsetzbar.
Und die Idee, ja auch wir in der Infrastruktur haben Kunden und reden direkt mit dem Kunden und fragen,
was er braucht, um das dann optimal umzusetzen, das ist natürlich äußerst hilfreich.
Plattform ist auch ein ganz interessantes Thema, interessanter Begriff.
Wie verstehst du denn Plattform?
Plattform in dem Kontext verstehe ich so, dass es eine Infrastrukturplattform gibt,
die eben die Anforderungen aus der Entwicklung und dem Anwendungsbetrieb optimal erfüllt.
Und manchmal ist es eine Plattform, die automatisiert virtuelle Maschinen zur Verfügung stellt.
Wir kennen alle das Thema Kubernetes und die ganzen Distributionen,
die auch so eine Plattform zur Verfügung stellen können.
Genau, aber die Ausprägung so einer Plattform hängt natürlich am konkreten Projekt.
Ist also auch unabhängig vom Hosting, ob es jetzt On-Premise gehostet ist
oder durch einen Public-Cloud-Anbieter zur Verfügung gestellt wird.
Das macht für dich keinen Unterschied?
Nein, das macht, also es macht in der Beschaffung natürlich auch, es macht schon Unterschiede.
Gerade der Beschaffungsprozess ist beim Public-Cloud-Anbieter,
der nochmal ganz anders skaliert, natürlich anders.
Sicherlich auch besser, dort haben wir dann mehr Herausforderungen in der Verrechnung.
Aber prinzipiell macht es keinen Unterschied.
Am Ende muss ich Anforderungen optimal erfüllen.
Und das ist natürlich ein Architekturthema, das tun lässt,
möglichst gut zu arbeiten.
Wenn es nicht früh adressiert wird und wenn es Architekten gibt und dann Architekten bohrt,
dann müssen die natürlich auch mit einbezogen werden.
Das löst so ein bisschen das Problem, dass Infrastrukturbetrieb ab und zu als Bremsschuh wahrgenommen wird.
Kann man das so sagen, dass man da eine Lösung hat,
indem man zum Beispiel Cloud-Anbieter an solcher Stelle mit einbindet?
Ja, Cloud-Anbieter mit einbeziehen kann natürlich eine Lösung sein.
Allerdings jetzt nur Ressourcen in den Cloud zu beziehen,
meiner Meinung nach ist das ein sehr teures Hosting 2.0.
Ich muss natürlich auch Betriebsmodelle anpassen.
Ohne Automatisierung wird es sicherlich nicht sehr viel mehr Spaß machen,
als wenn ich lokale Ressourcen zur Verfügung stelle.
Wie sieht es im Infrastrukturbetrieb dann aus?
Hat solche Anbieter, Technologie, Cloud und ähnliches auch einen Einfluss,
auf das Mindset, auf die Kultur in solchen, ich nenne es erstmal Abteilungen?
Ja, über kurz oder lang hat es natürlich Einfluss.
Zumindest wenn es erfolgreich sein soll, meiner Meinung nach.
Das ist ähnlich wie eine Containerplattform.
Die agiert oft als so ein Kristallationspunkt.
Es wirkt oft als Katalysator, um dann eben Arbeit zu verändern,
die Zusammenarbeit zu verändern.
Es wird sehr schnell klar, dass mit alten Betriebsmodellen
und der alten Art der Zusammenarbeit eben die Mehrwerte,
die man sich erhofft, gar nicht zu heben sind.
Insofern hat es natürlich Einfluss.
Das heißt, es verändert durch andere Beschaffungsprozesse
auch die Unternehmenskommunikation, die Kultur, das Verständnis der Arbeit.
Also an sich etwas, wo man nicht auf eine neue Generation an Mitarbeitern hat,
die andere vielleicht weniger historisch bedingte Einflüsse mitbringen,
sondern kann das auch in einem laufenden Unternehmen
mit bestehenden Mitarbeitern forcieren.
Gibt es außer Beschaffungsprozesse auch andere Mittel,
die eine Kultur beeinflussen?
Das ist witzig, dass du es ansprichst, Falco.
Mir wurde das tatsächlich so eins zu eins gesagt.
Ja, Herr Lange, das ist ja alles gut und schön,
was Sie uns hier vorschlagen.
Unsere Mannschaft geht das nicht.
Da müssen wir warten auf eine andere Generation.
Das ist natürlich schon auch ein Stück weit eine Bankrotterklärung,
meiner Meinung nach.
Kultur, ja, ein wichtiges Thema in DevOps.
Es gibt ja keine Nicht-Kultur.
Ich habe noch nie eine Organisation erlebt, in der es keine Kultur gibt.
Irgendeine gibt es immer und die ist ja irgendwie gewachsen.
Ich halte es für sehr wichtig,
dieses große, total schwammige Thema Kultur mal,
zu konkretisieren und ich bin Fan davon,
es auch erst mal stark zu reduzieren und zu sagen,
okay, lasst uns mal dafür sorgen,
dass wir eine gemeinsame Sprache entwickeln,
dass wir gemeinsame Regeln haben
und dass wir uns um die Arbeitsbeziehung kümmern.
Daraus lässt sich dann tatsächlich auch Kultur schaffen.
Also ich weiß nicht, wie es euch geht.
Ich hatte schon sehr oft das Erlebnis, dass ich,
gerade am Anfang, der Kunde meinte, ja, wir machen einen Workshop
mit den Entwicklern und einen Tag später machen wir einen mit dem Betrieb.
Und dann kommt man mit so wirren Ideen wie, nee, wir machen das gemeinsam,
wir setzen die an einen Tisch und im Nachgang ist dann das Feedback,
wow, dass wir mal miteinander reden konnten
und wir uns gegenseitig erklärt haben, was wir eigentlich meinen.
Das war so hilfreich.
Also gerade die Sprache.
Also meine Freunde, die nicht in der IT sind, die glauben ja, IT ist eins, so.
Und ja, vielleicht ist es ein eigener Planet,
aber auf dem gibt es doch sehr unterschiedliche Kontinente mit unterschiedlichen Sprachen.
Ja, also das zusammenzubekommen, dann tatsächlich die gemeinsamen Regeln,
der Fokus auf das übergeordnete Ziel, das sind Dinge, ja, die sind einfach so wirksam,
das ist…
…gar nicht stärker betonen kann.
Also für dich sind Sprache, Regeln und sind es Prozesse als drittes,
Zusammenarbeit, Arbeitsweisen, die Kernelemente, die eine Kultur ausmachen?
Zumindest ist es ein ausgezeichneter Anfang, das Thema Kultur konkret anzugehen,
konkret zu schauen, wo haben wir denn eine gemeinsame Sprache,
wo haben wir keine gemeinsame Sprache.
Das ist übrigens auch etwas, wo gerade am Anfang, wenn wir über Architektur reden,
die Architekten sicherlich einen guten Beitrag leisten können,
denn die Architektur, gerade mit ihrem übergeordneten und ganzheitlichen Blick im Idealfall,
natürlich für diese gemeinsame Sprache mitsorgen kann.
Wie stelle ich mir das am ehesten vor?
Der eine sagt Server, der andere sagt Server, ist die gleiche Sprache,
aber der eine redet trotzdem von was ganz anderem?
Ja, das ist doch genau schon so ein Punkt, oder?
Der eine denkt, wenn man Server redet, denkt er an Apache und der andere denkt an Blech im Keller.
Na klar. Also ein einfaches Beispiel, was ich immer wieder erlebe,
wenn der Entwickler von einem Deployment spricht, dann meint dann Maven einen Punkt
und jemand aus dem Betrieb sagt, Moment mal, wenn Software irgendwo auf der Platte liegt,
dann ist es nicht deployed.
Software muss sich im Kreis rumdrehen und Strom verbrauchen, dann ist es deployed.
Und der Fachbereich sagt.
Deployed ist das, wenn tatsächlich jemand darauf zugreifen kann und einen Mehrwert hat.
Wie kriegt man diese drei Sichten für ein Deployment übereinander?
Ja, indem man es einfach anspricht, zusammenbekommt und dann halt auch in der großen Runde mal fragt,
was ist denn das Ergebnis von einem Deployment-Entwickler?
Und dann erklärt er das und dann landen sich andere halt an die Stirn und sagen,
ja, Moment mal, und darüber findet man dann eine gemeinsame Sprache
oder zumindest eine gemeinsame Sprache.
Das ist zumindest ein Verständnis dafür, dass der gleiche Begriff woanders was anderes bedeutet.
Im Idealfall kann man ja daraus dann auch ein Glossar bauen, damit das für alle nachvollziehbar ist.
Ja, schönes Werkzeug auf jeden Fall für solche Zwecke.
Aber wenn das so einfach und so wirkungsvoll ist, wird das dann nicht eigentlich überall gemacht?
Den Eindruck habe ich nicht, dass es überall gemacht wird.
Ich glaube, es ist zumindest dort, wo ich gebeten werde, mitzuarbeiten,
gibt es natürlich schon Hindernisse.
Und eines der größten Hindernisse, die ich sehe, sind vor allen Dingen diese hohen Betriebsaufwände,
unter denen die Betriebsmannschaften stöhnen und die ihnen oft auch gar nicht die Zeit geben,
Dinge, Arbeit grundsätzlich zu verbessern.
Das ist tatsächlich einer der großen Punkte.
Und an der Stelle vielleicht auch mal ein Buchtipp.
The other side of innovation, solving the execution challenge,
von Govindarajan und Trimble, finde ich an der Stelle sehr lesenswert.
Die erklären, warum aus einer Bestandsorganisation heraus solche Dinge,
die reden tatsächlich von größeren Innovationen,
aber ich halte auch so DevOps-Projekte für ausreichend innovativen Charakter
und das aus der Bestandsorganisation nur schlecht heraus umsetzbar ist.
Ja, das ist auch interessant.
Da muss ich nochmal.
Als an diese Folge denken, die wir gemacht haben mit diesem Google SAE.
Der hat gesagt, wenn Sie mehr als 50% manuelle Arbeit haben im Wochenmittel,
dann befinden Sie sich per Definition im Notfallbetrieb.
Wow.
Er sagt, mindestens 50% seiner Aufwände sollen in tatsächliche Weiterentwicklung gehen,
in Autorobation, in Innovation und so weiter und so weiter.
Wenn er diese 50% nicht mehr halten kann, dann per Definition sind Sie im Notfallbetrieb.
Und dann greifen andere Regeln.
Dann werden zum Beispiel Lasten anders verteilt und sowas.
Das finde ich einen spannenden Ansatz.
Und ja, es ist bestimmt hilfreich.
Schön, dass Google dort eine Lösung gefunden hat.
Ob das so eins zu eins umsetzbar ist auf den klassischen Mittelständler, weiß ich nicht.
Google hat halt auch viel Geld, um es gegen so ein Problem zu schmeißen.
Genau, tatsächlich viel Geld.
Und sicherlich auch viel Personal, die da in der Lage ist, das anzugehen.
Aber diese 50% als Zielmarke, das ist, finde ich, sehr spannend und lohnenswert, sich anzuschauen.
Und selbst wenn es dann nur 30% sind, wäre ja sicherlich auch schon ein Schritt in die richtige Richtung.
Ja, irgendwo muss man anfangen.
Bis jetzt bei 50% hat, weiß man ja nicht, ob es dabei auch bleibt.
Aber es ist zumindest ein gutes Maß, um zumindest solche Themen wie Regeln, was du ja auch vorhin angesprochen hast,
dass für dich zur Kultur auch Regeln gehören, mal sichtbar zu machen, auch Transparenz zu schaffen.
Und dann zu sagen, okay, wir haben gerade offiziell mehr als 50% manueller Aufwand.
Folge, wir haben Notfallsituationen.
Folge, wir gehen anders mit unserer Arbeitszeit um.
Das ist natürlich eine interessante Regel.
Gibt es dann andere Regeln, die euch gerade einfallen, die Unternehmen in dem Umfeld definieren?
Ich meine, so klassisch, recht weit verbreitet ist ein Thema wie, wir arbeiten nach agilen Frameworks als Zusammenarbeitsmodell.
Wäre eine Form von Regel.
Eine andere habt ihr schon genannt.
Fällt euch noch was ein?
Also mir fällt vor allen Dingen ein, die Veränderung von bestehenden Regeln.
Typischerweise also solche Dinge wie Verantwortung und wer wofür verantwortlich ist.
Das verändert sich im Rahmen so eines DevOps-Prozesses einer Reise natürlich auch.
Und da muss natürlich drauf geschaut werden.
Wenn ich Möglichkeiten schaffe.
Ad hoc, vielleicht sogar als Self-Service, Ressourcen zu requestieren.
Wer ist denn eigentlich noch verantwortlich für das Ressourcenmanagement?
Kann ich das denn immer noch in der Infrastruktur verorten?
Haben die denn noch die Möglichkeiten?
Das ist, finde ich, einer der wichtigen Punkte.
Denn natürlich ernte ich Widerstand.
Wenn ich Verantwortung jemanden gebe, der sie letztendlich gar keine Möglichkeit hat,
hier die Verantwortung zu übernehmen.
Ja, das ist ein wichtiger Punkt, auf den ich auch zum Beispiel in Trainingsgesprächen immer wieder stoße.
Dass den Leuten Verantwortung aufgebürdet wird, ohne dass man ihnen die entsprechenden,
so wie du sagst, Möglichkeiten gibt, um dieser Verantwortung gerecht zu werden.
Entweder indem man sie fachlich befähigt oder indem man ihnen die Zeit einräumt
oder indem man ihnen die notwendige Autonomie gewährt, dieser Verantwortung gerecht zu werden.
Und wir wissen ja auch, Autonomie hat verschiedene Komponenten.
Hat eine, ich sag mal, kulturelle Komponente.
Darf ich was selber entscheiden?
Hat aber auch zum Beispiel vielleicht Architekturaspekte.
Kann ich überhaupt meinen Service so schneiden, wie ich das möchte?
Oder bin ich völlig eingeengt in bestehende architekturelle,
bestehende Vorschriften oder einfach nur faktische Gegebenheiten?
Genau, und das lässt sich, glaube ich, auch nicht für alle Organisationen über einen Kamm scheren.
Da muss man auch schauen, was gibt es für regulatorische Anforderungen etc.
Aber ich denke, der wichtige Punkt ist, wenn ich denn ein cross-funktionales Team habe,
dann muss ich mit dem Team gemeinsam diese Regeln sozusagen reviewen
und da, wo nötig, neu definieren.
Übrigens.
Übrigens.
Wenn ich da ganz kurz ein bisschen das Thema wechseln darf,
da gibt es etwas, was mich schon seit langem umtreibt
und ich bin wahnsinnig gespannt, ob du da eine gute Antwort für mich hast,
weil ich habe leider irgendwie nicht so richtig eine,
nämlich dieses ganze Thema von cross-funktionalen Teams.
Weil wir streben ja an, dass Teams auch ein langfristiges Gebilde sind,
dass da immer dieselben Leute zusammenarbeiten,
dass sich da Vertrauen einstellen kann,
dass sich da gemeinsame Arbeits- und Sichtweisen einschleifen usw.
Andererseits habe ich aber doch bestimmt über die Zeit
auch sich wandelnde Anforderungen an dieses Team.
Wenn ich jetzt mal sage,
ich fange jetzt auf der grünen Wiese mit einem neuen Service an,
da brauche ich in dem Sinne erstmal noch keinen Betrieb,
weil es gibt ja noch nichts zu betreiben.
Ja.
Und später kehrt es sich dann vielleicht um,
da brauche ich dann quasi keine Entwicklung mehr.
Da muss halt irgendwie einer noch so ein bisschen ab und zu mal ein paar Bugs fixen,
aber im Wesentlichen ist das Ding ausentwickelt
und es ist nur noch reiner Betrieb.
Wie geht das zusammen mit dem Wunsch nach stabilen Teams
mit einer mehr oder weniger konstanten Zusammensetzung?
Naja, eine der Möglichkeiten ist,
dass wir,
diese Liaison schaffen,
dass jemand eben nicht mehr in einem Team primär Mitglied ist,
sondern etwas, ich sage mal, etwas loser dem Team zugeordnet ist,
die Kompetenzen noch mit einbringt
und dann, wenn es noch notwendig ist, mitarbeitet.
Das wäre so das, was mir ad hoc einfällt,
weil natürlich verändert sich der Schwerpunkt eines IT-Produkts
im Laufe der Zeit.
Ich habe dazu auch ein paar Gedanken.
Und zwar, so ein IT-Produkt
entwickelt sich ja auch nicht von heute auf morgen.
Das heißt, es ist ja auch nicht wie so ein Projekt,
das vielleicht ein Jahr oder zwei geht, läuft,
sondern es sind ja teilweise sogar in die Jahrzehnte hinein.
Und da gibt es natürlich einerseits die Möglichkeit,
dass sich das Team von seinem Wissen her,
durch Schulung, durch Weiterbildung, durch Übungen,
tägliche Arbeit und Co. mit dem Produkt weiterentwickelt.
Und man hat natürlich auch solche Effekte wie Fluktuationen,
Mitarbeiter verlassen das Unternehmen,
neue kommen hinzu,
gegebenenfalls auch ältere Mitarbeiter gehen in Rente,
verlassen das Unternehmen dauerhaft und Ähnliches,
dass man diese, ich sage jetzt mal,
mehr oder weniger naturgegebenen Veränderungsprozesse
an der Stelle mitnutzt.
Einerseits durch Schulung, Weiterbildung,
andererseits durch Fluktuation
und dann natürlich auch solche Effekte dann zu sagen,
okay, man schaut vielleicht auch mal,
wie die Teams, die man im Unternehmen hat, zusammenarbeiten,
macht vielleicht sowas wie eine Analyse in Richtung Team-Topologien,
schaut vielleicht auch, ob man bewusst solche Zusammenarbeitsmodelle
zwischen Teams entsprechend anpasst, um bestimmte Ziele,
denkt da so ein bisschen an Architekturziele vielleicht auch,
abzubilden und eine Cross-Funktionalität herzustellen,
dass man vielleicht ein klassisches Entwicklungsteam,
ein klassisches Betriebsteam, die dann recht groß sind,
zusammenbringt und vielleicht anders schneidet,
dass dann daraus sowas wie ein Plattformen-
und ein Business- oder produktfokussiertes,
endkundenfokussiertes Team wird,
interne Kunden, externe Kundenschichten
und das lässt sich auch in überschaubaren Zeiträumen gut anpassen
und so funktioniert aus meiner Sicht das Thema Cross-Funktionale Teams
auch mit der Veränderung der Anforderungen
über einen Produktlebenszyklus hinweg.
Also wenn ich es richtig verstehe, dann sagst du einfach,
die Veränderungen sind so langsam,
dass ich einerseits den Charakter meine,
eines Teams ändern kann, aber gleichzeitig der Forderung
nach Stabilität weiterhin nachkommen kann,
weil die Änderung einfach langsam genug ist.
Wenn man das Produkt als jetzt längerfristig laufende Produkte sieht,
dann auf jeden Fall.
Wenn man jetzt natürlich ein kleines Unternehmen hat,
frisch gestartetes Startup mit einem Produkt,
das vielleicht regelmäßig, vielleicht auch einmal im Jahr
oder in kürzeren Abständen aufgrund von Kundenfeedback
einen Schwenk macht, klassischen Pivot,
dann ist es natürlich auch eine gute Situation,
dass man da andere Ansätze verfolgen muss,
dass man dann vielleicht auch wirklich sagt,
man löst das Team auf und baut neue auf,
entlässt gegebenenfalls sogar Mitarbeiter,
wenn das sinnvoll und hilfreich ist.
Da geht es natürlich dann so ein Stückchen
eher ans Eingemachte als bei Unternehmen,
die ein langlaufendes Produkt haben,
so ein Google mit einer Suchmaschine.
Ich glaube, die ist auch nicht letztes Jahr an den Start gegangen,
sondern halt auch schon so ein paar Jahrzehnte unterwegs.
Und auch bei solchen Produkten,
hat man ja regelmäßig Neuentwicklung,
wieder von vorne anfangen mit den Erfahrungen,
die man gemacht hat.
Und dann kann man natürlich an der Stelle
auch wieder mit einem neuen, frischen Team,
mit neuen Fähigkeiten wieder parallel entwickeln,
aufsetzen und dann das bestehende alte Produkt ablösen.
Weil viele Unternehmen gemacht,
nicht nur Google mit der Suche,
erst einen Monolithen bauen ist ein häufiger Ansatz,
danach dann halt was Service-orientiertes,
nächste Stufe,
wahrscheinlich was eher mit kleinen Services,
Microservice-Architekturen oder ähnliches einzusetzen,
ist ein häufiger Ansatz.
Und auch in diesen Rhythmen kann man natürlich entweder,
wie gesagt, bestehende Teams mit Weiterbildung fördern
und in die Richtung bringen
oder halt auch durch Neuzusammensetzung.
Ja, kann ich nur unterstreichen.
Aus meiner Erfahrung heraus gibt es natürlich immer wieder Punkte,
an denen man sich das Team anschauen muss.
Das Team und die Team-Zusammenstellung ist ja am Ende auch,
ich würde nicht sagen ein Tool,
aber hat schon diesen Charakter.
Und wenn ich merke, dass ein Team,
dass sich der Kontext geändert hat oder das Produkt
oder die Anforderungen geändert haben
und ich ein Team anpassen muss,
dann sollte ich es natürlich tun.
Und das ist ein ganz, ganz wichtiger Aspekt.
Und da kann man, glaube ich, nicht generell sagen,
mach es immer in diese Richtung.
Das ist tatsächlich kontextabhängig.
Genau, da kann man natürlich, wie du vorhin gesagt hast,
mit Teilzeit-Mitarbeitern, die vielleicht in dem Team
nur zeitweise mit unterstützen oder anderen Maßnahmen
genauso arbeiten wie halt die disruptiveren Themen,
wie komplette neue Teams aufsetzen.
Ja, und in der Hinsicht, glaube ich, ist auch tatsächlich
noch mal zu erwähnen die Gedanken,
die insbesondere zum Beispiel in diesem Buch
Team Topologies rauskamen.
Dass man eben eine Teamstruktur
und auch eine darunter liegende Architektur
nicht als etwas Statisches ansieht,
sondern als etwas, was sich ganz natürlich weiterentwickelt.
Und dass man dem einfach Rechnung trägt und einfach mal beobachtet,
welche Kommunikationsflüsse finden denn jetzt ganz real statt?
Welche Leute reden denn miteinander oder reden nicht miteinander?
Und ist das, was ich da wahrnehme, überhaupt das, was ich wünsche?
Das, was ich für erfolgversprechend halte?
Wie ist das denn dann eigentlich? Da bin ich neugierig.
Wenn jetzt zum Beispiel ein Peter in ein,
ich sag jetzt mal, klassisches Unternehmen geht,
die haben irgendwie eine eingespielte IT-Betriebsmannschaft
und jetzt kommt er irgendwie in die Geschäftsleistung
und sagt, hier, da ist der Peter und ihr bringt euch jetzt DevOps bei
und alles wird neu und besser. Läuft das so?
Ne, typischerweise läuft es nicht ganz so.
Das Thema alles wird neu und besser,
das muss man dann schon noch mal ein Stück tiefer legen.
Was natürlich enorm wichtig ist,
gerade wenn ich von ganz unterschiedlichen Menschen
in unterschiedlichen Bereichen,
wenn ich will, dass die zusammen etwas erreichen,
dann ist es meiner Meinung nach super, super wichtig,
dass ich den gemeinsamen Sinnstifter finde.
Also das ist dann vielleicht sogar der CIO
oder ein Abteilungsleiter, wo mehrere Teams drunter sind
und er auch eine klare Vision vermittelt.
Er klar sagt, warum brauchen wir das eigentlich?
Damit erstmal ein Bewusstsein da ist,
wozu soll denn diese Veränderung führen?
Und dann die Menschen mitzunehmen,
dass sie selber auch den Wunsch verspüren für diese Veränderung,
auch merken, was ist da für mich mit drin?
Und dann fangen wir an, Wissen zu vermitteln
und Dinge zu verändern.
Das ist der typische Weg.
Und tatsächlich einer der wichtigsten initialen Schritte,
initialen Punkte ist eben diese Vision
und das Buy-in vom gemeinsamen Sinnstifter.
Denn so eine Veränderung, so groß wie sie denn auch sein mag,
ist natürlich auch mit viel Unsicherheit behaftet.
Und dort hilft natürlich eine klare Vision.
Das ist meiner Meinung nach
einer der wirkmächtigsten Instrumente,
um so eine Veränderung ins Rollen zu bekommen.
Ja, zumal,
um da mal eine Lanze für altgediente Betriebler zu brechen,
es mir auch in DevOps-Trainings dann oft so gegangen ist,
dass die dann gesagt haben,
naja, das machen wir eigentlich schon lange so.
Oder wir haben es jedenfalls so gemacht,
bis sie es uns verboten haben.
Und jetzt dürfen wir endlich wieder so,
wie wir schon lange wollen und können.
Ja, auch so in der Zwischenzeit
sind Organisationsgrenzen dazwischengezogen worden.
Irgendwas ist outgesourced worden.
In, keine Ahnung, Osteuropa, Indien und Co.
sind ja da meist Kandidaten, wo man dann so was findet,
Betriebsteams oder Supportteams
oder gegebenenfalls sogar ganz andere Bereiche.
Selbst die Entwicklung wird da teilweise outgesourced
und dann halt in Tochterunternehmen
oder Unterauftragnehmer und ähnliches gepackt.
Da hat man natürlich dann einen höheren Aufwand,
das wieder zurückzurollen,
um wirklich cross-funktionales Miteinander hinzubekommen.
Ja, richtig.
Diese Fragmentierung ist natürlich ein großes Problem,
insbesondere, wenn da ja die Ziele oft sehr unterschiedlich sind.
Die Entwickler werden für Veränderungen bezahlt,
und die Betriebsmannschaft wird für Stabilität und Sicherheit bezahlt.
Das widerspricht sich natürlich.
Und dementsprechend muss ich natürlich agieren.
Das ist dann wieder das Thema gemeinsame Regeln.
Das, was du, Luca, ansprichst, erlebe ich verhältnismäßig häufig.
Also gerade die, die sich mit dem Mainframe, den Hosts beschäftigen,
die kommen ganz oft mit dem Thema und sagen,
ja, vor 40 Jahren hatten wir das schon mal.
Jetzt kommt ihr damit wieder ums Eck.
Verrückterweise sind das aber auch oft die,
die als die Dinosaurier gesehen werden
und die, die anscheinend in den Widerstand gehen.
Tatsächlich, wenn man jemandem mit denen arbeiten würde
oder ihnen wirklich zuhören würde, würde er feststellen,
dass die, was Automatisierung angeht, unglaublich weit sind.
Natürlich, die gesamte Dunkelverarbeitung passiert vollautomatisiert.
Also tatsächlich könnte man sich dort auch die Kompetenzen zunutze machen
und von ihnen lernen.
Also ich breche auch gern, wie ihr merkt,
gerne eine Lanze für den Betrieb und auch für die Infrastruktur.
Zumal sie viele Dinge auch verantworten.
Sie verantworten typischerweise auch so Themen wie Netzwerk und Security.
Und wir kennen das. Es gibt ein Problem.
Na ja, dann als erstes sagt man, das ist das Netzwerk.
Das ist einfach.
Das ist intransparent.
Man weiß nicht genau, was da passiert.
Also wird schon das Netzwerk sein.
Und das macht natürlich was mit den Teams.
Ich war selber am Anfang meiner IT Firewall-Administrator,
Content Scanner, solche Dinge.
Und nie ruft jemand an und sagt, hey, die Firewall funktioniert heute wieder ganz toll.
Und sie blockt auch alles ganz toll.
Vielen Dank für deine Arbeit.
Man wird nur angerufen, wenn etwas nicht funktioniert.
Und das macht natürlich was mit einem.
Man hat den Eindruck, da draußen funktioniert nie etwas.
Und ganz oft bin es ich und meine Firewall.
Und das ist eben auch ein Thema von gegenseitigem Verständnis.
Einfach mal in alle Köpfe reinzubekommen.
Die Firewall soll Dinge blocken.
Und wenn sie das tut, ist das genau richtig.
Einfach mal Danke sagen.
Zum einen Danke sagen und zum anderen frühzeitig Bescheid geben,
wenn man eine neue Anwendung hat.
Und neue Firewall-Regeln braucht.
Zumal ja diejenigen, denn auch diejenigen sind, die geprüft werden,
ob die Policies alle so passen, ob alles dokumentiert ist.
All das ist ja in diesem Umfeld, in dem wir eigentlich sehr schnelle Durchlaufzeiten haben wollen,
ein wichtiger Aspekt.
Wie kann ich das denn erreichen und trotzdem die regulatorischen Anforderungen noch umsetzen?
Und da hilft miteinander reden und gemeinsam Lösungen finden.
Ja, genau.
Zum Beispiel auch nicht den armen Betrieb dann erstens mal immer die Rolle des Kontrolleurs aufs Auge drücken
und auch die Rolle des irgendwie undankbaren Neinsagers.
Sondern das vielleicht einfach schon weiter nach links schieben und sagen,
das gehört in unsere Definition of Done mit rein.
Wenn wir Firewall-Regeländerungen brauchen,
dann müssen wir erstmal für uns geschaut haben, ob das Hand und Fuß hat.
Und vielleicht holen wir uns halt auch zum Beispiel einen Firewall-Menschen mit ins Boot,
dass der bei Zeiten schon mal drüber schaut und direkt sagt, oh Jungs, so wird das nichts.
Genau.
Entweder das, zeitweise vielleicht sogar jemanden mit dem Team mitlaufen lassen,
punktuell zu Workshops mit dazu holen.
Gegebenenfalls aber auch die Chance nutzen, in Richtung Automatisierung zu denken.
Und zwar zu überlegen, vielleicht ist das ja nicht nur einmalig,
sondern macht man halt regelmäßig.
Und dann entsprechend zu schauen, was kann man tun, damit man eben,
wenn, keine Ahnung, eine neue virtuelle Maschine ist,
die ins Netzwerk kommt, da nicht jedes Mal jemand aus dem Netzwerk
oder Security-Team hinzugezogen werden muss,
sondern dass man halt Regeln schafft,
sind wir wieder bei Regeln, schöner Hinweis,
Regeln schafft, die man auch als Grundlage für eine Automatisierung nutzen kann,
um eben das zu verkürzen.
Auch da dann sich wiederholende Tätigkeiten so weit weg zu automatisieren,
dass es entspannt und rund läuft.
Wie sagt man so schön?
Anders, was man mehr als zweimal tut, sind gute Kandidaten für Automatisierung.
Genau, automate everything you can.
Na klar, warum ist eigentlich die Anforderung für ein neues Objekt
in der Regelbasis nicht im Git mit drin?
Damit habe ich eine Versionskontrolle,
ich kann vielleicht auch den Prüfer zufriedenstellen damit.
Das ist aber auch ein heißes Eisen.
Also ich kenne auch so Situationen, da kommt dann jemand und sagt,
hey du Firewall-Administrator, ich will die Firewall automatisieren.
Damit erreicht man manchmal auch nur mit Mühe und Not die Ausgangstür.
Natürlich muss, wenn der Firewall-Administrator die Verantwortung hat,
dann muss er natürlich auch die Hoheit über die Regeln haben.
Aber wie du schon angesprochen hast,
vielleicht gibt es ja Regeln und ich muss nur Objekte hinzufügen.
Und das muss in der Zusammenarbeit mit den Firewall-Administratoren gelöst werden,
weil die haben letztendlich auch die,
auch die Verantwortung und sind auch rechenschaftspflichtig.
Tatsächlich ist meine Erfahrung, wenn man aufeinander zugeht,
wenn man miteinander redet, dann gibt es typischerweise Lösungen,
sodass wir dann nicht in einer Situation sind,
dass man ein Deployment von Wochen auf Minuten herunterbekommen hat
und dann braucht man halt nochmal eine Woche für eine Firewall-Regel.
Und bloß um das nochmal zu sagen, bloß weil jemand die Hoheit hat,
heißt das ja nicht, dass er erst am Schluss drauf schauen darf.
Oder bloß weil jemand die Verantwortung hat,
sondern wäre es nicht toll, wenn man ihn direkt von vornherein einladen würde,
so wie es der Falco vorhin schon gesagt hat,
dass wenn das Ding fertig ist, alle schon wissen, das wird auch funktionieren.
Genau so ist es.
Also ein anderes gutes Beispiel im Security-Kontext ist das Thema Betriebssystem-Hardening.
Wie schaffe ich eigentlich ein Hardening?
Und wie schaffe ich auch notwendige für Applikationen, notwendige Ausnahmen eines Hardenings zu automatisieren?
Und auch in Reports zu gießen, um den Prüfer zufriedenzustellen?
Auch das ist tatsächlich machbar und bedarf halt der Zusammenarbeit der unterschiedlichen Spezialisten.
Das sind doch einige DevSecOps-Themen, die wir jetzt gerade so am Wickel haben.
Finde ich gut, dass man das Thema auch bei uns im Podcast im Fokus mitbekommt,
weil es ist ja ein recht verbreiteter Punkt.
Den man an vielen Stellen wiederfindet, sei es im Scaled Agile Framework,
dass da Security auch einen höheren Wert bekommt und mit im Fokus steht
oder an vielen anderen Stellen genauso.
Wenn man das miteinander in der Zusammenarbeit mit unterbringen kann, umso besser.
Also für mich war das nie verstehbar, warum das Thema Security,
manche sagen ja DevSecOps und BuzzDevSecOps,
warum das extra betont werden muss.
Ich meine mal ganz ehrlich, heutzutage das Thema Security nicht mit zu fokussieren,
ist absolut sträflich.
Und egal wie eine IT-Produktion läuft, ob super klassisch oder mit DevOps-Methoden,
Security muss ein ganz starker Fokus sein und mit berücksichtigt werden,
voll umfänglich umgesetzt werden.
Das steht doch außer Frage.
Was ist an spannenden Dingen,
mit Peter zu reden gibt,
dass er sich großzügigerweise bereit erklärt hat,
mit uns noch einen zweiten Teil aufzunehmen.
Insofern betrachtet das mal als die erste Folge eines zweiteiligen Gesprächs mit Peter Lange.
Wir haben ja vorhin gesagt, alles was man öfter als zweimal macht, sollte man wegautomatisieren,
aber wir belassen es bei zweimal.
Insofern ist es glaube ich okay, wenn wir uns unterhalten.
Insofern Peter, bis hierhin ganz vielen Dank für die interessanten Sachen,
die du uns erzählt hast und über die wir gesprochen haben.
Und ich freue mich schon auf den zweiten Teil.
Genau. Bis dann. Ciao.
Na dann, bis zum nächsten Mal.
Auch von meiner Seite herzlichen Dank für die Einladung.
Hat mich gefreut.
Ich freue mich auch auf den nächsten Teil.
Tschüss.

Folge 62: Die Zukunft von DevOps

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Dierk, Falko und Luca diskutieren ihre Beobachtungen aus der Beratungs- und Trainingspraxis und versuchen daraus Erwartungen und Vorhersagen für die Zukunft von DevOps abzuleiten.

In dieser Episode des DevOps Podcasts werden verschiedene Aspekte von DevOps beleuchtet, einschließlich der Herausforderungen, die durch Stagnation in Transformationsprozessen, die Integration von KI und die Notwendigkeit der Anpassung an sich ändernde Technologien und Praktiken entstehen. Es wird diskutiert, wie DevOps immer vielfältiger wird und wie dieser Wandel sich auf Unternehmen auswirkt, mit einem besonderen Fokus auf Wertstromorientierung, Feedback-Schleifen und die Integration von Best Practices wie SRE (Site Reliability Engineering).

Inhalt

  • Definition und Bedeutung von DevOps
  • Der Einfluss von Team Topologies auf DevOps
  • Die Rolle und Bedeutung des State of DevOps Reports
  • Herausforderungen und Chancen in der Evolution von DevOps
  • Die Integration von Site Reliability Engineering in DevOps
  • Stagnation und Herausforderungen in DevOps-Transformationsprozessen
  • Die Zukunft von DevOps und die Rolle von KI und Remote Work
  • Agiles Arbeiten und Skalierungsframeworks in DevOps

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

DevOps – Auf die Ohren und ins Hirn
Ein Podcast rund um DevOps
Von Dierk Söllner, Falko Werner und Luca Ingianni
Hallo und herzlich willkommen zu einer neuen Folge des DevOps Podcasts
Auf die Ohren und ins Hirn, gestaltet und produziert von Luca Ingianni,
Dierk Söllner und Falko Werner. Wir sind DevOps-Trainer und Coaches
mit langjähriger Erfahrung. DevOps umfasst für uns kulturelle,
organisatorische und technische Aspekte. Mein Name ist Dirk Söllner,
ich begrüße alle Zuhörenden und natürlich auch Luca und Falko.
Hallo. Hi.
Wir freuen uns heute auf das Thema die Zukunft von Def Ops. Zu Gast haben wir
da wieder mal niemanden. Wir drei werden heute nochmals
Gedanken aus der Folge 55.
Fortsetzen. Da hatten wir ja schon mal ein bisschen dieses Thema gestreift,
ein bisschen andiskutiert. Werden wir heute nochmal fortsetzen, weil wir nämlich zu dieser Folge
55 einige Rückmeldungen erhalten haben.
Mittlerweile erleben wir drei das häufiger, dass wir in unseren Schulungen zu Def Ops
auf diesen Podcast angesprochen werden, respektive, dass wir in unseren Schulungen
auf den Podcast verweisen können. Und da haben wir, wie gesagt, einige Rückmeldungen
erhalten, dass die Zukunft von Def Ops ja nochmal ein bisschen vertieft werden könnte.
Das tun wir heute gerne. Und wir wollen ganz kurz zu Beginn das machen, was wir mit unseren Gästen
immer machen. Denn wir fragen unsere Gäste ja immer zu Beginn nach ihren Sichten auf Def Ops, nach ihrer
persönlichen Definition. Also wie definiert unsere, wir definieren unsere Gäste Def Ops.
Und ich würde da oder nicht, ich würde, ich tue eins.
Ich verweise immer gerne auf die Definition von Tobias Weinmann aus der Folge 7, also ist schon ein
bisschen her.
Ich würde sagen, dass ich meine Gäste Def Ops damals als nachhaltige Geschwindigkeit unter
Berücksichtigung der drei Wege von Jim Kim definiert.
Natürlich gibt es verschiedene Ausprägungen und die haben sich auch aktualisiert.
Aber für mich ist der Text nach wie vor der Aufbau hoch performanter IT-Organisation, dass wir
müssen in der IT aus meiner Sicht schneller und hochwertiger werden und schneller allein
reicht nicht, wenn wir eben keine Qualität liefern und hochwertig allein reicht nicht, wenn
wir immer nur zu spät liefern oder Teile zu spät liefern.
Das heißt.
Aus meiner Sicht liefert Def Ops viel hilfreiche Ansätze, um beides zu verbinden, also sicherzustellen,
dass wir schneller und hochwertiger liefern.
Luca, was ist deine Definition?
Oh Mann, nicht schon wieder.
Ich war doch schon erst in der vergangenen Folge über BDD dran.
Insofern auch im Interesse der Kürze.
Liebe Hörer, wenn euch meine Definition interessiert, dann hört euch doch einfach die Folge über BDD an.
Die ist ohnehin hörenswert.
Da ist auch eine Definition drin.
So cool.
So kann man auch auf die eigenen.
Alte Folgen hinweisen, wobei so alt ist die ja noch nicht.
Nee, die kam ja raus zum Zeitpunkt der Aufnahme am vergangenen Wochenende.
Ja, perfekt.
Falko.
Ja, wir haben ja alle schon unsere Definitionen in dem Podcast an verschiedenen Stellen breitgetreten.
Aber eine, die noch nicht vorgeschlagen worden ist, ist eine, die Luca und ich uns zusammen für die Def Ops Days in Magdeburg dieses Jahr überlegt haben.
Und zwar in dem Fall auf Englisch.
At its core, Def Ops is empowering organizations to drive value for all stakeholders.
Mit einem Hinweis, dass zu all stakeholders jeder betroffen ist.
Das heißt, der Entwickler, das Unternehmen, die Unternehmenseigner, die Kunden.
Und insofern ist das für mich eigentlich ein Weiterdenken des Agilitätsbegriffs.
Ob man das nur in einem skalierten Umfeld macht.
Ob man das nur in einem Enterprise-Umfeld wirklich mit vielen, vielen Teams macht.
In einem kleinen Team eine App, eine kleine Web-Anwendung oder ähnliches.
Wenn man dabei den Kundenfokus im Blick behält.
Das heißt, schnell Kundenanforderungen nach den Vorstellungen des Kunden, also mit hoher Qualität, auch liefern zu können.
Dazu hilft Automatisierung.
Dazu hilft Verschiedenes, zum Beispiel Wertstromanalyse.
Value-Stream-Mapping und andere Dinge.
Und insofern würde ich zurück an Dirk geben und hoffen, dass das eine gute Beschreibung ist.
Ja, das sollen andere entscheiden, ob das gut war.
Auch das ist ja ein Punkt, dass Def Ops ja auch sehr vielfältig ist.
Und insofern gibt es auch vielfältige Sichten darauf.
Gut, dann lasst uns mal inhaltlich starten oder weitermachen.
Und wenn wir über die Zukunft von Def Ops reden, dann ist es ja hilfreich,
auch mal ganz kurz ein bisschen in die Vergangenheit zu gucken und vielleicht auch sich andere Quellen zunutze zu machen,
die auch über State of Def Ops reden.
Also insofern State of Def Ops Report ist ja etwas, was wir auch in unseren Schulungen häufiger nutzen,
was immer einen ganz guten Blick auf den jeweiligen Status von Def Ops bringt.
State of Def Ops Report kommt einmal im Jahr raus, ist von Gene Kim ursprünglich mal sozusagen aufgebaut worden.
Mittlerweile.
Das heißt, es ist eine feststehende Institution.
Und wenn man da mal zurückschaut, 2016 haben sie auf Punkte geschaut, wie Versionsverwaltung ist, die vorhanden ist,
Monitoring im Einsatz, wie sieht es beim Teamwork aus?
Also haben da zum Beispiel solche Erkenntnisse gewonnen.
Sie haben 2017 so ein bisschen geschaut, wo können wir hochperformante und nicht zu hoch performante IT-Organisationen vergleichen.
2018, 2019 ging es weiter.
2020 haben sie Plattformen so ein bisschen rausgehoben.
Und 2022, das wäre der aktuelle, der ist gerade am Laufen.
Das heißt, den aktuellen State of Def Ops Report gibt es eben noch nicht.
Die Umfrage, die Ausweitung läuft gerade, sodass wir uns auf den State of Def Ops Report 2021 kurz stürzen.
Also wie gesagt, wir machen das kurz, weil wir ja in die Zukunft gucken wollen.
Aber wie gesagt, ich denke, dass man auch mit Blick in die Vergangenheit ein bisschen was in Zukunft erzählen kann.
Und wenn man sich das State of Def Ops Report 2021 anschaut,
ist es so, dass nach wie vor noch viele Unternehmen gegen kulturelle Blockaden kämpfen.
Also Aussagen, die wir auch immer wieder hören, das haben wir schon immer so gemacht oder warum sollen wir etwas ändern?
Läuft doch. Also solche Punkte sind aus unserer Sicht, aus meiner Sicht, Indikator für kulturelle Blockaden.
Und wenn man sich den Report anschaut, zeigt er, dass man einfach, dass es dort hilfreich ist, eine Top-Down-Unterstützung, der Bottom-Up-Transformation zu haben.
Also im Prinzip das.
Um abzusichern, was Def Ops bedeutet, also eine Veränderung.
Und da reicht es nicht aus, Top-Down vorzugehen, sondern ein Punkt, den ich für wichtig empfinde, hilfreich ist es, Top-Down-Unterstützung bei einer Bottom-Up-Transformation.
Und wenn man das in die Zukunft jetzt mal transformiert, glaube ich, muss dann noch sehr viel mehr Wissen, sage ich mal, auch in die Top-Ebenen gebracht werden.
Also Top, wenn ich Top-Down vorgehe, muss ich auch Wissen in die Top-Ebenen bringen.
Und ich muss viel mehr Bottom-Up unterstützen, indem ich ausbilde, indem ich einfach auch dort Experimente unterstütze, indem ich das absichere oder unterstütze, dass es von unten nach oben kommt.
Luca, Falko, passt das für euch so?
Ja, ich denke, dass es sinnvoll ist, bei Transformationen zumindest an Stellen anzufangen, wo es Freiwillige gibt, die Interesse haben, die ein Verständnis dafür haben, um dann im Unternehmen aus den Erfahrungen profitieren zu können.
Das sind Ansätze, die wir mit verschiedenen Kunden auch so in der Form umsetzen.
Und ab einem bestimmten Zeitpunkt, wenn es über Teamgrenzen oder Bereichsgrenzen hinausgeht, kommt man ohne Top-Down-Unterstützung nicht voran.
Und an der Stelle kommt man entweder auf eine Blockade und bleibt irgendwo stecken.
Oder man kriegt dann Top-Down-Unterstützung.
Oder, wenn man es schafft, schon vorher Management-Unterstützung.
Von den Entscheidern, von der Geschäftsführung und anderen Top-Down-Unterstützern zu bekommen und sie frühzeitig ins Boot zu holen, hat man noch ein paar andere Vorteile.
Deswegen ist es sinnvoll, das beides zu kombinieren und immer auch den Support, die Unterstützung aus den Entscheidungsebenen im Unternehmen mit einzubinden.
Zweiter Punkt, der in dem State-of-Dev-Obs-Report angesprochen wird, ist das Thema Teamverständnis und klare Regelungen sind hilfreich.
Und insbesondere wird im Dev-Obs-Report darauf abgehoben, dass der Ansatz von Team-Topologies dort sehr viel bewirkt hat und sehr hilfreich ist.
Da können wir, wenn wir jetzt wieder hier unsere eigenen Folgen bewerben, auf die Folgen 42, 43 und 46 verweisen.
Das heißt, wir haben im letzten Jahr schon Team-Topologies auch hier im Podcast bearbeitet.
Und das ist einfach wichtig. Und auch das ist wieder, wenn man in die Zukunft guckt, wichtig.
Dass so ein Teamverständnis ausgeprägt wird, dass klare Regelungen ausgeprägt werden.
Das heißt, es reicht einfach nicht aus, sozusagen wir machen Dev-Obs, sondern dass man wirklich dort Regelungen schafft,
die dafür, die sicherstellen, dass Dev-Obs zum Beispiel zusammenarbeiten in der einfachsten Form.
Wir haben nachher noch ein paar andere Themen, weil Dev-Obs ist ja viel vielfältiger,
aber wirklich klare Regelungen und klare organisatorische Regelungen sind enorm hilfreich und enorm wichtig.
Luca?
Team-Topologies ist doch dein Steckenpferd, oder?
Ja, das ist mein Steckenpferd. Und ich möchte da auch auf eine Sache hinweisen, die sehr wichtig ist,
einerseits für Team-Topologien, aber auch ganz allgemein für Dev-Obs.
Nämlich, wenn man Team-Topologies liest, dann weisen sie auch darauf hin, dass es vollkommen gewöhnlich und erwartbar ist,
dass sich Team-Strukturen und damit einhergehend natürlich auch Produktarchitekturen wandeln im Laufe der Zeit.
Die sind einer stetigen Veränderung unterworfen. Das ist vollkommen normal.
Und das ist eine ganz gute Neuigkeit, finde ich, weil man ist nicht gezwungen, es aufs erste Mal richtig zu machen,
sondern man macht halt mal einen Versuch und man wird natürlich Schwächen feststellen bei dem,
was man sich da so zusammengereimt hat. Ja gut, dann geht man halt her und macht es besser.
Also ein iterativer, agiler, wertgetriebener Ansatz ist nicht nur auf der Produktebene hilfreich und sinnvoll,
sondern natürlich auch auf der Organisationsebene.
Und das ist mir, glaube ich, ganz wichtig, darauf hinzuweisen. Ich glaube, dass das Bewusstsein dafür auch wächst,
dass das ist das, was ich auch im Dialog immer wieder mal erlebe mit den Kunden,
dass so eine DevOps-Einführung ist halt nicht irgendwie, du gehst her und stülpst der Organisation was Neues über
und dann bist du irgendwie fertig und reitest in den Sonnenuntergang,
sondern das ist der Startschuss für eine neue Art des Zusammenwirkens, des Zusammenarbeitens,
in der Wandel eine Konstante ist in einem gewissen Sinne.
Und das völlig positiv gemeint. Wir lernen ständig mit und nutzen das, was wir lernen.
Ja, wenn man das dann wieder in die Zukunft projiziert, wir reden über die Zukunft von DevOps,
ist eigentlich der Punkt.
Dass das quasi die Zukunft ist. Also fortwährend lernen, fortwährend Erfahrungen machen,
fortwährend Organisationen anpassen und so weiter.
Ja, auch vielleicht wegzukommen von den sehr großen Schwungweisen,
einmal alle zwei, drei, vier Jahre stattfindenden Change-Prozesse,
hin zu einem kleinen, in kontinuierlichen Ansatz ablaufenden Veränderungsprozess.
Damit man einerseits nicht die Überlastung hat, was natürlich bei Team Topologies auch so,
ein Thema ist, kognitive Last zu reduzieren.
Nicht nochmal zusätzliche Last durch Veränderungsprozesse, große Change, Reorganisationen
und andere Vorgehensweisen zu produzieren, sondern halt an den Stellen zu optimieren
und das immer wieder zu tun, zum Beispiel durch Retrospektiven oder Inspect and Adapt Workshops
oder ähnliche Vorgehensweisen, um eben nicht die Notwendigkeit auch zu haben
für solche großen Umstellungen, Umstrukturierungen.
Ja, in kleinen Schritten vorwärts gehen, ne?
Ja, okay.
Dann lasst uns noch den dritten Punkt kurz rausnehmen aus dem Set of DevOps Report,
den ich quasi so ausgelesen habe.
Ich habe den mal zusammengefasst oder übersetzt mit dem Thema
Automation und Cloud sind allein nicht DevOps.
Ja, natürlich kann ich Dinge automatisieren, dann kann ich auch sagen,
ich mache DevOps, aber das allein reicht.
Das heißt, der State of DevOps Report hat quasi rausgefunden,
dass hochentwickelte Unternehmen im DevOps,
im DevOps-Kontext besser automatisieren als andere
und das hochentwickelte Unternehmen im DevOps-Kontext auch die Cloud sinnvoller nutzen.
Also das heißt, natürlich kann ich Cloud-Angebote nutzen
und dann kann ich auch sagen, ich mache DevOps, lassen wir mal,
oder ich lasse es mal unkommentiert, aber eben der State of DevOps Report zeigt,
wenn ich Automation und Cloud wirklich gut nutze, sehr gut nutze, sinnvoll nutze,
dann bin ich auch erfolgreicher im DevOps-Kontext.
Also reicht es nicht, sich bei Microsoft in der Azure Cloud
die DevOps-Produktportfolios zu nutzen, die dann Azure DevOps heißen
und dann ist man fertig, ne?
Nein, nein, nein.
Du hast vergessen, den Ironie-Modus anzuschalten
oder auf den Ironie-Modus hinzuweisen.
Ja, das hört man mit meiner verstopften Nase gerade nicht.
Ja, ist okay.
Okay, dann lasst uns mal wechseln oder weitergehen.
Das war jetzt ja sozusagen der weltweite Blick, State of DevOps.
Und wir haben ja auch ein paar Kunden und da können wir auch ein bisschen berichten,
was unsere Kunden so erleben oder was wir bei unseren Kunden erleben.
Und ich würde sagen, Luca, hast du noch eine Idee von deinen Kunden,
was deine Sicht da ist, was deine Erfahrungen sind?
Ja, also wenn ich jetzt wieder so die Rückschau gehe,
als ich angefangen habe, das Thema DevOps in andere Unternehmen reinzutragen,
da war noch viel weniger Verständnis dafür da,
was das bedeutet, warum das wertvoll ist, was das überhaupt ist.
Das Witzige ist wahrscheinlich, das ist heutzutage immer noch nicht anders,
weil ihr wisst ja, wie es läuft, wenn man zehn Leute nach ihrer DevOps-Definition fragt,
kriegt man 20 Antworten.
Aber ich glaube, das Verständnis davon, dass das ein wichtiges Thema ist,
egal wie man es jetzt eigentlich fasst und wo man die Grenzen zieht,
das ist schon gewachsen.
Aber nichtsdestotrotz gibt es, glaube ich, immer noch einen verbreiteten Zweifel,
ob das etwas ist, was wertvoll ist für meine Organisation,
ob das etwas ist, was zu meiner Organisation passt.
Insbesondere auch, weil ich zunehmend beobachte, dass man erkennt,
dass man an die Grenzen der IT-Organisation stößt, beziehungsweise sie durchbricht.
Deswegen möchte ich da so ein bisschen auf deine DevOps-Definition von der Eingangsfrage hinweisen.
Dirk, die ich vor wahrscheinlich zwei Jahren noch voll unterschrieben hätte und wo ich jetzt,
gerade als ich dir zugehört habe, gefragt habe, hoch performante IT-Organisationen,
ob das denn noch reicht oder ob man nicht sagen muss, eigentlich gehört da viel mehr dazu.
Eigentlich müssen wir auch,
IT-Fremde, um es jetzt mal so auszudrücken, Kollegen mit einbinden,
sei das jetzt das Controlling oder sei das das Produktmanagement oder sei das, wer du möchtest.
Wenn du die Arbeitsweisen, die Verhaltensweisen und schlussendlich das Aussehen und Verhalten
deiner IT-Organisation änderst, wird das notgedrungen ausstrahlen
auf den ganzen Rest der Organisation und auf die Art und Weise, wie du Produkte schaffst.
Und das ist etwas, was ich zunehmend beobachte, dass das erkannt wird.
Häufig sozusagen im negativen Sinne, dass die Leute sagen,
also ich würde mich ja so gerne transformieren,
aber ich knall die ganze Zeit irgendwo vor eine Wand.
Mein Controller sagt, nö, so machen wir das nicht oder sowas.
Das nämlich zunehmend als Thema war,
dass man die Grenzen der klassischen IT-Abteilungen sprengt.
Sprengt oder sprengen müsste, also dass man quasi die Überzeugung,
dass DevOps hilfreich ist, das ist ja erstmal eine Philosophie,
es ist ja nicht irgendein Framework, es ist eine Philosophie,
es verändert an vielen Stellen Dinge und dass man das eben über die IT hinausbringt,
also das würde ich jetzt auch sagen, das ist auch aus meiner Sicht eine Wahrnehmung
und wenn man jetzt wiederum auf die IT guckt,
wir sagen ja mit DevOps versuchen wir Entwicklung und Betrieb zusammenzubringen.
Ich habe einige Kunden, die stellen immer noch fest, dass Ausschreibungen,
also große IT-Ausschreibungen genau das immer noch trennen.
Also da gibt es eine Ausschreibung für die Entwicklung und eine Ausschreibung für den Betrieb.
Ja, siehst du.
Ja, und insofern, das ist genau der Punkt.
Da ist irgendein Management, da gibt es irgendeine Juristik,
Juristische Abteilung, Kontrolling, Einkauf, wie auch immer,
die denken noch in alten Aspekten und sind wahrscheinlich auch schwierig zu überzeugen,
weil die IT kommt jetzt, hey, lass uns DevOps machen.
Ja, warum soll man DevOps machen?
Also das ist, also wenn wir auch in Zukunft wieder gucken, ein wichtiger Punkt,
quasi den Nutzen von DevOps, das Konzept von DevOps und eben auch die Vorteile für das Unternehmen,
aber auch die Konsequenzen von DevOps wirklich aus der IT hinauszutragen in die restliche Welt,
weil die restliche Welt ist ja da.
Und die haben auch ihre Aufgaben und haben auch ihre Ziele, die sie erreichen müssen.
Ja, letztendlich muss man von Kunde zu Kunde denken.
Also vom Kunden mit der Anforderung zurück über die ganzen Prozesse, Fachbereiche, Entwicklung, Architektur,
was auch immer so dazwischensteckt, bis man die Kundenanforderung wieder realisiert,
dem Kunden als Feature, als neues Produkt anbieten kann.
Und da hilft natürlich DevOps mit der Automatisierung.
Ja, aber das finde ich auch spannend.
Dass du das so gesagt hast, weil ich glaube, an der Stelle sind auch zunehmend IT-Organisationen
und insbesondere deren Leitung in der Pflicht, anderen Unternehmensteilen das wirklich zu erklären,
inwieweit die da auch einen Beitrag haben, einen Einfluss haben.
Weil ich könnte mir gut vorstellen, dass zum Beispiel ein Personaler nicht ganz zu Unrecht sagt,
was habe ich mit dem Kunden und dem Produkt zu tun?
Ich erbringe hier eine rein interne Funktion.
Macht ihr mal euer Ding.
Aber ich mache weiter meins.
Und natürlich sind diese Leute weder dumm noch gemein noch sonst irgendwas,
aber ich finde, sie haben durchaus ein Recht darauf,
dass man ihnen erklärt, inwieweit notwendig ist,
dass sie auch einen Beitrag leisten, indem sie vielleicht ihre Herangehensweisen ändern,
ihre Sichtweisen ändern.
Zum Beispiel, so wie du gesagt hast, Dirk, Projektausschreibungen anders fassen.
Ja, die Kundenkommunikation letztendlich auch mit einzubeziehen.
Das ist bei vielen Unternehmen halt die Schwierigkeit, die dann halt sagen,
okay, wir haben halt aus der öffentlichen Hand,
aus irgendwelchen anderen jahrzehntelangen eingeschwungenen Prozessen mit unserem Kunden
klassische Projektvorgehensweisen.
Und da steht halt eine Entwicklung, die wird halt dann ausgeschrieben.
Und wenn das dann soweit ist, dann ist das Produkt da.
Und dann geben wir es vielleicht auch ganz bewusst, ganz gerne an ein anderes Unternehmen,
mit dem wir halt gute Erfahrungen im Ops-Bereich haben.
Dass man dadurch natürlich gewisse Dinge verliert,
nämlich Kommunikationsprozesse, Feedback-Schleifen und anderes,
die dann auch der Wertschöpfung, in der Wertschöpfung, in der Wertschöpfungskette fehlen.
Das muss man natürlich an der Stelle dann erstmal bewusst machen.
Ja, ich finde auch, das ist ein ganz wichtiger Punkt, den ihr eben angesprochen habt.
Das ist eben immer noch dieses Projektdenken.
Und wir hatten ja über Team-to-Producties gesprochen.
Also ist ja eher eine Produktorganisation.
Und wenn ich natürlich Unternehmen habe, die auch in der Zusammenarbeit voll auf Projekte ausgerichtet sind.
Das ist ja auch da quasi.
Den Tanker muss der auch da sein.
Da musst du ja auch wirklich umorientieren in Richtung Produkte, Produktteams, Produktorganisationen.
Also auch da sehe ich diese Schwierigkeiten.
Und wir reden ja über die Zukunft.
Mir ist da nicht bange, weil ich eben sehe, dass die beteiligten Experten dort offen sind.
Also in den Trainings haben wir ja häufig, also ich kann es ja nur von mir sagen,
habe ich häufig die Experten, die Experten, die Fachexperten.
Und die sind da häufig offen.
Das heißt, die sagen, dass sie den Sinn verstanden haben,
dass sie die Konsequenzen verstanden haben
und versuchen, das in kleinen, kleinen Schritten umzusetzen.
Aber natürlich kommt man nicht aus den großen Punkten raus, aus der, aus einer Projektdenke.
Da muss man wirklich organisatorisch ran.
Also insofern, in die Zukunft geblickt, glaube ich, müssen wir es hinbekommen,
dass wir das Expertenwissen für IT auch organisatorisch umsetzen.
Ich möchte aber auf der Stelle einhaken, weil wo ich uns so zuhöre,
fällt mir da gerade irgendwie ganz gewaltig was auf.
Weil wir reden da jetzt irgendwie ganz gelassen davon.
Ja, Projektdenken ist böse.
Und Produktdenken ist gut.
Und ich frage mich, inwieweit in vielen Organisationen überhaupt klar ist,
was wir damit meinen.
Zum Beispiel, wenn wir mit diesen Begriffen um uns schmeißen.
Das ist, glaube ich, genau die Krux.
Wir gehen hier ganz lässig mit so einem Jargon um,
das vielleicht anderen gar nicht geläufig ist.
Und die vielleicht vollkommen nachvollziehbar finden,
wovon wir reden, wenn es ihnen nur mal jemand erklärt.
Was meinen wir denn eigentlich mit diesem Unterschied
zwischen Projekt- und Produktdenken, Dirk?
Naja, ich meine, das ist ja eine meiner,
meiner Lieblingsfolien von unserer Grundlagenschulung.
Nämlich genau von Aktivitäten orientiert zur Teamorientierung.
Und da kommen wir wieder auf den anderen Punkt zurück,
zu der Veränderung, die wir eben angesprochen haben.
Das heißt ja zum Beispiel, dass ich wegkomme von Spezialisten.
Dass ich hinkomme zu T-Shirt.
Und insofern ist es hilfreich,
wenn man diese Menschen in der Schulung sitzen hat,
weil da hast du ja die Spezialisten.
Und dann sagst du denen, wir brauchen euch nicht mehr.
Und das muss man natürlich erklären.
Weil wir brauchen die Spezialisten ja schon noch.
Aber ich glaube, Falko hat ja noch viel mehr Projekterfahrung.
Ob das so viel mehr ist, weiß ich nicht.
Aber ich möchte gerne an der Stelle
zwischen eher kürzeren Projekten,
die ein, zwei Jahre oder ähnliches laufen,
die für die Zeit ein Team zusammenstellen,
das dann hinterher wieder aufgelöst wird,
wo das Ergebnis dann an ein anderes Team übergeben wird,
das dann den Betrieb macht,
hin zu dem Produktdenken mit einem Produktlebenszyklus,
von der Initiierung, von dem Entwicklungsprozess
über einen Reifeprozess hin zu einem Betrieb,
das letztendlich von einem Team langfristig begleitet wird,
wo sich vielleicht das Team über die Zeit so ein Stück entwickelt,
auch vielleicht anders ausrichtet.
Vielleicht auch das eine oder andere Teammitglied wechselt
in ein anderes Unternehmen oder andere Bereiche.
Aber von dem Gedanken her am Produkt bleibt
und damit auch am Kunden bleibt
und somit auch eine Erfahrung aufbaut,
die ein Projektteam bei der Übergabe in den Betrieb
dem Betrieb nicht mitgeben kann.
Dass das einfach in den Köpfen mit dem Produkt gewachsenes Wissen
eben auch am Produkt bleibt
und das Expertentum halt nicht in einer Tätigkeit,
wie du es gerade beschrieben hast,
so ein Datenbankmanagement-Team oder IT-Betrieb,
oder Security-Team hat,
sondern dass man halt ein produktfokussiertes Experten-Team hat
mit einem Kundenbezug,
wo man letztendlich auch die Kundenbindung immer weiter treiben kann.
Das ist für mich der Kernaspekt dieser Produktdenke,
die man nutzen kann im DevOps-Umfeld,
weil eben Produkte für gewöhnlich eine längere Laufzeit haben.
Wenn ich mir anschaue, welche großen Mainframe-Systeme
da teilweise immer noch bei vielen Unternehmen laufen,
dann weiß ich, dass das nicht so einfach ist.
Das ist ein sehr guter Punkt.
Das ist ein sehr guter Punkt.
Das ist ein sehr guter Punkt.
Das ist ein sehr guter Punkt.
Das ist ein sehr guter Punkt.
Das ist ein sehr guter Punkt.
Das ist ein sehr guter Punkt.
Das ist ein sehr guter Punkt.
Das sind ja dann eher Jahrzehnte als Jahre oder Monate.
Im Gegenzug sind Projekte halt eher Monate bis maximal zwei, drei Jahre.
Das ist auch ein interessanter Punkt, den du da gerade ansprichst,
auch mit lange währenden, zum Beispiel Mainframe-Systemen oder sowas.
Ich weiß nicht, wie es euch geht,
aber das ist etwas, was ich zunehmend beobachte auch in den Gesprächen,
dass Organisationen sich auch dessen bewusst werden,
dass sie noch über längere Frist oder vielleicht sogar sehr langfristig
noch zweigleisig fahren müssen,
dass sie eine in Anführungszeichen moderne Produktentwicklung,
von neuen Produkten haben, die auf die eine Weise funktioniert,
die den einen Produktbegriff hat und dass sie zum anderen
aber auch noch gewachsene Strukturen, Mainframes, was auch immer haben,
die sie noch auf lange Sicht pflegen müssen
und die vielleicht ganz andere Rhythmen erfordern,
die vielleicht auch andere Strukturen erfordern.
Man denke an Conway’s Law.
Wenn ich eine Mainframe-Applikation habe und die hat eine Architektur,
dann kann ich da nicht irgendwelche beliebigen anderen Teams aufpropfen.
Das endet ja in Tränen.
Ja.
Ist das auch etwas, was ihr beobachtet?
Ja, das kann man machen.
Aber hat man…
Natürlich größere Schwierigkeiten.
Das ist wie immer.
Man kann vieles machen.
Man sollte aber nicht alles, was man kann, auch tun.
Aber einfach auch so dieses Bewusstsein so,
wir können gar nicht unsere ganze Organisation hier so peng neu ausrichten,
sondern wir müssen das scheibchenweise machen
und es wird vielleicht sogar einige Scheiben der alten Organisation geben,
die noch sehr lange Bestand haben werden
und wir müssen uns was einfallen lassen, wie wir damit umgehen.
Ja, das hört man im CIO-Bereich halt häufig.
Da gibt es ja diese multimodalen IT-Umgebungen,
die modal halt mit unterschiedlichen Geschwindigkeiten arbeiten.
Klassische rechenzentrumgetriebene Produkte,
die man halt schon lange selbst hostet
und vielleicht auch neuere, eher cloudartig ausgerichtete,
vielleicht auch wirklich mit einem Cloud-Anbieter zusammenarbeitende Infrastrukturen,
die dann außer Haus betrieben und bereitgestellt werden,
sind natürlich dann Aspekte, die man dabei bewerben muss.
Das ist der Aspekt der unterschiedlichen Plattformen,
die wir halt auch in den State-of-Devops,
in den State-of-Devops-Reports sehen.
Dirk, magst du dazu noch was sagen?
Ja, weil ich dort auf meine Definition wiederkomme,
weil multimodal oder bimodal,
was ja vor Jahren hochgehypt wurde durch ein paar Berichte auch von BMW und so weiter,
auch durch Unternehmensberatungen,
klassische Bekannte, die das als Idee verkauft haben,
hat immer für mich das Geschmäckle dabei,
dass schnell gut ist.
Also die einen sind schnell und die anderen sind langsam.
Der wird schon langsam sein.
Deswegen multimodal, wenn ich das mache oder bimodal,
dann, ich habe bei der Meinung da auch ein bisschen geändert.
Wichtig ist aber, dass man klar macht,
schnell muss nicht immer gut sein.
Beziehungsweise andersherum, ich habe Gründe,
weswegen ich vielleicht in bestimmten Umgebungen gefühlt langsamer bin,
aber trotzdem eine gute Qualität liefere.
Und für die Schnellen heißt es wirklich auch Qualität liefern.
Ganz wichtig.
Ich würde sogar so weit gehen zu sagen,
schnell ist eine Konsequenz von gut.
Wenn ich die Sachen gut mache,
dann werde ich in der Konsequenz daraus schneller werden.
Ich muss nicht noch mehr Schleifen drehen.
Ich muss keine Schaden auswetzen.
Da gibt es diesen Spruch, den ich, glaube ich, gehört habe bei den US Marines,
die immer sagen, slow is smooth and smooth is fast.
Was heißt das auf Deutsch?
Langsam ist geschmeidig und geschmeidig ist schnell.
Gut, das muss ich sacken lassen.
Ja, aber es ist letztendlich ja ein Thema,
dass man in der DevOps-Welt mit zum Beispiel groß angehäuften,
technischen oder anderen Schulden,
das sind ja nicht finanzielle,
können ja aber auch organisatorische oder soziale oder Wissensschulden sein,
dass die Mitarbeiter letztendlich in einem Unternehmen unterwegs sind,
bei dem viel auf die Zukunft projiziert wird,
auch Aufgaben in die Zukunft projiziert werden auf dem Weg,
die dann letztendlich als Hürde in der Zukunft im Weg stehen.
Also wenn man schnell sein will,
dann muss man entsprechend auch gut arbeiten,
damit man in Zukunft auch weiter schnell,
schneller sein kann.
Nachhaltige Geschwindigkeit, ne Dirk?
Also ich finde, was wir gerade zu tun ist,
wir philosophieren ein bisschen.
Und ich würde dieses Philosophieren mal so ein bisschen nutzen,
um auch wieder in die Zukunft zu gucken.
Ich habe ja immer wieder gesagt,
dass für mich DevOps eine Philosophie ist,
es ist ja kein Framework.
Das macht es auf der einen Seite vielleicht ein bisschen einfacher,
weil man nicht ein Framework einführen muss
und sich dabei die Finger vielleicht verbrennt
und auch vielleicht zu sehr durch das Framework eingeengt wird.
Natürlich auch mit der Herausforderung,
diese Philosophie immer wieder zu erklären.
Und was ich eben dabei positiv finde,
ist, dass durch diese Akzeptanz von DevOps,
dass eben auch die Philosophie immer stärker weiter verbreitet wird.
Das heißt eben Frameworks in anderen Frameworks wie IT4, wie SAVE,
da sind weiterhin DevOps-Ansätze mit drin,
DevOps-Ansätze werden eingebaut.
Das heißt also, die Gedanken, die Philosophie von DevOps,
die werden quasi damit auch in die Menge oder in die Breite getrieben,
weil eben andere Frameworks erkannt haben,
das ist hilfreich, das ist akzeptiert.
Und insofern wird dadurch auch DevOps quasi wirklich in die Breite verteilt.
Und das erleben wir auch, das hatten wir eben schon gesagt,
wir erleben immer wieder IT-Mitarbeiter, die das verstehen.
Wenn du auf erfahrene IT-Mitarbeiter schaust,
dann sagen sie, dass sie das schon früher gemacht haben.
Also früher haben schon DevOps zusammengearbeitet.
Und das kann man natürlich bei entsprechender Motivation
auch wiederum nutzen und einbringen.
Also insofern, was ich eben in Zukunft blickend positiv finde, ist,
es gibt eine ganze Reihe von Best Practices aus der Praxis,
die fließen in die Philosophie ein.
Also die müssen nicht in einem Framework niedergeschrieben werden,
sondern die fließen in die Philosophie ein.
Und ein schönes Beispiel haben wir ja vorhin schon angesprochen,
das ist Team Topologies.
Also in die Zukunft blickend, sage ich mal, was ich schön finde,
ist, das ist eine Philosophie und die lebt, die erweitert sich,
die wird besser durch viele Beispiele aus der Praxis
und das stimmt mich auch hoffnungsfroh für die Zukunft.
Ich finde, das hast du toll gesagt.
Und ich finde es immer wahnsinnig ermutigend,
wenn alte Hasen dann in den Trainings drin sitzen und sagen,
ja, das haben wir doch früher auch schon so gemacht.
Ich finde, das ist eine ausgezeichnete Neuigkeit,
weil das heißt, so blöd können diese ganzen Ideen ja alle gar nicht sein.
Und es ist ja auch so, also DevOps, wenn man ehrlich ist,
enthält ja gar nicht wirklich was Neues, noch nie Dagewesenes.
Das integriert Teile von Agile, die von sich aus schon eine gute Idee waren.
Und übrigens auch die agile Idee natürlich ist bestimmt viel älter,
als das agile Manifest, das 2001 verfasst wurde,
sondern das ist das, was in meinem Ingenieurstudium
mir meine Professoren immer als ingenieurmäßiges Vorgehen verkauft haben.
Insofern, ich glaube, das ist, wie gesagt, das ist eine ganz tolle Nachricht.
Und wie wir, glaube ich, auch schon beobachtet haben,
in diesem Sinne hat DevOps auch einen gewissen Siegeszug angetreten.
Der Begriff hat sich einfach verfestigt.
Viele andere Frameworks wollen jetzt auch ein Stück vom Kuchen haben.
SAFe spricht auch über DevOps.
ITIL 4 spricht auch über DevOps.
Erstens über den Begriff, aber zweitens natürlich auch über die Inhalte
und Herangehensweisen, zum Teil haben sie die auch selber gefunden,
sehr zu Recht, weil sie machen ja Sinn.
Wo wir gerade so mit Abkürzungen um uns geworfen haben,
mit SAFe und ITIL, in unserer IT-Blase,
da kann man einfach voraussetzen, dass das bekannt ist.
Was ich aber immer sehr schön finde, das ist ja so ein bisschen ironisch,
das sind die ganzen tollen Abkürzungen, die wir in der IT immer haben.
Und wenn ich jetzt von DevOps spreche und wir in die Zukunft blicken wollen,
was machen wir denn mit?
No-Ops, DevSecOps, DevTestOps, BizDevOps, DevDevBuffBuff,
also diese ganzen Begrifflichkeiten, die man da kombiniert,
das ist ja auch eine Herausforderung aus meiner Sicht,
diese ganzen angrenzenden Themen oder auch beinhaltenden Themen rein zu integrieren,
in die Philosophie reinzubringen.
Was ist da eure Erfahrung?
Ja, das ist ein heißes Eisen.
Das haben wir, glaube ich, schon ein paar Mal angesprochen jetzt.
Es geht wirklich darum, dass da auch Bewusstsein wächst.
Ich meine, wir sprechen immer von DevOps, so als ob es nur Dev und Ops betreffe,
aber das ist ja gar nicht wahr, sondern DevSecOps ist momentan ein Thema,
das in aller Munde ist, sehr zu Recht natürlich,
wobei ich persönlich mich dann immer so ein bisschen wundere, warum man das raushebt.
Ich bin ja ein alter Softwarequalitäter.
Ich persönlich bin immer sehr begeistert von DevTestOps.
Insofern, ich glaube, da wächst einfach vieles zusammen, was zusammengehört.
BizDevOps, DevTestOps, DevSecOps, was du möchtest,
alles, was halt in den Wertstrom rein muss,
alles, was dazu beiträgt an Aktivitäten und Sichtweisen,
um Wert für den Kunden bereitzustellen.
Und das ist natürlich ganz, ganz vieles.
Genau. Letztendlich bildet das doch die verschiedenen Walls of Confusion,
also die letztendlich Silo-Grenzen, die ein Unternehmen hat, ab.
Die können von Unternehmen zu Unternehmen unterschiedlich sein.
Und viele agile Teams, die Testen im Team verankern,
haben natürlich DevTestOps mit im Blick.
Das ist ein Video, was häufig ein bisschen weiter entfernt ist
von der reinen Entwicklung und auch vom reinen Betrieb.
In verschiedenen Organisations-Aufbauorganisationen
ist halt die IT-Security, da ist sicherlich auch Datenschutz dabei.
Wenn man sich mal den Prozess anschaut,
so klassische Wasserfall-Prozessstufen,
sind das ja auch irgendwo Walls of Confusion,
wo Übergaben von verschiedenen aufgabenorientierten Teams
zu anderen aufgabenorientierten Teams fällig sind.
Und letztendlich ist es eine Abbildung
der verschiedenen Walls of Confusion, die man hat,
die man versuchen sollte abzubauen.
Nicht unbedingt immer mit dem Ansatz auf die Wall of Confusion
irgendjemanden als Rolle draufzusetzen,
der dann die Transformation macht,
also zwischen Dev und Ops den DevOps-Engineer,
der halt dann die gebauten Pakete nochmal, keine Ahnung,
überprüft und betriebsfähig macht.
Oder den Product Owner zwischen Business und Entwicklung.
Das kann man unbedingt mit einer Rolle machen.
Man kann die Teams auch so organisieren,
dass die Kommunikationsprozesse das abbilden
und dass sie cross-funktional aufgebaut sind,
ohne dass man dafür extra Rollen schafft.
Aber letztendlich ist ja das Ziel, wie Luca gesagt hat,
den Wertstrom vielleicht auch eine Wertschleife mit dem Gedanken,
dass man halt auch Feedback am Ende wieder einsammelt,
um den Wert auch weiter zu steigern.
Also eine selbstverstärkende Rückkopplung,
bei der man letztendlich aus dem Feedback vom Kunden
wieder gute Ideen, gute Gedanken für eine Weiterentwicklung des Produkts hat.
Und solche Schleifen aufzubauen sind natürlich sehr hilfreich.
Ja, da sagst du auch was Wahres.
Das ist jetzt etwas, was ich vielleicht nicht so sehr in der Debatte wahrnehme,
aber etwas, von dem ich mir wünschen würde,
dass es etwas präsenter wäre.
Das beobachte ich nämlich oft bei Kunden,
dass sie, wenn sie ihre Prozesse verbessern,
ihre Automatisierung verbessern,
sich sehr stark auf die Vorwärtsrichtung fokussieren,
auf den Wert Strom, der irgendwie immer stromabwärts geht.
auf den Wert Strom, der irgendwie immer stromabwärts geht.
auf den Wert Strom, der irgendwie immer stromabwärts geht.
In Richtung Kunde.
Und unangenehmerweise häufig so ein bisschen vergessen,
dass die Rückwärtsrichtung ja ebenso wichtig ist,
die Rückkopplungsrichtung.
Darum, das ist momentan mein persönliches Steckenpferd
in Bezug auf DevOps und verwandte Themen,
Rückkopplungsschleifen zu stärken.
Das hat ja schon Gene Kim damals in den drei Wegen definiert,
wenn man überlegt, man hat den ersten Weg,
das ist der Wert Strom,
das ist letztendlich der Fokus,
überhaupt einen kontinuierlichen Entwicklungsprozess,
Betriebsprozess, neue Features
in einem regelmäßigen Rücken,
Rhythmus vielleicht sogar automatisierbar auf den Weg zu bringen
und dann die Stufe 2 zu nehmen
und zwar die Feedbackschleifen aufzubauen
und die vielleicht natürlich auch in kleinen Feedbackschleifen
über Continuous Delivery Pipelines,
wo dann halt Testergebnisse, Feedback für die Entwickler liefern
und anderes.
Aber eben auch die gesamte Schleife
von der Kundenanforderung wieder zurück zum Kunden
und dann wieder zur nächsten Anforderung.
Was häufig die längste Feedbackschleife
in einem gut geölten Continuous Delivery getriebenen
Entwicklungsprozess ist.
Ja, das ist interessant, dass du das sagst,
weil Jane Kim hat das wann?
2011 formuliert, die drei Wege.
Und es zeigt sich, wie schwer es ist,
diese an sich relativ einfache und einleuchtende Maxime
halt auch tatsächlich umzusetzen.
Genauso wie übrigens auch,
und das beobachte ich ja auch immer wieder,
es wahnsinnig schwer ist,
sich von dem klassischen Rollendenken,
von dem klassischen Silo-Denken zu lösen,
selbst bei allerbesten Absichten.
Ganz plötzlich rutscht man also versehentlich
wieder zurück in Silos hinein
und in Zuständigkeiten hinein
und so weiter.
Ich glaube, in der Hauptsache
ist es auch eine Art Ermutigung,
auf sich selber aufzupassen und zu schauen,
treffe ich da die richtigen Entscheidungen,
laufe ich da in die richtige Richtung?
Einfach, weil es doch irgendwie unangenehm leicht ist,
da wegzurutschen,
obwohl man es eigentlich besser wissen sollte.
Und wenn man jetzt wieder das Thema Zukunft
von DevOps fokussiert,
finde ich es gut, was ihr beide gesagt habt,
das Thema Value Stream, also Wertorientierung.
Weil auch das, glaube ich,
wird immer mehr im Mund gehen.
Das, glaube ich, wird hilfreich sein, näher an die Kunden ranzukommen.
Und auch all das, was ich tue, wo wir Probleme sehen in Silos, in getrennten Aktivitäten, in unterbrochenen oder nicht vorhandenen Feedback-Schleifen,
dass man eben wirklich unabhängig von irgendwelchen Frameworks, von irgendwelchen Rollen, von Funktionen, von Bereichen,
sich immer mehr anschaut oder immer häufiger, intensiver anschaut, wo sind wirklich diese Wertströme.
Und da, glaube ich, ist aus meiner Sicht auch viel Potenzial, vieles von dem auch anzugehen,
was wir vorhin auch im Podcast bis jetzt schon auch als Schwierigkeit benannt haben.
Also ich glaube, dass Wertstromorientierung, wir haben sie auch, das haben wir in ITIL, wir haben es in SAVE,
also diese Wertstromorientierung findet sich eben dort immer häufiger wieder.
Und ich glaube, dass man mit diesem Ansatz auch diese verschiedenen Bereiche mit Testen, mit Security, mit Kunden und so weiter,
also alles sehr gut hat.
Sehr viel einfacher und auch vielleicht pragmatischer in so ein Thema hochperformante Organisationen einbringen kann.
An der Stelle würde ich letztendlich darauf hinaus wollen, dass man sagt, Wertstrom,
Waste Remapping, Waste Remanagement sind Techniken, die sich aus der Produktentwicklung ergeben haben,
die auch viele produzierende Unternehmen schon lange im Einsatz haben, die Lean Management wirklich greifbar machen.
Und aus meiner Sicht ist das eine Richtung.
Die viele Unternehmen noch zu gehen haben, vor allem in dem IT-Umfeld und aus meiner Sicht ist es auch ein Stück Professionalisierung der IT,
die da mit dranhängt, die ein großer Treiber hinter dem DevOps-Thema letztendlich ist und hoffentlich auch dazu beiträgt,
dass Unternehmen dann Kapazitäten, die sie vielleicht in nicht ganz so performanten IT-Prozessen gebunden haben,
frei bekommen, um eher…
Kunden getrieben, eher automatisiert, eher auch vielleicht schneller und oder besser,
zumindest nicht mehr in der Richtung technische Schulden aufbauen, sondern eher abbauen, umsetzen können.
Mir gefiel gerade ein Wort, das der Dirk verwendet hat, nämlich das Wort pragmatisch.
Und als ich das gehört habe, dachte ich so ein bisschen an das Thema SRE, Site Reliability Engineering,
das ja zunehmend an Fahrt gewinnt.
Das ist jetzt natürlich ein Thema, das nicht erst 2022 aufgeploppt ist, aber nichtsdestotrotz.
DevOps ist ja angetreten mit dem Anspruch,
wir vereinen Entwicklung und Betrieb und lassen das alles von einem Team verantworten.
Und es hat sich gezeigt, manchmal ist das einfach nicht der pragmatische Ansatz,
weil es macht halt vielleicht durchaus Sinn, dass man Fachleute für den Betrieb hat,
für den fortwählenden, stabilen, reibungslosen Betrieb von großen IT-Infrastrukturen
und dass man die deswegen mit Fug und Recht halt vielleicht doch auslagert und als was Separates betrachtet,
aber dass man natürlich trotzdem erstens ihnen dieselben, ich sag jetzt mal, Denkweisen und Hilfsmittel an die Hand gibt,
wie Entwicklungsteams oder DevOps-Teams und dass man zweitens trotzdem dieses Hand-in-Hand-Arbeiten nicht vernachlässigt,
sondern es nur ein bisschen auf andere Füße stellt.
Man sagt, okay, das sind tatsächlich zwei verschiedene Gewerke, aber natürlich müssen die miteinander zu tun haben.
Und insofern, auch da ist SRE etwas für mich, was mich lange beschäftigt hat.
Bei DevOps, da habe ich mich immer gefragt, wie macht man das denn in langlaufenden Produkten,
dass man zunächst quasi null Betrieb hat und 100% Entwicklung, ist ja noch nichts da, was du betreiben kannst,
und zu irgendeinem Punkt schwenkt das um und dann habe ich, ich weiß nicht, 90% oder 95% Betrieb
und dann habe ich 5% oder 10% Entwicklung, die sich dann im Wesentlichen auf Bugfixing reduzieren.
Aber gleichzeitig fordere ich stabile Teams, nicht sich wandelnde Teams.
Wie passt das denn? Jemand, der gerne Entwickler ist, möchte der gerne Betrieb machen.
Solche Leute gibt es auch, aber im Großen und Ganzen, Schuster, bleib bei deinem Leisten.
Und insofern finde ich SRE da einen wunderbaren Baustein, um diesen Widerspruch so ein bisschen aufzulösen und zu sagen,
ja, es gibt.
Diese andere Blickrichtung, aber dieselben Werkzeuge, dieselben Denkweisen, die finden da auch ihre Anwendung.
Darum ist das aus meiner Sicht irgendwie eine sehr hilfreiche Entwicklung, oder wie seht ihr das?
Also ich finde das auch sehr hilfreich.
Für mich ist das auch wieder ein Beispiel, dass die DevOps-Philosophie erweitert wird um Best Practices,
also für mich ist SRE genauso ein Best Practice und das ist ein Indikator für mich,
dass eben diese beiden Bereiche zusammenwachsen.
Also selbst wenn sie irgendwie sozusagen getrennt werden,
inhaltlich oder getrennt bleiben, inhaltlich wachsen sie zusammen,
weil einfach ein Austausch stattfindet, also ein konzeptioneller, ein inhaltlicher Austausch.
Genau, jeder kann sich auf das fokussieren, was er gut kann und was ihm liegt,
aber gleichzeitig ist die Gemeinsamkeit des Zieles bleibt erhalten.
Jetzt würde ich gerne noch ein bisschen Salz in die Wunde streuen, die wir vorhin hatten,
nämlich das Thema stagnierende DevOps-Transitionen.
Ich glaube, da haben wir vorhin immer so ein bisschen das so gestreift,
also wir wollen ja nicht nur hier eine rosa, heile Welt rüberbringen.
Also es gibt, glaube ich, und das stelle ich eben auch fest, viele stagnierende DevOps-Transitionen.
Ich merke das dann, wenn man in Workshops sitzt und da kommt ein Ergebnis raus
und dann gibt es keinen Folge-Workshop.
Ja, dann ziehen sich zurück die Unternehmen, die machen irgendetwas,
aber man hat das Gefühl, dass sie in so einer Art, ja, bei den Sackgassen sind oder wo auch immer sind,
dass sie nicht vorwärts kommen.
Was denkt ihr? Also lebt ihr das auch?
Ja, das ist das, was wir machen.
Und vor allen Dingen, wenn es so wäre,
dass Stagnation festzustellen ist, was hat das für die Zukunft von DevOps für Auswirkungen?
Ja, also das ist auch etwas, was ich beobachte,
dass man mit großem Elan da irgendwie Initiativen startet
und die treffen dann halt irgendwann mal auf die Mühsalde-Ebene
und dann geht es irgendwie nicht so richtig weiter.
Dann hat man schon so ein bisschen Automatisierung eingeführt irgendwie
und dann hat man schon, weiß nicht, so agile Teams aufgestellt,
aber so richtig rund läuft das auch nicht.
Und vielfach hört man dann, also wir hatten uns da irgendwie,
mehr davon versprochen.
In der Tat höre ich ja auch eine zunehmende Diskussion darüber,
dass das Agile ja doch gar nicht so toll ist,
weil, ja, wir haben es probiert und es ist eigentlich voll nervig bloß
und dann hast du die ganze Zeit irgendwie Daily Stand-Ups
und am Ende kommt nichts bei rum.
Und mein persönlicher Eindruck ist,
dass das einfach dem geschuldet ist,
dass das ein so tiefgreifender Wandel ist,
dass ich zum Beispiel einen ganz anderen Ansatz des Risikomanagements wähle
als im klassischen Projektgeschäft vielleicht,
wo ich versuche durch sehr strikte Festlegungen,
durch sehr strikte Planung,
Risiken zu managen und die agile Welt sagt halt,
wir machen das, indem wir elastisch sind,
indem wir Feedback einholen,
indem wir uns auf beobachtete Situationen
jederzeit neu einstellen können.
Und wenn du diesen Schritt halt nicht vollständig gehst,
sondern so zwischen den Stühlen sitzen bleibst,
ja, dann ist es halt irgendwie ungemütlich.
Und das ist etwas, was ich zunehmend beobachte,
eben diese so halben Transitionen,
die dann ganz häufig auch gemessen an dem Aufwand,
den man da betrieben hat,
organisatorisch, technisch und auch emotional,
halt ganz ehrlich,
nicht ein bisschen wenig bringen.
Also wenn ich da drin säße,
würde ich auch sagen,
na ja, also war das jetzt echt alles.
Aber wann ist denn eine Transition eine halbe
und wann eine ganze?
Letztendlich geht es doch darum,
dass es einen Schwung gibt,
den man kontinuierlich halten kann,
der eine Weiterentwicklung,
wie kann man glaube ich auch definiert,
evolutionäres Change Management betreibt.
Also wirklich in kleinen Schritten kontinuierlich da dran bleibt,
auch die Veränderungen aufrechtzuerhalten.
Was für mich,
was für mich natürlich eine häufige Aufgabe ist,
die man zum Beispiel,
wenn man agil zum Beispiel Scrum getrieben arbeitet,
dann auch der Scrum Master den Teammitgliedern einimpfen muss.
Dass letztendlich Unternehmen häufig solchen Antrieb brauchen,
wenn sie in klassischen Vorgehensweisen unterwegs sind,
ist eine Erfahrung, die ich gesehen habe.
Und die Unternehmen,
wo ich einen relativ langsamen Entwicklungsprozess
oder gegebenenfalls auch sowas,
wie ihr als gestoppt oder irgendwie nicht weiterkommend gerade beschrieben habt,
haben aus meiner Sicht auch diesen Drive
aus den nicht besetzten Scrum Master Rollen heraus
nicht im Unternehmen etabliert bekommen.
Vielleicht ist das ein Aspekt,
dass man auch diese Ende-zu-Ende
und vollständig implementierte Scrum Vorgehensweise
oder Kanban Vorgehensweise als Grundlage braucht,
damit es diesen kontinuierlichen evolutionären Change Prozess,
Veränderungsprozess auch dauerhaft weiter treiben kann.
Wie seht ihr das?
Ich denke, da sagst du was sehr Wahres.
Denn es braucht eben tatsächlich diesen Treiber,
der muss jetzt auch nicht zwingend von außen kommen,
aber ganz häufig erlebt man das halt,
dass die Leute dann sagen,
naja, wir haben jetzt, keine Ahnung, Agile eingeführt,
uns bringt gar nicht so viel
und dann bleiben sie an der Stelle irgendwie stehen.
Statt dass sie dann den naheliegenden nächsten Schritt gehen würden,
zu sagen, Moment, was ist da los?
Warum fühlt sich das nicht so an,
wie wir uns das vorgestellt haben?
Denn ganz so,
ganz häufig findet man halt so eine Art von Cargo Cult Agile,
dass man alle Zeremonien eingeführt hat,
dass man die auch irgendwie macht,
aber dass man am Ende halt nicht weit genug gegangen ist.
Und das finde ich auch wahnsinnig verständlich und nachvollziehbar,
weil man bohrt da halt ein ganz schön dickes Brett.
Das ist ein sehr tiefgreifender Wandel,
ein sehr tiefgreifender, auch kultureller Wandel,
auch emotionaler Wandel für den Einzelnen.
Und ich finde es wahnsinnig verständlich,
dass einem da irgendwie unterwegs die Puste ausgeht
oder dir ein Mut ausgeht oder sowas.
Oder dass man es einfach unterschätzt hat,
auch schlicht und ergreifend.
Naja, aber ist doch schon,
da war ja so ein paar Steine ab,
die kriegen wir doch locker hin.
Wir machen eine Schulung und dann läuft das.
Genau.
Und das ist eben das, was ich beobachte,
dass ganz häufig,
und da hauen wir wieder in dieselbe Kerbe,
die Falco vorhin genannt hat von Rückkopplungsschleifen,
dass es da niemanden gibt,
der einfach mal sagt,
aha, was ist da los?
Zum Ende der Episoden unserer Podcast-Folgen
kommt ja auch immer mal die Frage,
also zumindest stelle ich die immer sehr gerne,
hast du noch irgendwas nicht gesagt?
Also haben wir mit unseren Fragen bei unseren Gästen
noch irgendwas nicht,
die haben wir noch nicht abgedeckt.
Und wenn ich jetzt nochmal ein bisschen
wieder auf den Titel gucke,
Zukunft von DevOps,
würde ich gerne unsere jetzige Diskussion
auch ein bisschen dahin bringen,
was sehen wir denn sozusagen in der Zukunft?
Und ich glaube,
dass DevOps auch immer vielfältiger wird.
Und das fällt mir,
ist mir sofort eingefallen,
als Luca eben vor den Schwierigkeiten,
oder wir eigentlich alle
vor den Schwierigkeiten gesprochen haben,
es wird vielfältiger
und damit wird es nicht einfacher.
Also es wird vielfältiger,
das ganze Thema,
ich sage mal,
Remote Work mal reinzubringen,
KIs reinzubringen und so weiter,
Serverless,
also es gibt ganz viele Dinge,
die darauf einwirken auf DevOps,
oder die einen Einfluss auf DevOps haben.
Vielleicht können wir das nochmal ganz kurz
ein bisschen beleuchten zum Abschluss.
Was denkt ihr dazu?
Ja, ein Aspekt,
den verschiedene Unternehmen,
vor allem größere haben,
ist, wie organisieren sie sich
in einer agilen Vorgehensweise,
die ein Produkt- und Kundenfokus haben,
wenn dann dann 10, 20, 100 Teams daran beteiligt sind,
wenn dann dann 10, 20, 100 Teams daran beteiligt sind,
wenn dann da auf einmal 1.000 Leute
an einem großen Produkt,
an einer Plattform arbeiten,
die dann eben für wirklich
Tausende, Hunderttausende Kunden gedacht ist,
wie organisiert man sich da?
Das ist ein großer Aspekt.
Und da kommen natürlich Skalierungsframeworks ins Spiel,
in erster Linie
von der Marktverteilung her,
ist Safe da groß im Wachstum,
ist für mich auch ein guter Einstieg
für Organisationen,
die aus einer klassischen Welt kommen
und dann in agilen,
agiles Arbeiten
in größeren Teamstrukturen vorangehen,
kann sich natürlich weiterentwickeln.
Da sehe ich dann andere,
zum Beispiel Less oder
je nachdem, was es für Teams sind,
haben wir auch eine kleine Schulung zugebaut,
wenn ich mich da nicht so falsch erinnere,
DevOps skalieren,
wo wir die DevOps-Sicht
in den verschiedenen Frameworks auch immer beleuchten,
finde ich ganz hilfreich,
vor allem dann, wenn man noch in der Entscheidungsphase ist,
was ist denn das richtige Framework,
wo starten wir dann?
Oder,
wenn man sich inspirieren lassen will,
wir kommen irgendwie jetzt gerade nicht weiter,
wir haben jetzt alles das,
was Framework X uns liefert,
implementiert,
stecken gerade irgendwie fest,
könnten jetzt irgendwo mal einen Anstoß brauchen,
wäre aus meiner Sicht ein guter Punkt,
sich da in die Richtung zu entwickeln.
KI, Luca,
was sagst du zu KI?
Um Gottes Willen.
Es würde uns erst mal Intelligenz
bei den Menschen helfen, ne?
Bei mir auf jeden Fall.
Auf jeden Fall.
Nee, aber,
also, ja, ich sehe jetzt KI gar nicht so sehr
als Hilfsmittel für DevOps,
auch wenn ich mir das sogar auch vorstellen kann,
gerade wenn es um Monitoring geht,
dass man da auch automatisierte Systeme hat,
die einfach, ich sag jetzt mal,
das gewöhnliche Verhalten eurer Organisation beobachten
und einfach mal die Hand heben,
wenn sie eine Veränderung sehen.
Selbst wenn sie die selber vielleicht gar nicht einschätzen können,
aber die einfach sagen,
normalerweise passiert doch immer diese Sache,
warum passiert die jetzt nicht?
Was ist da los?
Aber vor allen Dingen,
auch andersherum gesehen,
wenn ich jetzt KI als Bestandteil neuer Produkte sehe,
was bedeutet das denn für die Arbeitsweisen?
Was bedeutet das für die Zusammenarbeit?
Jetzt ganz stumpf auf vielleicht technischer Ebene,
wie binde ich ein KI-System in meine automatischen Tests ein
oder in mein Continuous Integration ein,
aber auch bis hoch zur organisatorischen Ebene
oder vielleicht sogar bis zur kulturellen Ebene?
Es macht halt alles noch vielfältiger,
noch komplexer.
Genauso auch solche Techniken wie Serverless,
wie Orchestrierung,
Orchestrierung auf der einen Seite
und andererseits aber auch das,
was wir auch schon gesagt haben,
nämlich die zunehmende Realisierung,
dass wir Mainframes oder andere gewachsene Legacy-Applikationen
einfach noch auf lange Sicht weiter betreiben müssen und wollen.
Also es wird einfach irgendwie, glaube ich,
vielschichtiger und komplexer
und ich behaupte,
dass es unter solchen Umständen besonders hilfreich ist,
sich zurückzubesinnen auf zugrunde liegende Prinzipien,
zum Beispiel auf die drei Wege von Gene Kim.
Wenn du die nimmst und sagst,
okay, was bedeutet das denn für mich?
Dann kriegst du auch einen Dreh dran,
was das zum Beispiel bedeutet,
wenn du jetzt eine KI-Komponente in dein Produkt einbaust
oder was weiß ich was.
Also ich glaube,
man braucht eine zunehmende kulturelle Reife,
sage ich mal,
um der zunehmenden Komplexität Herr zu werden.
Oder, Dirk?
Ja, vielleicht auch eine Entmystifizierung.
Ich habe also jetzt besonders auf dieses Wort geachtet,
dass ich mich dabei nicht verhaspele,
weil das ist das,
was ich bei dir eben so ein bisschen rausgehört habe
und positiv empfunden habe.
Also nochmal eine,
eine,
eine Wertorientierung,
eine Orientierung an Prinzipien,
weg von irgendwelchen Frameworks,
weg von Dogmatismus,
von wegen, das muss so sein,
das haben wir immer so gemacht,
weil wir ansonsten diese Vielfältigkeit
gar nicht integrieren können,
weil wir ja auch mit schnelleren,
mit agileren Frameworks
oder mit agilen Vorgehen,
fange ich ja selber schon vor,
mit agilen Vorgehen,
Vielfältigkeit ja unterstützen,
aber vielleicht bin ich da auch manchmal
auch auf dem falschen Weg.
Also insofern Entmystifizierung
von klassischen,
von agilen,
ähm, Frameworks,
einfach schauen auf Prinzipien,
auf zum Beispiel das,
was Gene Kim gesagt hat,
um neue Aspekte wie Remote Work,
wie KI,
was es auch immer so gibt,
um das quasi einzubinden.
Und das wäre auch mein Schlusswort für das,
äh, für die heutige Folge.
Also ich glaube,
dass es so die Zukunft von DevOps ist,
so ein bisschen entmystifizieren,
pragmatischer werden,
ähm, und immer zu schauen,
wo schaffen wir Wert?
Wie kriegen wir unsere Prinzipien
umgesetzt?
Alle, alle zeigen gerade aufeinander
und keiner möchte jetzt den nächsten, äh,
Nee, alle zeigen auf dich.
Richtig, Falco, du bist dran.
Also ich, ich sehe es letztendlich, ähm, so,
ich bin ja auch gerade am reden, ähm,
passt ja auch.
Zurück zum Thema Zukunft von DevOps.
Letztendlich sind aus meiner Sicht
die nächsten Schritte wirklich die
Ende-zu-Ende-Sicht zu realisieren,
teamübergreifend, unternehmensweit, ähm,
den Gedanken zu fassen,
also von der, also der erste Weg von Gene Kim,
ne, den engen Blick rein Entwicklung und Betrieb
zusammenzubringen, zu über, nicht zu übergehen,
sondern halt weiterzudenken und wirklich den gesamten
ersten Weg abzubilden, Ende-zu-Ende zu denken,
dann dabei auch den Kunden, den Kunden im Fokus
zu behalten, das heißt, ähm, zweiter Weg Feedback
schleifen mit eingebundenem Feedback von Kunden
und, ähm, als nächstes wäre ja dann der dritte Weg, ne?
Ähm, wenn wir in Zukunft denken, dann wirklich Unternehmen zu haben,
die an einer Stelle lernen und andere Stellen im Unternehmen,
vielleicht auch Kunden und andere davon profitieren,
wo dann auch Dokumentation, Wissensmanagement und ähnliches
einen größeren Fokus bekommen wird.
Soweit meine Einschätzung.
Luca.
Ja, ich glaube, dem ist nichts hinzuzufügen.
Weg von, weg von Frameworks, weg von Dogmatismus hin zu Pragmatismus,
äh, ganz so, wie der Dirk das schon wunderbar gesagt hat.
Also, das ist, glaube ich, der einzige Weg, um der zunehmenden Vielfalt auch,
ne, wie gesagt, dem, dass, dass wir eigentlich die IT-Organisation hinter uns lassen
und uns auf den Gesa-, auf das gesamte Unternehmen begeben.
Das ist das Einzige, was hilft, dass man, dass man sich wirklich vergegenwärtigt,
wo wollen wir eigentlich hin?
Und dann ergibt sich häufig die, die Antwort auf die Frage,
was machen wir denn jetzt, äh, wesentlich leichter.
Ja, so, und, äh, wenn ich jetzt, äh, wir haben ja gerade eben so erzählt,
dass alle auf Falco gezeigt haben.
Also, natürlich gucken wir uns in die Augen hier auf den Bildschirm,
wenn wir diesen Podcast aufnehmen.
Und vielleicht sollten wir ja irgendwann mal auch, äh, das Video mitlaufen lassen.
Also, ähm, könnt ihr ja auch mal, ähm, kurz Rückmeldung geben.
Ähm, natürlich wird es immer den Podcast in einer, ich sag mal, nur Audio-Version geben.
Aber vielleicht machen wir auch noch mal wieder ein Streaming, äh,
dass wir ein Video mit aufnehmen.
Gucken wir mal.
Hatten wir, glaube ich, letztes Jahr irgendwann so ein-, zweimal auch mal gemacht.
Haben wir mal probiert, ja.
Auch, okay.
Sogar, sogar Live-Aufnahmen dann, das war ganz cool.
Ja, ja, bei, bei YouTube.
Also, insofern, ähm, wir haben unseren Spaß gehabt.
Ähm, ich, äh,
leite jetzt mal den, den Abgesang hier ein.
Wir haben unseren Spaß gehabt.
Und vielleicht kann man den Spaß aber nächstes Mal auch transportieren,
indem wir das Video zeigen, wie dann, ähm,
Falco da sitzt und nichts zu sagen weiß, weil alle auf ihn zeigen.
Oder umgekehrt, wer weiß.
Also, ich sage mal danke an meine beiden Kollegen hier
und freue mich über diese Folge und freue mich auf die nächste Folge.
Auf Wiedersehen.
Macht’s gut.
Macht’s gut.
Ciao.

Folge 60: Service management and ServiceNow with Steve Nixon [EN]

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In this episode we discuss service management in general and SeviceNow in particular with our guest Steve Nixon.

In this episode, Steve Nixon delves into the intricacies of ServiceNow, a pivotal tool in service management, emphasizing its alignment with ITIL practices and its vital role in modern IT operations. He explains how ServiceNow facilitates incident, problem, and change management, and its adaptability in handling DevOps and Agile methodologies. Nixon highlights the platform’s ability to integrate with various tools like Jira, enhancing operational efficiency. The discussion also covers the challenges and solutions in maintaining service operations and the evolving landscape of IT service management.

Inhalt

  • Steve Nixon’s Background and Role
  • Defining DevOps and Its Evolution
  • ServiceNow’s Role in Service Management
  • Challenges in DevOps and Service Management Integration
  • Handling Incident, Problem, and Change Management
  • ServiceNow’s Adaptability with Agile and DevOps
  • Integration with Other Tools (e.g., Jira, Dynatrace)
  • ServiceNow and ITIL Framework Compatibility
  • The Future of IT Service Management and DevOps
  • Closing Remarks and Contacts

Shownotes

Steve’s LinkedIn: https://www.linkedin.com/in/steve-nixon-9a24b3/
ServiceNow: https://www.servicenow.com/

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

Welcome to a new episode of DevOps auf die Ohren und ins Hirn, or in English, DevOps
from your ears straight to your brain.
Usually, this is a German-language podcast, but we sometimes make exceptions for international
guests.
Today is one such exception.
My name is Luca Ingianni, and I host this podcast together with my colleagues Dierk Söllner
and Falko Werner.
We are DevOps consultants, trainers, and coaches trying to get teams to work together better
and create better products for their customers.
Today, it’ll be Falco and me running the episode, and we are joined by Steve Nixon to talk to
us about ServiceNow.
Hi, Steve.
Very welcome to the show.
Hi there.
Thanks for having me.
Steve, who are you anyway?
So, I run as Head of Service Management, or Head of Service Operations.
So, I’m the guy who takes the incidents, the changes, the problems, and sees those
through, and DevOps people are usually my third line.
So, we have a first line, which is the help desk.
We have a second line, which takes scripts and generally works things.
And then we have the third line, which is support teams and stuff that’s going to take
a bit more in-depth knowledge and a bit more time to fix.
Which brings us to another fun question that we ask every guest who shows up on the show.
Steve, please tell us, what is your definition of DevOps?
So, DevOps to me, traditionally, we’ve had app dev teams.
Application development teams that are put together, they develop a product, they throw
it over the wall to support, and they disappear and disband and become somebody else again.
In this modern world, development doesn’t tend to finish.
We don’t do a lot of waterfall-type projects that finish and never update ever again.
We’re much more web-based, so development is agile, it’s ongoing, and the development
team…
becomes the operations team.
So, when something goes wrong with it, we phone the actual development team.
And because they’ve got the insight and the knowledge on how it’s built, they know how
to fix it, which is a lot easier than the app dev team that we used to deal with, which
are usually just given a huge load of documentation by the dev team, which may be very incomplete
and are left to just support the thing and usually can’t reach a developer because he’s
disappeared off to another project.
And how does it work for you?
Is it better than before or worse?
It’s better from my perspective.
When we reach out to people, to teams, and need them to join a call, the in-depth knowledge
that the development team brings to the incident generally resolves it quicker.
Where we do hit issues is where the development team have gone…
from a development with an app support team to a devops team.
They don’t necessarily realize that they’re going to get called at two o’clock in the morning
to fix an incident, and management aren’t very good at explaining this until it actually
happens.
They hand over their phone number freely until they get called, right?
Well, yes, and that’s part of being a third-line support team.
You have a designated person on call.
But it just doesn’t seem to register to people that on call means you’re going to get called
at some point.
Yeah, well, I mean, it is surprising, isn’t it?
You get told you’re on call and then people call you.
Yeah, well, the way that a lot of devops teams work in the organizations I’ve worked, they’ll
have a development team and then they’ll have a rotating area of support people.
So they’ve got a queue of incidents that my guys are sending them.
Those need fixing.
The customers need updating.
It’s not usually the most glamorous piece of work.
So they don’t generally allocate people to it full time, but they’ll have people switch
in to it.
So when they say they’re on call, they expect that that means we’ll get, if something goes
wrong during the day, we’ll be called into the bridge.
Yeah.
We’ll have to deal with it.
But sometimes we have the bridge at two o’clock in the morning because these apps on the web
are 24 seven.
And, you know, the organizations I’ve worked at are international organizations and there’s
people using them all the time.
So when they break, I get a phone call at two o’clock in the morning.
My team get on bridges at two o’clock in the morning.
We pull in who we need to fix it.
But wouldn’t it in that case also make sense to have a distributed support team so that
nobody gets called at two AM because it’s always like, uh, three in the afternoon someplace.
To a, to an extent.
I mean, I’ve worked in organizations that have people in Singapore, UK and America.
But what tends to happen is that they’re localized to their markets.
Um, cost saving initiatives generally put service management in one place.
How often does it happen that you need to resort to third line?
And support in the first case, do you escalate, I guess you’d not escalating anything because
then you’d just be a glorified like phone answering machine.
Um, but who gets to make that decision?
How is it made?
Um, how do you maybe talk about that afterwards?
Yes, that’s, that’s a reasonable question.
I mean, we have, um, service operations processes.
Generally, we want to fix as many things as we can at first line because we’ve got the
user on the phone.
They’ve.
They’ve got the problem.
If our staff can pick up the procedures, do whatever they need to do on the system and
get that user back up and running, that’s great.
Um, if it’s going to take a little bit more than they can or a little bit more in depth
or the, the manual, and I’m not joking here, the manual might be 80 pages long.
Um, we’ll hand that off to level two, which again falls in my remit.
It’s a team of people usually siloed across desktop network, telephony, data center, probably
a team specific to email.
Um, and they’ve got a lot more in depth, you know, specialist knowledge of those systems.
Um, so the call will go to them, but the user won’t, the user will be taken off the call
and told to expect a call back.
Um, and we’ve got SLAs around.
Those pieces that say that they’ve got to pick that call up from the queue within a
certain period of time.
They’ve got to put an update on the system.
Um, and they’ve got to get back in touch with the user in some way to give them an update
on what they’re doing.
Um, now as to the rough numbers, we try to fix around 60 to 80% of calls at first and
second line.
Um, depending on the organization.
Depending on the processes that we have, we try to fix the majority at first line,
but in a real world scenario, we probably get 50, 60% at first line.
Forgotten passwords and the like, I guess.
We’re trying to get away from password resets altogether, to be honest.
Um, yeah, fair enough.
The last three organizations I’ve worked at have had more and more, um, sort of secure
and robust methods of.
Yeah.
Self-service password reset.
And actually one of the things that the pandemic has achieved for us is the understanding
of people having two-factor authentication, um, self-service password reset has become
the norm.
We’re using mobile devices a lot more than we were.
Um, you know, every organization I’ve worked at used to be primarily desktop based.
It’s now primarily laptop based.
And that thought.
Along with the ubiquitous of mobile phones that goes along with it has generally taken
password resets out of the equation.
So, you know, it used to be 45% easily of the amount of calls that my help desk would get.
And the last place that I worked, we were down to eight or 9% a week were password resets.
So those eight or 9% were, were the, the complicated cases where the,
the self-service just broke down for some reason, right?
It was usually because the two-factor authentication got out of sync.
So actually we’re naming this podcast session, something about service now, where does that
fit in?
So service now is the management software that we use within service operations.
Um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
Zendesk, es könnte etwas sein, das sie intern gemacht haben, HP macht einen, es gibt viele von ihnen, aber ServiceNow ist auf jeden Fall der größte.
Und es ist auch nicht wirklich aus dem Versuch, etwas anderes zu sein, es wurde von der Grunde her gebaut, um ein Service-Management-System zu sein.
Oder wir haben, und was wir preferieren, ist, dass wenn man auf die interne Website geht,
wird da ein Button da sein, das sagt Login-Incident, und sie können da gehen und sie können nur ein paar Dinge über ihre Sachen schreiben.
Es werden Dropdowns geben, die sie ein bisschen mehr targetiert machen können, weil wir Freetext-Feels nicht mögen,
weil die User alle Art von Dingen schreiben werden.
Die Anzahl der Leute, die Probleme mit ihrem Monitor haben, wenn ihr PC nicht aufhört, ist sehr groß.
Also kriegen wir…
Ja, wir geben ihnen Dropdowns, wir geben ihnen Formen, die sie in die richtige Richtung führen,
und wenn jemand das inschreibt, wird das automatisch zu dem Team zurückgehen, das es am besten handeln muss.
Und das ist, warum wir diese Dinge benutzen.
Wenn ich zurückgehe zu den frühen Tagen in meiner Karriere,
alles ging auf die Helpdesk, und die Helpdesk logierte es manuell.
Das erste System, das ich jemals gearbeitet habe, war basiert auf einem
Mainframe, also mussten wir alle Green Screen Emulators benutzen, um auf den Mainframe zu loggen und die Tickets aufzunehmen.
Und es gab keine Dropdowns, es war alles Freetext, und die Helpdesk machte ihr Bestes, um die Informationen reinzunehmen,
und dann würde es auf die einzelne zweite Linie der Unterstützungsteam gehen, wo ich meine Karriere begonnen habe.
Und dann würden wir es aufnehmen und wir distribuierten es zwischen den paar Leuten, die wir in der Office hatten,
die verschiedene Spezialitäten hatten.
Und dann, wenn wir es brauchten,
gingen wir zu einer dritten Linie der Unterstützungsteam, einer App-Team,
und wir gingen literally nach unten mit der Anrufung und gingen mit ihnen sitzen und versuchen,
was da los war, und dann kamen wir zurück zum Benutzer.
Als die Dinge erhöht wurden und die Dinge ein bisschen mehr automatisch wurden,
macht ServiceNow viel davon, dass ein richtig formattierter Ticket mit der richtigen Informationen in ihm
zu einem von mehreren hundert Resolver-Gruppen korrekt gesendet kann.
So dass er nicht über die Systeme gespeichert werden muss, und das bekommt der Benutzer schneller gespeichert, was wir hier alles umfasst sind.
Es klingt also so, als wäre ServiceNow nur ein normaler Issue-Tracker, ein normaler Backtracker, nicht wahr?
Das ist also die Insidenz-Gruppe. Es trackt auch Problem-Tickets. Für diejenigen, die es nicht kennen, ist eine Insidenz etwas, was falsch ist.
Man kann nicht auf dein E-Mail loggen.
Dein PC fängt nicht an zu booten.
Dein Browser fängt an zu crashen.
Es macht dir ein echtes Problem, da und dann.
Ein Problem-Ticket ist etwas, das wahrscheinlich eine größere Anzahl von Leuten beeinflusst,
aber es schafft nicht, dass sie in ihrem Job nicht mehr arbeiten.
Wir haben wahrscheinlich einen Workaround, oder wir haben einen Patch im System,
den wir in der IT kennen, das ist keine gute Idee, aber es macht die Dinge funktionieren, damit das Geschäft weitergehen kann.
Also haben wir ein Problem-Ticket, um daran zu arbeiten.
Das dritte, was ServiceManagement-Tools tun, und ServiceNow im Wesentlichen, ist Veränderungsmanagement.
Alles in der Organisation muss kontrolliert werden, wo es Veränderungen gibt.
Wir bekommen Veränderungen aus dem Hintergrund von Problem-Tickets.
Die meisten Sachen, über die wir gesprochen haben, sind user-relevant.
Aber wenn wir ein ganzes System aufbauen, dann gibt es wahrscheinlich einen Patch dazu.
Oder es gibt einen Reboot des Systems.
Oder es gibt einen Reboot des Systems.
Oder es gibt einen Reboot des Systems.
Oder es gibt einen Reboot des Systems.
Oder es gibt einen Clickdown, die Veränderung der Rát
Es muss alles secret gespeichert und überprüft werden, bis die Unternehmen mit Fehlverordnung
sicher sind von dem, was wir tun.
ServiceManagement automatisiert all das.
weil sie ein Upstream-System haben, das intern ausgebildete E-Mails sendet.
Man muss einfach die Leute kennen lassen.
Und das ist das, was das Modul für Veränderungen macht.
Wenn man die Systeme einlädt,
hat man automatische Anschlüsse darauf, wer sich beeinflusst.
Und sie bekommen automatische E-Mails.
Und wo es notwendig ist, bekommen sie Anerkennungse-E-Mails.
Und der Veränderung geht nicht weiter,
bis man von allen hat, die es beurteilen müssen.
Das bedeutet einfach, dass alle informiert sind.
Und das andere, was es tut,
und nicht jede Organisation hat das noch nicht implementiert,
weil es ein großes Werkzeug ist,
aber es hat ein Konfigurations-System darin.
Und das verbindet sich in alle anderen Teile,
der Veränderung, der Problem, der Veränderung.
Also im Konfigurations-Management
trackst du nicht nur deine Hardware.
Du trackst die Netzwerke,
die mit den Systemen verbunden sind.
Du trackst die Applikationen, die darin sind.
Dann trackst du deine Bezeichnungsinformationen
zu diesen Applikationen.
Und wenn du die ganze Sache ausgebaut hast,
und es ist kein einfaches Job,
aber wenn es ausgebaut ist,
kannst du ein System auswählen
und all die Abstands- und Abstandsabhängigkeiten davon schauen.
Du kannst total kontrollieren,
was auf dieser Maschine läuft,
was auf der anderen Maschine läuft.
Welche Teams müssen beurteilt werden,
wenn etwas gebootet wird,
oder gepatcht oder geupgradiert wird.
Und das ganze Ganze kommt wieder rein.
Wenn du also einen Unfall auf etwas erzeugst,
hast du die richtigen Resolver-Teams
automatisch geupdatet.
Wenn du ein Veränderungs-Ticket erzeugst,
hast du die richtigen Support-Teams
und die richtigen Business-Teams automatisch geupdatet.
Und das macht unsere Leben einfach viel einfacher.
Wie wird das mit cloud-basierten Systemen verbunden?
Wie mit skalierbaren, container-basierten Systemen?
ServiceNow folgt einer Infrastruktur,
ich versuche, die richtigen Wörter zu finden,
einer Prozesse, die ITIL heißt.
ITIL hat verschiedene Iterationen durchgeführt.
Wir sind jetzt bei ITIL 2.0.
ITIL Version 4.
Und ServiceNow hat geupgradiert,
als ITIL gekommen ist.
ITIL Version 4 gibt spezifisch Prozesse
und Wege, um mit Cloud zu handeln.
Wir haben mit ITIL Version 3 angefangen,
mit Virtualisierung.
Du hättest also eine Maschine,
und dort hättest du 200 VMs.
Und innerhalb der Config-Management-Database
hättest du die Möglichkeit,
die VMs an einem bestimmten Zeitpunkt zurückzuholen.
Sie arbeiten mit den Verbrauchern,
um sicherzustellen, dass, wenn VMs für Load-Balancing umgehen,
alles in der Config-Management-Database geupdatet wird.
Als sie in Cloud-basiert sind,
dauerte es eine Weile, bis ITIL Version 4 aufgekommen ist
und Prozesse umgesetzt wurde.
Aber ServiceManagement-Tools,
ServiceNow im Wesentlichen,
haben Module, die in die Hauptplattform hüpfen.
Google, Azure, Amazon.
Wir können in ihre Management-Console hüpfen
und die Informationen zurückbekommen,
die wir brauchen.
Die Informationen, die wir von dort bekommen,
sind bemerkenswert.
Du wirst nicht wissen,
welches Prozessor es läuft,
welche Erinnerung es läuft.
All diese Sachen.
Wir haben keine Ahnung,
um ehrlich zu sein.
Wir behandeln sie nur als Virtual Machines.
Und wir haben bereits Wege,
mit Virtual Machines zu handeln,
auch wenn sie im On-Premium sind.
Wir sind jetzt nur in der Cloud.
Und in ServiceManagement
liaisieren wir mit den Cloud-Providern
extrem nahe.
Also, wenn sie irgendwelche
Backend-Infrastruktur-Upgrades machen,
werden sie uns wissen,
es sollte nachhaltig sein.
Sie sollten Load-Balance
über die Dinge,
die sie nicht updaten.
Aber sie lassen uns sowieso wissen.
So haben wir,
wenn etwas um 3 Uhr morgens kommt,
eine sehr gute Idee,
warum.
Das klingt sehr interessant.
Ich war nicht sicher,
dass es so viele
Verbindungen gibt
zu den verschiedenen Cloud-Providern
und direkt
diese zu Service-Management-Systemen
hüpfen können,
in dem Fall,
was wir hier über Service-Now sprechen.
Es ist also gut,
das zu hören und
versuchen zu verstehen,
was die Vorteile sind.
Es kann noch besser werden.
Eine der Firmen,
mit denen ich ein paar Mal gearbeitet habe,
ist eine Firma namens Dynatrace.
Aber es gibt auch andere Firmen,
die ähnlich machen.
Sie können dir
eine holistische Sicht
deines App-Stacks zeigen.
Es ist egal,
ob es Cloud, Container,
virtuell oder physisch ist.
Es gibt einfach
kleine Teile des Codes,
die in den Code
eingebunden werden.
Du arbeitest mit den Dev-Teams,
um das einzusetzen.
Und das ganze
hüpft zurück.
Das Dynatrace-Modul
monitoriert
den Traffic,
der zwischen den Dingen
geht,
alle Verbindungen
zwischen
Applikationen.
Es weiß,
was normal ist.
Deshalb kann es
Abnormalitäten beurteilen.
Und Dynatrace kann automatisch
die Tickets in ServiceNow
aufbauen,
um sie zu den Teams zu bringen,
oft bevor sie realisieren,
dass es ein Problem gibt.
Das klingt wie Magie.
Es ist teure Magie.
Aber es ist.
Es ist Magie.
Ist Magie immer teuer?
Du musst etwas bezahlen.
Entweder musst du studieren
und es in Hogwarts lernen,
oder du musst
die Wunde kaufen.
Und diese Zeit,
ja,
ist Dynatrace
eine
IT-Magie-Wunde.
Ja,
tatsächlich.
Wenn ich
über
Servicemanagement
denke,
hast du
über
Helpdesk
gesprochen
und
mehrere
Niveaus
der Unterstützung
ähm
Problem
und
Incident-Management
und
Change-Management
und
Configuration-Management
um
wie
ähm
Availability-Management ähm
ähm
Dinge wie äh
Kapazitätsmanagement und ähm
Ähm
Verbesserung
Teil davon
es ist
es ist alles
in der Art
der Art der Service
jetzt funktioniert
es gibt Module für
all diese Dinge
es ist einfach
abhängig, wo eine
Firma ist
auf ihrer Reise durch
Servicemanagement
in Bezug auf
wo diese Dinge sind
es dauert
eine sehr lange Zeit
und viel Arbeit
um Konfigurationen zu erstellen
um Konfigurationen zu erstellen
der nächste offizielle Schritt danach ist
Lizenzmanagement
auf der Rückseite
kann man
Availability-Management bekommen
Kapazitätsmanagement
tendiert
parallel
an einem bestimmten Punkt
zu laufen
ich habe
ähm
meinen ersten
echten
Kontraktjob
lange
zurück
in
ich weiß nicht
2007
war eine
Kapazitätsmanagement-Rolle
Kapazitätsmanagement für
eine
Bankenorganisation
und
wir haben das
ziemlich manuell gemacht
wir mussten
die Konfigurations-Management-Sache
immer noch bauen
aber es war
sehr
grundlegend
wir konzentrierten uns
auf Server
nicht auf Desktop
und wir haben nur
die Informationen
die wir brauchten
aber auf der Rückseite
dieser
Arbeit
sahen die Teams
mit denen wir
gearbeitet haben
den Vorteil davon
und diese Organisation
ging auf
eine volle
CMDB
und als ich
weggegangen bin
machten sie
das ganze
ein
Baublock
das eine
das
scheint
im Moment
die Bewegung
von
Change Management
zu
Release Management
viele
Dev-Teams
hüpfen
in
deine
DevOps-Konversation
ich glaube
das
das
Hauptproblem
mit
Dev-Teams
ist
dass sie
versuchen
den
Change-Management-Prozess
zu vermeiden
und das
ist
eine
typische Organisation
die
erwartet,
dass du
deinen
Veränderung
ein paar Tage
vor dem
Zeitpunkt
erwartet wirst
du erwarten,
dass du
es
erwartest
es wird
eine
Anzahl von
Anleitungen
spezifisch
zu dieser Veränderung
und
es wird
generell
ein Veränderungs-Board
sitzen
und durch diese Veränderungen
wird es
nicht möglich
dass
du
den
Veränderungs-Board
auf
einer
Anleitung
auf
einer
Anleitung
auf
einer
Anleitung
ein
Veränderungs-Board
auf
einer
Anleitung
auf
einer
Anleitung
auf
einer
Anleitung
auf
einer Anleitung
auf
einer Anleitung
unter
einer hardened
ist
ich
Consumer
Services
uschrift
das habe
situations
wagen
wahnsinnig
enrichiert
ähnliche
alerts
die
er
er
Albs
die
solche
die
sociale
jetzt
degree of flexibility in a rigorous change management process so in
organizations that are doing that service now has a module that does
release management and there you can put in standard releases standard things
that are going to be done and get pre approval you can get a schedule and
understanding and the system will know when these things are going on and alert
accordingly if anything goes wrong but they don’t have to go through the
formality of a change management process and a change board which you know we’ve
had a joke within service management for years dev teams calling themselves agile
just means they want to avoid the change management process they just carry on
working exactly the same as they were but you know now they’re agile they
don’t need to do change management okay but then in fact they do right of course
you’re right but then in fact they do right of course
they have to do it in somehow in some way the worst thing that they can get is
being called it to ignite yeah well it this this organization I worked at a few
years ago that was very very web-based major website that’s where all the
traffic was driven through they they did one of these release without change
management processes just a simple change and they in in the process they
excluded ie6 from working because they
they’ve done all their due diligence there was less than two percent of their
user base across thousands and thousands of hits that were using ie6 so so well
we’ll just take the hit on them they could see from their data that they
weren’t actually generating a lot of sales they were just doing searches and
utilizing the system because they hadn’t informed us and we didn’t have a change
management board and we didn’t listen to them and talk to the others
What they didn’t realize was that 2% was the stores.
We had IE6 still on the Citrix version that the stores were using.
And the customers would go into the stores, sit at the desk, talking to the person.
And on a Thursday morning, it just stopped dead.
Fantastic.
So within the service management and the operations piece,
we had to scramble to get Google Chrome put onto the Citrix piece.
And then I went into town on a Saturday morning because we put the change live on a Friday night.
And I went into town on a Saturday morning into one of these stores and just said,
is it working today?
And they were like,
And they said, also that was you, wasn’t it?
Well, they’d understood what was going on by that point.
They’d had a nice couple of days.
A couple of days just sitting around drinking tea and chatting.
Ah, so actually they were quite happy with you, weren’t they?
Yes.
But you know, it’s those sort of things that when people are outside of the change process,
it does have knock-on effects sometimes.
And 99% of the time they can make the changes and do their A-B testing and it’ll have no effect whatsoever.
But if we’re not aware,
it can have…
It can have unforeseen fallout.
And that’s why we’re moving for teams like that from change management to release management so that we can work with them to get a schedule of what they’re doing and understanding of the timings of when they’re doing it and they can get a system that they can work with that doesn’t shoehorn them into weekly change board meetings and unnecessary to them delay.
That brings me to an interesting point.
Because the reason I invited you on this podcast was that I came across a remark of yours where somebody was complaining about the service management processes and you kind of quipped,
well, looks like your ServiceNow instance has just been bent to a process.
And I found that really interesting.
What do you mean by this?
So when you go to a service management tool,
you’ve generally come from…
something else.
You know,
you’ll have had a help desk for years.
And, you know,
in my instance that I mentioned earlier,
where we used to have a mainframe
and, you know,
we literally had a guy in the office that would print out the tickets in the morning
and you’d walk around with a stack of papers
fixing those things.
If you take what we were doing there
and then try and get it
to the point where you’re…
you’ve got a service management tool,
if you don’t change your way of working,
to the way the service management tool works,
but you try and make the service management tool work the way you do,
it’s not going to go well.
For a more concrete example,
the change management process
at a very large organization that I’d worked with,
before ServiceNow came along,
they had this concept of standard changes.
And you didn’t need approval for a standard change.
But they were generally…
thought of as small, understandable changes.
They put that into ServiceNow.
Now, ServiceNow, in the change management piece,
has approval built in.
That’s the way it works.
That’s the way change management works.
But they modified the code
in such a way that they could have this concept of a standard change
that would then bypass all the approval.
And the daft thing about it was
the engineer raising the change,
was the one that made the classification
as to whether it was standard or non-standard.
And there was an instance of the engineer
making a standard change
that knocked out the entirety
of the booking system for a large British airline
for an entire weekend.
And nobody knew that it was going on
because it was a standard change.
Until it happened.
That is kind of what I meant.
I can’t remember what the exact instance was,
what the comment was,
but it was something that they were saying
was just counter to the way ServiceNow works.
And I’ve seen it in so many organizations
where the teams in existence have a process
and here comes this new tool,
but they don’t want to change the process.
But aren’t they right to say,
look, we have a system that works for us.
Maybe ServiceNow is not the right tool for us.
Maybe we should go with, you know,
something else.
But should you really bend your process to ServiceNow
or shouldn’t it rather be the other way around?
So from my perspective on that,
if your process doesn’t fit with ServiceNow,
it’s probably wrong.
Because ServiceNow is built to the ITIL foundation,
you know, the ITIL framework.
The ITIL framework has been built up
by service management professionals.
Over many, many years.
The processes within that on how to deal with an incident,
how to deal with problem, how to deal with change,
have been embedded and, you know, forged in fire
over many, many years.
If your organization gets a tool that does things that way
and you go, nah, we do it this way.
You’re probably wrong.
Fair enough.
So in that sense, you can say that ServiceNow,
is opinionated enough, if I hear you right,
to sort of serve as this expression of this body of knowledge
and not just as a business process automation engine.
Yeah, to an extent.
I’m just trying to, I’ve got slightly distracted
because I’m looking at what they were saying.
Yeah.
So in the original thread that we were looking at,
they’d said that the process owners were annoyed
that he filled in a form instead of watching a training video
to find out where the secret hidden questions were.
And that is exactly the sort of thing that I’ve seen.
In ServiceNow, they’ll take a form
that was in their original way of doing things
and it’ll have all sorts of esoteric questions.
And, you know, if you use ServiceNow properly,
you go onto an incident or a service request form,
and you’ll start filling in the information you want.
The first few things you’ll get will be drop-downs
because that allows you to tailor
what questions you need to ask the person.
But the amount of times that I’ve seen it where they don’t do that
and they leave free text information in,
and if you don’t type in exactly the right thing
that the person who created the catalogue
thought you were going to do,
it doesn’t give you the options that you need to fill in
to actually get your request.
I mean, we haven’t really touched on service requests,
but that’s just a slightly different side of service management.
You know, we deal with incident problem,
which is where something’s broken,
but we deal with service requests as well,
which is if you need something.
If you need a user creating,
you need access to a printer,
you need a new laptop.
The big one in that is obviously
the new joiners, new leavers process,
which will kick off hundreds of jobs to different teams
if it’s set up right
to make sure that, you know,
when the person walks in the door on day one,
they’ve got a laptop, they’ve got a phone,
they’ve got their email set up
and all that sort of stuff.
All that’s run through ServiceNow and service request modules.
And it certainly sounds like on the one we were reading
that they’d gone through a basic service request
process that hadn’t been set up right.
And there were hidden fields and hidden stuff
that if you didn’t type exactly the right keywords,
you wouldn’t get them.
And therefore you would never get your request actually acknowledged.
That sounds kind of like an escape room.
To a certain extent it can be, yes.
But it’s more like one of those really annoying crawler dungeons
that we used to play on text screens,
back in the day.
You know, you type…
You’re in a tasty maze of passages.
That’s it, exactly.
All alike.
Yeah.
Turn left.
I don’t know how to turn.
Walk left.
Ah, yeah.
I now walk left.
And if you don’t type exactly the right thing,
it’s not going to work.
But, you know, when these things are set up properly,
you should, as I say,
you should have a number of dropdowns at the top
that allow us
to tailor the form
to ask exactly what you want.
Because it doesn’t help anybody
that if you’ve got a service request coming through
or an incident that goes to the wrong team,
all that does is put a delay in.
And it doesn’t make anybody happy.
As we’ve listened to you talk,
I was wondering, you know,
you are pretty much in favor of announcing your intentions in advance,
of, you know, making changes known in advance,
of…
asking for approval for a change to go through, et cetera, et cetera.
Yes.
Isn’t that sort of really contrary to Agile,
where you just sort of try it out and see if it works?
And then if, you know,
if all of the shops in all of Britain suddenly fail,
then oops, let’s maybe roll back.
So I guess what I’m getting at is
that sounds a little more restrictive
than the average developer would enjoy these days.
So there’s two sides of it.
I mean,
a lot of change management processes
are based around infrastructure changes,
things that aren’t time critical,
but need to be done.
So, you know, every Tuesday,
the first Tuesday of the month,
we get the latest Microsoft patches.
Some of those might be critical
and need to go out quite quickly.
We get patches on networking equipment.
We get upgrades on stuff that need to be done.
And all of those things can change.
So we generally go through
a normal change management process,
because you’re not really running
to get those things in ASAP,
like this afternoon.
You can wait a couple of days and get those in.
Where we have a high priority incident,
where something’s gone wrong,
or we’ve got something that’s come along,
like that one that came along and did the…
Log4j.
Log4j, yeah, that’s what I’m thinking of, yes.
That was quite critical.
Yeah, sounded like it.
And the change management process
has two things that we can do.
We can either do a urgent change
or an emergency change.
And those things just massively reduce
the amount of time needed
and the amount of approval needed.
And in the case of a high priority incident,
we may reboot and raise
a retrospective emergency change later.
To cover the fact that we did something.
In the case of developers,
there’s two sides of it.
A lot of them do know
when they’re going to do something.
They’ll be working towards a release,
or they’ll be working towards something specific.
And they can schedule that one in.
And the change management process is flexible enough
that if it moves or shifts a couple of weeks,
we can deal with that.
Where you’ve got the stuff
that we’ve been talking about previously,
the change management doesn’t really lend itself to it.
And that’s what I was mentioning earlier
with the release management module.
ServiceNow have realized,
like they’re moving to cloud infrastructure,
they’re realizing that developers
aren’t doing big bucket release.
They’re doing minor changes,
things that are constantly ongoing.
And with the release management module,
you can manage that sort of information.
The developers work with us,
and we get the right information in there,
and we get the right level of understanding.
It’s not so much trying to shoehorn the developers
and get them to follow our process.
It’s more making everybody aware of what’s going on.
Service management is that at its heart.
If we know what’s going on in an organization
and something goes wrong,
we know who to call.
If you’ve got developers just throwing stuff onto the servers
and trying what they like,
and then we start getting users calling in
to say something’s broken,
if we don’t know what’s going on,
it’s going to take us a lot longer
to get the right people on the call.
And developers with the best will in the world
don’t always have the information at their fingertips
that something’s not working.
How good is it possible to integrate this
either change or release management process
into automated processes developers like to use,
like continuous delivery pipelines
in one or the other way?
So the release management module within ServiceNow
hooks into the major players of that thing.
So that’s what I mean when I say
we work with the developers to get a flow
that works for them,
so that we’re aware of what’s going on,
the system is aware of what’s going on,
so that we can update the CMDB
and therefore all the dependencies within the organization,
but they still work within their tool.
A flip side of that, one that I’m very au fait with,
when we raise a ticket
that goes off to a third party app dev team,
it will quite often automatically
raise that ticket in Jira.
Mhm.
And Jira will automatically update
the ticket in ServiceNow.
So the developer doesn’t ever need
to go into the ServiceNow ticket to update it.
They can live in Jira and keep their workflow going
and they can get their bug ticket raised
and they can do all their development
and hook the patch back into their system
and the updates feedback seamlessly to ServiceNow.
When they close the Jira ticket,
it triggers into the service
into the ServiceNow ticket
to let the user know that update’s been done
and we’ll put it into a resolve state
and then the user will get three days to confirm
and then it’ll close the ticket.
So with something like that,
the app dev team or the DevOps team
is never going anywhere near ServiceNow.
They’re living in Jira,
which is where they want to live.
And for release management,
it’s very, very similar.
They’ll live within their tool,
but that tool will talk to ServiceNow.
It will raise the relevant tickets
or the relevant announcements that we need
and everybody will be happy.
All right.
Are those connectors to the different tools
part of the ServiceNow ecosystem?
Are they developed in each of those surrounding systems
or is there some kind of,
I don’t know,
service bus or central connector
that you support or you would, yeah.
Yeah, I mean, there’s two ways you can do it.
In the first case
and the one that you default to if possible,
they’ve generally worked
with the other third party organization
to provide the connector.
So if you hook into Jira,
like I just said,
they’ve worked with Confluence.
So there is an official connector
that talks from ServiceNow to Jira and back again.
But if you’re talking to something
that doesn’t have connectivity between systems
through an official connector,
then there’s an API.
And at the very worst,
you can just call HTTP
and just talk directly to the calls
on the backend system.
Excellent.
So I’m kind of running out of questions here.
Steve, is there a question
that you think I should have asked,
but somehow didn’t?
I don’t think so.
I think we’ve covered off
the vast majority of what we do.
I mean, you know,
service management isn’t this magical black box
where things happen.
It’s just that bit of IT
that everybody uses
when things go wrong
or when they want something.
Kind of like the glue that holds things together?
It is indeed, yes.
Okay, wonderful.
In that case,
I guess we can safely wrap up the show.
So any final words,
anything you would like to tell the listeners, Steve,
before we send you off?
Only if they need
a new head of service management,
give me a call.
Oh, yes.
So, dear listeners,
if you are in need
of a new head of service management,
reach out to us
and we’ll get you in touch with Steve.
And I suppose, Steve,
you can be easily found on LinkedIn
and all of these places, right?
I can indeed, yes.
Okay, wonderful.
So, Steve,
thank you so much
for taking the time to talk to us today.
This was really interesting
and very enjoyable.
Thank you.
Thank you very much
and enjoy your weekend.
Yeah, you too.
Ciao, instincts.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.

Folge 61: Behaviour Driven Development

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Luca und Falko besprechen Behaviour Driven Development (BDD), eine Technik zum Erstellen automatisiert testbarer Spezifikationen — testgetriebene Entwicklung auf Feature-Ebene.

In dieser Folge des Podcasts wird das Konzept des Behavior-Driven Development (BDD) detailliert erörtert. Die Diskussion umfasst die Grundlagen von BDD, seine Rolle in der Softwareentwicklung, die Verbindung zur DevOps-Philosophie und die Herausforderungen bei der Implementierung von BDD in Teams. Es wird betont, wie BDD zur Verbesserung der Kommunikation zwischen Entwicklern, Testern und Fachexperten beiträgt und wie es in verschiedenen Testebenen, einschließlich Unit-Tests und Systemtests, angewendet wird. Zudem werden praxisnahe Beispiele und Tipps für die effektive Anwendung von BDD sowie die Integration in vorhandene Entwicklungsumgebungen und Tools besprochen.

Inhalt

  • Einführung in Behavior-Driven Development (BDD)
  • Verbindung von BDD und DevOps
  • Die Rolle von BDD in der Softwareentwicklung
  • Herausforderungen bei der Implementierung von BDD
  • Kommunikationsverbesserung durch BDD
  • Anwendung von BDD in verschiedenen Testebenen
  • Praktische Beispiele für den Einsatz von BDD
  • Integration von BDD in Entwicklungsumgebungen und Tools
  • Best Practices und Tipps für die effektive Nutzung von BDD

Shownotes

https://en.wikipedia.org/wiki/Behavior-driven_development

Gojko Adzic, „Specification by Example“, ISBN 978-1617290084

https://cucumber.io/docs/gherkin/

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

DevOps – auf die Ohren und ins Hirn
Ein Podcast rund um DevOps
Von Dierk Söllner, Falko Werner und Luca Ingianni
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts
DevOps – auf die Ohren und ins Hirn
Gestaltet und produziert von Luca Ingianni, Dierk Söllner und mir, Falko Werner
Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung
DevOps umfasst für uns kulturelle, organisatorische und technische Aspekte
Wir freuen uns heute, das Thema Behavior-Driven Development mit euch zu besprechen
und wollen es von verschiedenen Seiten beleuchten
Dabei sollt ihr herausfinden, wie ihr Behavior-Driven Development nutzen und einsetzen könnt
und was der Zusammenhang zu DevOps ist
Zu Gast haben wir heute einen der üblichen Hosts, Luca Ingiarni
Er ist Berater
und Coach in allen Bereichen, die mit DevOps und Agilität zu tun haben
Lieber Luca, wir haben in diesem Podcast die Tradition, die du auch kennst
all unsere Gäste nach ihrer persönlichen Definition von DevOps zu fragen
Du hast das schon ein, zwei Mal gemacht
Nichtsdestotrotz, was ist deine Definition von DevOps?
Ach Gott, ich hoffe, jetzt fühlt sich keiner der Hörer bemüßigt nachzuschauen
was ich die letzten Male so erzählt habe
weil das widerspricht sich dann wahrscheinlich
weil auch meine Definition von DevOps, glaube ich
entwickelt sich im Laufe der Zeit irgendwie weiter
Also da, wo ich momentan angekommen bin, ist halt, dass es eine Weiterentwicklung der Agilität ist
dass es die Verbindung von Agilität ist mit Technologie
mit dem Ziel, noch mehr Feedback-Schleifen zu bauen
mit dem Ziel, noch größere Bereiche des Wertstroms zu überdecken
und noch mehr Leuten dabei zu helfen, gute Produkte zu bauen
Okay, vielen Dank
Dann lass uns mal ein Stück in das Thema Behavior-Driven Development einsteigen
Was ist die grundlegende Problemstellung, die man hat, wenn man sich mit dem Thema auseinandersetzen will?
Die grundlegende Problemstellung ist vielleicht die
dass man sich wünscht, automatisierte Tests zu haben auf funktionaler Ebene
Das heißt, auf der Ebene dessen, welches Verhalten man sich eigentlich wünscht von seinem Produkt
Man kennt ja automatisierte Tests, zum Beispiel von Test-Driven Development, von Unit-Tests oder sowas
die auf sehr, sehr niedriger Ebene sind
die nur einzelne Fragmente eines Produktes untersuchen
und dasselbe aber auf wirklich hoher Ebene zu tun
auf Ebene des Gesamtproduktes zu tun
oder nennenswert großer Blöcke davon
Das ist wesentlich verzwickter und wesentlich weniger üblich
Da ist man ganz häufig noch in der Gegend, wo dann auch manuelle Tests gemacht werden
Na, weil da ist man dann in Richtung Benutzerschnittstelle unterwegs
Da ist man in Richtung von wirklich, im Zweifelsfall auch sehr komplexen Gesamtsystemen unterwegs
Und BDD ist ein Weg, um eben automatisierte Tests auf funktionaler Ebene möglich zu machen
Und das heißt gleichzeitig auch, das ist nämlich ganz verrückt
Das ist ja auch eine Art, Spezifikationen zu schreiben
Also wer vielleicht das klassische V-Modell kennt
Wo man den linken Ast dieses Vs hat
Wo man von Grobspezifikationen, Feilspezifikationen sich runterarbeitet
Bis hin zum Entwickeln, zum Coden
Und dann auf dem rechten Ast wieder hochmarschiert
Zu immer großräumigeren Tests
Unit-Tests, Teilsystem-Tests, System-Tests, Funktional-Tests und so
Und BDD sitzt auf beiden Zweigen von diesem V
Das ist eine ganz lustige Besonderheit
Das ist nämlich
Die anderen Bezeichnungen für
Oder eine andere Bezeichnung für BDD ist zum Beispiel
Specification by Example
Also Spezifikationen verfassen dadurch, dass man konkrete Beispiele gibt
Klammer auf
Und dann hat man dann auch noch eine andere Bezeichnung für BDD
Und dann diese Beispiele direkt als Testfälle verwendet und die durchtestet
Klammer zu
Das heißt letztendlich
BDD ist, wenn man sich mal die Testpyramide, so MyCone im Hinterkopf anschaut
Relativ hoch angesiedelt, wie du gesagt hast
Wie viele Tests auf der Ebene führt man dann normalerweise aus?
Ich habe immer so im Hinterkopf
Je weiter unten, desto mehr
Je weiter oben, desto weniger
Ja, das ist in diesem Fall natürlich auch so
Einfach deshalb, weil
Weil diese Tests von ihrer Natur her ein bisschen aufwendiger sind
Oder sogar viel aufwendiger sind
In der Errichtung
Die brauchen teilweise auch sehr lange, um abzulaufen
Ein Unit-Test per Definition hat ja keinerlei Seiteneffekte
Das ist die Definition eines reinen Unit-Tests
Dass der nur innerhalb dieser einen Funktion irgendwie rumsaust
Und wenn du das machst, ist eine Millisekunde natürlich eine sehr lange Zeit
Wohingegen
So ein funktionaler Test, der
Greift dann vielleicht sogar auf entfernte Dienste zu
Von Dritten oder sowas
Also das kann schon mal sein
Dass der im Zweifelsfall auch ein paar Minuten braucht
Bis der endlich mal durch ist
Wenn der irgendwas richtig Kompliziertes macht
Das kann schon sein
Die Frage ist ja auch immer
Und das ist die Kunst eines guten Testmanagers
Wie komme ich an das Vertrauensniveau für mein Produkt hin, das ich brauche
Und der Extremfall, den ich mal hatte, war
Wir hatten nur einen einzigen BDD-Test
Das war also
Wenn man böse ist, kann man sagen
Das war ein Small-Test-Test
Aber allein dieser eine war so machtvoll
Einfach um für uns selber fortwährend nachzuweisen
Ganz grundlegend
Unser System lebt noch
Und wir hätten dann
Natürlich auch noch mehr andere Tests dran häkeln können
Aber das haben wir dann gar nicht so als notwendig empfunden
In dem speziellen Fall
Das haben wir auf anderen Testebenen abgefrühstückt
Und eigentlich hat dieser eine Test dazu gedient
Zu verifizieren
Ja, die anderen Testebenen, die lügen uns nicht an
Sondern die erzählen weiterhin die Wahrheit
Wenn wir, das war eine Maschine
Wenn wir der Maschine
Wenn wir die Maschine kommandieren
Zu sagen, fahr auf diese Koordinaten
Dann fährt die da auch ganz tatsächlich physisch hin
Wir haben das dann nachgewiesen
Mit einem kleinen Tasterle
Ist die Maschine dann dagegen gefahren
Und dann haben wir gesagt, wunderbar
Das Gesamtsystem
Maschine von oben bis unten
Und letzten Endes sogar unser Test-Framework
Funktioniert noch
Und das war alles, was wir brauchten an der Stelle
Okay
Wir haben jetzt gerade so ein bisschen die Problemstellung beleuchtet
Ich würde zum nächsten Thema übergehen
Und zwar BDD
Was ist es überhaupt?
So ein bisschen angerissen hast es
Wollen wir das Ganze noch ein bisschen vertiefen?
Na klar, genau
Also, ich habe ja gesagt
Es sitzt so zwischen den Stühlen
Zwischen Spezifikation und Testen
Und zwar in der Form
Dass ich da
Natürlichsprachige Spezifikationen verfasse
Typischerweise in einer bestimmten Syntax
Die so ein bisschen
Sogenannte Gherkin-Syntax
Die ist eigentlich völlig harmlos
Das ist jetzt also keine irgendwie abgefahrene Syntax
Sondern der Kennzeichner für die ist eigentlich nur
Dass die Sätze mit
Einem von drei Wörtern anfangen
Nämlich given, when oder then
Das war’s
Da gibt es noch ein paar Sonderlocken
Aber das ist jetzt mal so die Grundlage
Und das war alles
Das sind also wirklich natürlichsprachige Sätze
Und die Idee dahinter ist, dass auch ein
Nicht-Tester
Ein Nicht-Software-Entwickler
Ein Fachexperte in der Lage ist
Das zu lesen und zu verstehen und zu sagen
Ja, dieses Verhalten des Systems
Das hier beschrieben ist
Das ist das, was ich mir wünsche
So, das ist das eine
Und das andere ist
Jetzt möchte ich die ja automatisiert ausführbar machen
Das muss ich also irgendwie die Brücke schlagen
Von diesen natürlichsprachigen Spezifikationen
Hin zu einer automatisierten Testausführung
Und um gleich alle vorweg zu beruhigen
Also da kommt jetzt keine KI
Die versucht englische Sätze in Testcode umzuwandeln
Sondern an der Stelle muss dann schon ein
Testcode umgewandelt werden
Menschlicher Tester eben tatsächlich
Testcode verfassen
Und was ein BDD
Engine
Dann macht, ist, dass sie
Ein Mapping durchführt
Wenn ich diesen natürlichsprachigen Satz lese
Dann verstehe ich daraus
Aha, ich muss folgende
Ruby-Funktion, Python-Funktion
Wie auch immer du deine Tests konkret implementierst
Ausführen
Und dann
Und auf diese Weise bekomme ich dann meine automatisierten Tests
Mhm
Also letztendlich das, was auch ein
Tester, der das händisch machen würde
Eine Art von Skript hat
Auch tun würde
Das stimmt, genau
Und was ist dann der Unterschied zu
Akzeptanztests?
Der Unterschied ist eigentlich
Nur einer in der
Im Testgegenstand
Grundsätzlich
Macht BDD halt
Automatisiert
Automatisierte Tests
Auf funktionaler Ebene
Das können auch Akzeptanztests sein
Ein funktionaler Test heißt ja einfach nur
Ich mach was, was
Die Funktion
Das Verhalten
Meines eigentlichen Produkts beobachtet
Und das kann ja durchaus auch ein Akzeptanztest sein
Dass ich sage, also
Damit ich dieses Produkt als irgendwie
Gelungen akzeptiere
Muss es folgende
Verhalten vorweisen
Und das kann ich ja als BDD-Test formulieren
Also
In dem Sinne Akzeptanztest ist halt ein Sonderfall
Eine besondere Sichtweise, wenn man so will
Auf funktionale Tests
Das ist alles
Man kann das mit BDD
Ansätzen automatisiert machen
Und häufig kenne ich Akzeptanztests
Zumindest in vielen Umfeldern
Dass sie durch zum Beispiel User
Als User Acceptance Test
Zum Beispiel umgesetzt werden
Und häufig noch manuell stattfinden
Genau
Und du kannst ja da
Das Ding einfach umdrehen
Und kannst sagen
Ich setze mich nicht erst mit meinen Fachexperten zusammen
Wenn das Produkt fertig gemacht ist
Sondern ich setze mich mit ihm im Vorfeld hin
Und dann soll er mir mal einfach erzählen
Was erwartet er denn
Was will er denn sehen von diesem System
Dass er sagt, so passt mir das
Und dann schreiben wir das
In dieser Gökken-Syntax hin
Und dann haben wir einen fertigen Testfall
Den können wir zu jedem Zeitpunkt
Neben dieses System halten
Und sagen, gefällt uns was wir sehen
Sind die Tests schon grün
Das heißt wir können Akzeptanztests
Auch dann machen
Wenn wir kurz vorm Release stehen
Und der Fachexperte vielleicht im Urlaub
Oder im Wochenende
Oder an anderer Stelle ist
Und machen uns damit ein Stück unabhängiger
Ja, das ist richtig
Du gewinnst halt ganz grundsätzlich
All die Vorteile, die du aus automatisierten Tests hast
Genauso wie du sagst
Man gewinnt diese Unabhängigkeit
Man gewinnt sicherlich Geschwindigkeit
Man gewinnt auch die Wiederholbarkeit
Ich muss den jetzt nicht ständig irgendwie neu piesacken
Und sagen, hier probier nochmal, probier nochmal
Geht’s jetzt und so
Sondern zu jedem Zeitpunkt während der Entwicklung
Kann ich einfach meine BDD-Test-Suite laufen lassen
Und kann mich selber vergewissern
Geht noch alles
Oder habe ich jetzt versehentlich irgendwo anders was kaputt gemacht
Zum Beispiel
Aber ich habe auch in der Umkehrung
Den schönen Vorteil, ich weiß genau wann ich fertig bin
Weil hier habe ich eine Liste von Akzeptanztests
Die sind schon
Im Vorab
Diskutiert, abgestimmt
Und dann kann ich einfach sagen, sobald die alle grün werden
Bin ich fertig
Mit dieser Funktion
Das ist also
Ein
Form des Shift-Lefts
Dinge frühzeitig zu tun, die man
Sonst im, ich sag jetzt mal
Klassischeren Vorgehensweisen
V-Modell, Wasserfall oder Co
Erst später, vielleicht sogar manuell
Gemacht hätte, wiederholbar
Automatisiert und von dem
Letztendlich auch frühzeitig
Mit dem Thema zu befassen
Genau so ist es
Und auch ansonsten kriegst du ja all die schönen Vorteile
Die du aus Automatisierung kriegst
Zum Beispiel diese Verschriftlichung
Das ist jetzt nicht mehr Geheimwissen
Irgendeiner Person
Irgendeines Fachexperten, irgendeines Testers oder so
Sondern das ist jetzt hier schwarz auf weiß
Das sind die Erwartungen
Die wir an das System haben
Das ist das Verhalten, das wir
Erwarten, das wir voraussetzen
Das steht da
Das kann sich jeder anschauen, den das interessiert
Darüber kann man diskutieren
Dann hat man ein gemeinsames Verständnis
Man hat auch nicht zum Beispiel das Risiko, dass der eine Tester
Es ein bisschen mehr so macht und der andere ein bisschen mehr so
Und dann je nachdem, ob es der Heinz oder der Mike
Gemacht hat, wird der Test dann halt grün oder nicht
Sondern man kriegt diese schöne
Klarheit
Und wie gesagt
Das Tolle ist halt
Ich kann meine Abnahmetests
Im Voraus festlegen
Und zu jeder Zeit laufen lassen
Ich kann also sogar
Testgetriebene Entwicklungen machen
Auf der Feature-Ebene, auf der funktionalen Ebene
Sozusagen das klassische Red-Green-Refactor
Das geht dann halt nicht mehr auf Unit-Test-Ebene nur noch
Sondern wenn so ein BDD-Test
Einmal verfasst ist, als natürlich
Spezifikation, dann wenn ich den laufen lasse
Dann erwarte ich, dass der erstmal rot ist
Und dann tüftel ich weiter
So lange bis alles grün ist
Und dann kann ich in aller Ruhe refactoren
Und kann mir sicher sein, dass ich beim Refactoren
Mir nicht ein Ei lege, weil ich kann jederzeit
Nachtesten, gehen noch alle Funktionalitäten
Die mein Fachexperte sich von mir gewünscht hat
Das ist also eine Paralelität
Zu Test-Driven-Development auf Unit-Test-Ebene
Gibt es denn Unterschiede
Die man dabei beachten muss
Zwischen BDD und TDD
Naja, es sind
Verschiedene Sachen. BDD ist ja einfach nur
Automatisiertes Testen auf funktionaler
Ebene und
TDD, ich weiß was du meinst
Man impliziert
Immer ganz gerne, dass das halt auf Unit-Ebene stattfindet
Aber grundsätzlich heißt TDD ja nur
Ich schreibe erst meine Tests und dann
Die Funktionalität, die diese
Testfälle überhaupt erfüllt
Auf welcher Ebene ich das mache
Ist jetzt erstmal dahingestellt
Sind also alles
Treiber für
Driven-Development-DDs
Gibt natürlich auch andere DDs
Einfach zum Abgrenzen
Model-Driven-Development oder ADD
Gibt es etwas, was wir an der Stelle
Mit besprechen sollten
Ja, ich weiß nicht
Also
Model-Driven-Development ist ja dann nochmal wieder
Ein bisschen was anderes, wo man sich also erstmal
Ein Muster
Sozusagen seines
Funktionalen Elementes, ein Prototypen
Wenn man so will
Ein Mock, wie auch immer, baut
Und den kann man natürlich auch
Verwenden
Um, ich sag mal
Als ausführbare Spezifikation
Wenn man so will
Aber der Unterschied ist halt der
Model-Driven-Development und solche Sachen
Die setzen immer noch sehr viel technisches
Know-How voraus. Ich finde das Schöne an
An BDD
So wie es üblicherweise
Eingesetzt wird mit der Gherkin-Syntax
Und so weiter
Dass das auch für einen
Nicht
Software-Entwickler
Zugänglich ist
Ich meine, natürlich wird der am Anfang so ein bisschen fremdeln
Mit dieser Syntax und so
Und man soll um Himmels Willen
Nicht auf die Idee kommen
Einen Fachexperten solche BDD-Testfälle
Selber schreiben zu lassen, es sei denn
Der weiß, wie man Testfälle schreibt
Aber
Aber ganz grundsätzlich ist das einfach viel
Viel zugänglicher
Okay
Ich kenne noch die Abkürzung
ATDD
Akzeptanz
Test-Driven-Development
Ist das was anderes als BDD?
Ja, es hat halt eine andere Sichtweise
Also du kannst
ATDD auch
Mithilfe eines BDD-Frameworks machen
Verstehst du? Du kannst ja Akzeptanz-Tests
Verfassen
Mit deinem BDD-Framework
Deiner Wahl
Und dann auf diese Weise
Testgetrieben entwickeln, kannst du machen
Gibt es für dich noch andere Dinge
Die man abgrenzen sollte
Zu Behavior-Driven-Development
Oder über die wir jetzt an dem Punkt gut reden sollten
Ich finde, es gibt noch eine Sache
Die haben wir in unsere
In unsere Notizen reingeschrieben
Als wir uns über die Episode unterhalten haben
Nämlich, was ist denn jetzt der Unterschied
Zum Beispiel zwischen BDD und AB-Tests
Und der Unterschied ist ganz einfach der
Dass BDD, ich sag jetzt mal
Von seinem Ansatz her
Stattfindet vor
Der Auslieferung an den Kunden
Und das ist ja auch so
Vor einem Release
Das kann ich jederzeit machen
Während der Entwicklung, genauso wie ein Unit-Test oder sowas
Nichts hindert mich
Das sollte man vielleicht auch sagen
Nichts hindert mich natürlich daran
Diese Tests auch nachträglich
Nach der Auslieferung immer wieder laufen zu lassen
Und als Health-Checks im Prinzip einzusetzen
Für mein System und zu sagen
Kann ich jetzt zum Beispiel immer noch
Was weiß denn ich, wenn ich einen Online-Shop habe
Kann ich denn immer noch was bestellen?
Geht das denn?
Diesen Testfall, den habe ich zwar am grünen Tisch entwickelt
Und in meiner irgendwie
Testumgebung ausgeführt
Aber warum sollte ich den nicht auch in der Live-Umgebung ausführen können?
Kann man also machen
Ist das sowas wie eine
Synthetische Transaktion, wie
Einem unserer früheren Podcasts zum Thema
Observability diskutiert?
Ja, genau
Das wäre eine synthetische Transaktion
Genau, das stimmt
Okay, dann habe ich das soweit verstanden
Wir waren gerade bei BDD und AB-Tests
Du hast gerade erklärt, was die Vorteile von
BDD sind, wie man das letztendlich nutzen kann
Das ist vorrangig
Das ist vorrangig
Dafür ausgelegt ist es, während der Entwicklungsphase zu nutzen
Man kann es genauso auch umsetzen
In der Live-Umgebung
Dann sind wir bei
Observability, synthetischen Transaktionen
Aber wie sieht das jetzt mit AB-Tests aus?
Die sind letztendlich
Dafür nicht gedacht, sondern
Genau, die verfolgen ja ein ganz anderes Ziel
BDD ist ja ein Test
Auf der funktionalen Ebene
Tut das Ding das, was ich
Von ihm erwarte, was ich formuliert habe
Irgendwie
Während AB-Tests
Sind ja Tests, die nach der Auslieferung stattfinden
Indem man
Verschiedenen Benutzergruppen
Verschiedene Varianten des Systems
Zur Verfügung stellt
Und dann versucht, aus dem Benutzerverhalten zu schließen
Welche sich besser eignet
Mit anderen Worten
Das ist kein Test in dem Sinne
Sondern das ist ein Experiment
Und das ist ein Experiment nicht auf funktionaler Ebene
Sondern auf Wertebene
Welche der gegebenen Funktionalitäten
Der gegebenen Verhaltensweisen, die ich da darstelle
Empfinden die Anwender
Als wertvoller
Das ist eine Frage, die die BDD gar nicht
Zu beantworten versucht
Funktioniert ja auch nur im Zusammenhang
Mit den Nutzern
Die das System wirklich verwenden
Und BDDs
Werden letztendlich
Dafür eingesetzt, die Entwicklungsprozesse
Oder die Stabilität des Systems
Als teilweise noch Regressionstest
Zu verwenden
Wenn man jetzt überlegt, man möchte BDDs
Also Behavior-Driven entwickeln
Behavior-Driven-Development-Tests einsetzen
Gibt es bestimmte Techniken
An die man denken sollte?
Naja
Wie macht man sowas denn überhaupt?
Der erste Schritt ist, dass man
Diese natürlichsprachige Spezifikation
Mal verfasst
Das bedeutet, man wird sich in der Regel
Zusammensetzen mit
Einem Fachexperten
Und
Gibt es ja diesen berühmten
Begriff von den Three Amigos
Ich weiß gar nicht, wer sind denn die ganzen Amigos?
Also der Kunde ist einer
Und ich glaube klassischerweise ist der Entwickler der Nächste
Und der Product Owner der Dritte, war das so?
Also ich kenne viele
Es gibt ja auch den Film und Chevy Chase und Co
Aber im agilen Umfeld
Im agilen Umfeld hätte ich jetzt gesagt
Business
Also entweder Product Owner, Kunde oder Kundenvertreter
In irgendeiner Form, Fachexperte
Der Zweite ist für mich immer
Die Entwicklung, also die, die das umsetzen
Und die Dritten die Tester
Die an der Stelle
Überlegen, wie kriegen wir
Sichergestellt, dass das, was der
Entwickler entwickelt, mit dem übereinstimmt
Was der Anforderer
Sich ausgedacht hat
Genau
Und insofern
Ihr merkt auch, liebe
Zuhörer, mir ist das gar nicht so wichtig, wer die Amigos
Im einzelnen sind, das Wesentliche ist halt
Dass man die Leute an den Tisch bringt, die
Dazu beitragen, dass
Das gute
Spezifikationen werden
Schrägstrich gute Tests werden
Dass da am Ende ein rundes Produkt dabei rauskommt
Und da werden bestimmt ein ganzer Haufen Amigos
Irgendwie auflaufen, im Zweifelsfalle
Ja, je weiter
Das Team cross-funktional ist
Desto mehr verschiedene Rollen
Spielen damit rein
Das ist ein Stück der Gedanke von
Development und Operations zusammenzubringen
Bereiche, die im klassischen Umfeld
Ja, mehr oder weniger nichts
Miteinander zu tun hatten, außer die
Wall of Confusion, über die sie bestimmte
Effekte drüber geworfen haben
Pakete, die gebaut worden sind
Auf einem Entwicklerrechner, der dann
In der Form produktiv
Gehen soll und wo sich dann
Operations drum kümmern sollte, dass das funktioniert
Je mehr man letztendlich
Den Wertstrom betrachtet
Also von Anfang, von der Anforderung, von dem
Kunden gedacht, bis hin zur Funktionalität
Die dem Kunden wieder zur
Verfügung gestellt wird, umso
Mehr Beteiligte kann man in dem
Prozess haben, ja
Ansonsten, gut, Techniken sind
Gespräche, gibt es noch andere Dinge, auf die man
Auf der Ebene achten sollte oder
Wenn nicht, würde ich sagen, gehen wir zum nächsten
Thema über, welche Unterstützung
Durch Tools kann man an der Stelle bekommen
Genau, also ganz grundsätzlich
BDD ist etwas, was man
Mit Tool-Unterstützung macht
So wie Unit-Test, da hast du immer
Ein Unit-Test-Framework und bei BDD hast du auch immer
Irgendein BDD-Framework
Das eben für dich die automatisierte
Testausführung übernimmt
Und in dem speziellen
Fall halt auch das Mapping von
Spezifikation auf
Test-Code, wie auch immer der
Lied ausgedrückt ist
Da gibt es also BDD-Frameworks
Gibt es für jede mir bekannte
Programmiersprache
Ich glaube in JavaScript gibt es Jasmine
Unter anderem
Es gibt natürlich den Uropa
Von in allen, Cucumber für
Ruby
Die sind auch diejenigen, die mit der Gherkin-Syntax
Angefangen haben
Es gibt Behave unter Python
Und so weiter und so weiter, also für jede
Programmiersprache eurer Wahl
Gibt es
Ein entsprechendes Framework
Und vielleicht sollte man das an der Stelle auch erwähnen
Wir sind ja so weit weg vom eigentlichen
Produktionscode, dass
Bloß weil jetzt dein Produkt in, weiß nicht, Java
Geschrieben ist, heißt das nicht, dass
Auch dein BDD-Framework
Ein Java-Framework sein muss, sondern du kannst
Deine Tests
Auf der funktionalen Ebene
Ja auch von mir aus in
Ruby formulieren
Du brauchst halt nur die passende
Laufzeitumgebung, damit du sie
Umsetzen kannst
Wie gut sind solche
Frameworks und Vorgehensweisen
In Continuous Delivery
Oder Continuous Integration Tools
Integriert oder integrierbar
Sehr gut
Also das läuft wirklich ganz geschmeidig
Das kannst du so wie jedes andere
Test-Framework da einfach
Anflanschen
Und die, das hängt natürlich
Von den Spezifika der jeweiligen Frameworks ab
Aber alle, die mir bekannt sind, die sind auch
In der Lage, zum Beispiel
Diese klassischen
Ex-Unit-Resultat-Dateien
Zu generieren, die dann auch wiederum
Von allen gängigen
CI-Tools konsumiert werden können
Also das stellt normalerweise eigentlich
Keine wirkliche Schwierigkeit dar
Das passt schon
Die Pferdefüße, wenn man BDD
Verwendet, die liegen ganz woanders
Okay, da kommen wir bestimmt noch drauf zu sprechen
Erstmal würde ich
Ein Gefühl dafür kriegen, wie das im konkreten
Beispiel aussieht, mit so einem
BDD-Testfall
Kannst du uns sagen, was
Letztendlich da
Das Pudels Kern ist
Genau, also das ist natürlich ein bisschen undankbar
In einem Podcast
Ich werde es trotzdem versuchen und
Liebe Hörer, ihr müsst euch auch vorstellen, dass ich ganz wild
Mit meinen Händen rudere, indem ich versuche, das noch ein bisschen
Plastischer zu machen, hilft aber auch niemandem
Also, nehmen wir uns mal
Als Beispiel, wir entwickeln
Irgendwie hier einen Online-Shop
Kennt natürlich jeder von euch
Das ist also eine Anwendung, die natürlich auch
Sehr dankbar sich mit BDD
Testen lässt, weil da ist
Ziemlich klar, wie man an die Schnittstellen
Rankommt, wie man sowas
Automatisieren kann
Und da würde ich hergehen und würde ich eine
Spezifikation verfassen
Okay, sagen wir mal
Es geht jetzt erstmal darum, sich einzuloggen oder sowas
Dann könnte ich ja
Die Spezifikation verfassen, ich sage
Given
I am at
The login page
Ich stelle einen Grundzustand ein
When
I enter
The correct password
Then
I am transferred to the welcome page
Oder sowas
Das wäre ein ganz klassischer Ablauf
Und ihr merkt schon, liebe Hörer
Da habe ich natürlich ein bisschen was rausgelassen
Man braucht bestimmt außer dem Passwort auch noch einen Benutzernamen oder so
Aber im Sinne der Einfachheit
Given
Irgendeinen gegebenen Grundzustand
When
Ich stimuliere das System irgendwie
Then erwarte ich
Ein bestimmtes
Eine bestimmte Reaktion des Systems
Ganz klassisch, ganz banal
So, das habe ich jetzt natürlich
Sprachlich so formuliert
Und dann werde ich in
Sagen wir mal
In Cucumber
Werde ich dann eine entsprechende
Ruby-Funktion haben
Die hat dann ein
Ein Markup
Mit dem das BDD-Framework erkennen kann
Okay, wenn der Benutzer schreibt
Given I am at the login page
Dann heißt das für mich
Ich muss meinen Mock-Browser
Zu
Dieser Login-URL
Schicken
When I enter
A password
Dann weiß er
Dann muss er das mappen auf eine Ruby-Funktion
Und dieses Mapping, das geschieht auch
Ganz stumpf in der Regel einfach über reguläre Ausdrücke
Da steht dann einfach
So ein Stück von diesem Satz nochmal
Und das sucht dieses BDD-Framework
Das sagt dann
Wenn ich den folgenden Text
In der Spezifikation lese
Auf welche
Konkrete Funktion
In einer Programmiersprache
Muss ich die anwenden
Welche muss ich jetzt ausführen
Welche muss ich laufen lassen
Das übernehmen die Frameworks
Dann dieses Mapping
Das heißt, man muss zwar den Text
Quasi kopieren
Aus dem Behavior-Driven-Test-Fall
Aus der Beschreibung, aus der Spezifikation
Das dann in ein Stück
Quellcode übernehmen
Und daraus quasi von
Beschreibungstext in
Ausführbaren Code
Das Mapping übernimmt dann das Framework
Genau, und viele Frameworks
Helfen einem dann auch dabei, wenn die zum Beispiel
Ein neues Stück Text sehen
Für das sie nichts gemapptes finden können
Dann spucken sie direkt einen Funktionsrumpf aus
Und sagen, magst du nicht den direkt nehmen
Und den muss man dann natürlich
Noch selber mit Leben füllen
Das ist klar, das kann dann wiederum das Framework nicht übernehmen
Dass es dann sagt, wie weiß ich denn zum Beispiel
Meinen Automatenformat
Im automatisierten Browser an
Zu dieser URL zu gehen oder sowas
Das kann es nicht
Machen das dann üblicherweise die Entwickler mit
Die dann das mitentwickeln
Oder ist das eine Aufgabe bei Testern
Oder kommt so der klassische
Kommt drauf an, mal so, mal so
Ja, es kommt natürlich drauf an
Aber ich sag jetzt mal, in der Regel
Machen das dann tatsächlich Tester
Machen das Leute, die einfach geübt im Umgang
Mit solchen Automatisierungswerkzeugen zum Beispiel sind
Ist das so ein
Ein Tester mit Automatisierungshintergrund dann
Also nicht unbedingt ein manueller Tester
Sondern jemand, der sowas, wie du gesagt hast
Schon das ein oder andere Mal gemacht
Gesehen hat und weiß, worauf er achten muss
Okay
Genau
Und natürlich, wenn ein Entwickler auf Draht ist
Dann kann der das auch selber machen
Aber in der Regel, sagen wir mal
Kristallisiert sich es halt irgendwie raus
Es gibt Leute, die sind gut da drin
Diese Automatisierungen zu verfassen
Und die machen das dann
Okay
So
, aber jetzt ist das natürlich noch nicht so
Nicht so richtig wahnsinnig testgetrieben
Weil jetzt muss ich ja trotzdem immer noch
Eine Spezifikation verfassen
Und dann muss jemand einen Test verfassen
Das kann er zwar auch gleich machen
Aber jetzt kommen wir zu etwas, was
Sich in der Praxis häufig als sehr charmant herausstellt
Nämlich
Die Anzahl der verschiedenen
Aktionen, die man tatsächlich ausführt
Gegen eine Software
Die sind relativ gering
Zum Beispiel, geh zu einer URL oder so
Du hast vielleicht 100 verschiedene URLs
In deinem Produkt
Aber
Ganz grundsätzlich
Zu einer URL gehen
Ist ja immer dieselbe Funktion
Der Witz ist nämlich
Du kannst
Die natürlichsprachige Spezifikation
Auch parametrieren
Da gibt es dann auch
Je nachdem, welches Framework
Gibt es da verschiedene Auszeichnungen
Beliebt sind geschweifte Klammern zum Beispiel
Und dann weiß dieses Framework auch
Es gibt zum Beispiel eine generische Funktion
Geh zu einer URL
Und dann
In der natürlichsprachigen Spezifikation
Steht dann in den geschweiften Klammern drin
Was denn in dem Fall die konkrete URL ist
Also ich
http
Doppelpunkt
Doppel Slash
Logo
Host Slash
Login
Was auch immer
Ne?
Und dann
Kommst du an den Punkt
Dass
Überhaupt nicht mehr
Für jeden einzelnen Testfall
Für jede einzelne Spezifikation
Ein Tester tatsächlich Code schreiben muss
Sondern dann kommst du ziemlich schnell
Auf den Grundstock von
Ich sag jetzt mal
20, 30, 40 Funktionen
Die du für
Ich weiß nicht
Tausende von Testfällen einsetzen kannst
Gibt es dafür
Bibliotheken
Die man nutzen kann
Die vielleicht
Quasi
Wiederverwendbar sind
Begrenzt
Begrenzt
Also sie sind dann schon
Eher produktspezifisch
Das heißt
Da muss man
Dann wirklich
Selbst sammeln
Und entwickeln
Okay
Genau
Aber das Schöne ist eben
So viel muss man am Ende
Gar nicht sammeln
Das könnt ihr euch selber überlegen
Auch bei meinem Beispiel
Vorher mit
Passwort eingeben
Das ist ja einfach nur
Irgendein String
In irgendein Textfeld
Und wenn du deine
Test
Deinen Testcode
Entsprechend generisch
Formulierst
Dann ist das
Dann
Funktioniert das für
Benutzernamen
Genauso wie für
Passwörter
Genauso wie für
Keine Ahnung
ISBNs
Etc.
Etc.
Etc.
Dann musst du also
Wirklich nur noch
Den natürlichsprachigen
Teil
Verfassen
Und die Automatisierung
Ist ohnehin schon
Steht ohnehin schon
Zur Verfügung
Weil du es schon
Hast halt schon mal gemacht
Okay
Das ist auch der Weg
Wie man damit anfängt
Also
Letztendlich
Erfahrungen sammeln
Ersten BDD-Testfall
Mal schreiben
Gucken wie es
Funktioniert
Und dann weitergehen
Oder gibt es
Noch weitere
Tipps
Genau
Also um zu starten
Ist es genauso
Wie du sagst
Da würde ich mir
Erstmal irgendein
Ich sag jetzt mal
Leicht zugängliches
Stück Funktionalität
Nehmen
Und da einfach mal
So ein bisschen
Das ausprobieren
Und da hat man
Relativ schnell
Glaube ich auch
Recht gute Erfolge
Gerade mit dem
Was ich gerade
Beschrieben habe
So eine Login-Funktion
Oder sowas
Die
Ich sag jetzt mal
Wenn du es noch nie
Gemacht hast
Wahrscheinlich hast du
Innerhalb von
Einer voller Stunde
Einen
Nennen wir es mal
Hello-World-Test
Das ist also
Sehr verlockend
Ich finde aber
Leider
BDD ist so ein bisschen
Heikel
Weil es gehört
Zu den Techniken
Für die man
Schon so ein bisschen
Erfahrung braucht
Bisschen Fingerspitzengefühl
Braucht
Weil es relativ
Leicht ist
In die falsche
Richtung zu laufen
Und das sehr lange
Nicht zu merken
Okay
Woran kann man das erkennen
Oder was
Typische Fehler
Die man vermeiden kann
Oder Risiken
Die man beachten sollte
Also es gibt
Eine Reihe von Risiken
Ein Risiko
Dem man sich
Vielleicht einfach
Durch
Durch Disziplin
Ein bisschen
Entledigen kann
Ist
Dadurch
Dass du dieses Mapping hast
Von natürlich sprachig
Auf irgendwie
Eine Funktion
Ist es
Relativ leicht möglich
Dass man nicht so richtig
Realisiert
Dass es eine Funktion
Schon gibt
Und dann hast du
Vielleicht irgendwie
Drei, vier, fünf, sechs
Funktionen
Die alle dieselbe
Funktionalität
Eigentlich
Implementieren
Sagen wir mal
Zu einer URL gehen
Oder sowas
Weil
, ne
Da hilft es
Also wenn man sich
Wirklich so
So eine sehr klare
Sprechweise überlegt
Und ein sehr klares
Vokabular überlegt
Um solche Dubletten
Zu vermeiden
Die ja dann auch
Irgendwann mal
Zu Schwierigkeiten
Führen können
Also manche Tests
Funktionieren
Und manche funktionieren
Nicht
Je nachdem
Welche der Methoden
Sie aufrufen
Oder sowas
Das ist also das eine
Das andere ist
Wie
Formuliere ich
Eigentlich meine
Spezifikation
Vielleicht hat
Der eine oder andere
Von euch
Liebe Hörer
Schon gerochen
Ich könnte ja jetzt
Dieses
Dieses
Given
I am
At
You know
At the login page
Oder sowas
Das kann ich entweder
So formulieren
Sehr
Ich sag mal
Spezifisch
Und natürlich
Sprachig
Oder ich kann es
Formulieren als
Given I am
At the URL
So und so
Dann wäre es viel
Leichter zu parametrieren
Aber ist nicht mehr
Produktspezifisch
Sondern ist dann halt
Irgendwie so ein bisschen
So beliebig
Liest sich nicht mehr
So schön
Gerade für
Fachfremde Leute
Die vielleicht
Nicht so richtig
Geübt darin sind
URLs zu lesen
Da kann man also
Sich auch viel
Kaputt machen
Da kann man sehr viel
Wiederverwendbarkeit
Überraschenderweise
Auch wieder einbüßen
Sogar mit dem
Versuch Dinge
Generischer zu machen
Da gibt es aber
Kein Patentrezept dafür
Sondern da muss man
Genauso die richtige
Formulierungsebene
Finden
Wo man sagt
Das ist
Natürlich
Sprachig
Menschen
Zugänglich
Aber andererseits
Halt auch noch
Griffig umzusetzen
Für einen
Für einen gewieften
Testautomatisierer
Der sagt
Ah das kann ich hier
Parametrieren
Da kann ich
Das kann ich
Kann ich verallgemeinern
Da gibt es ganz viele
Möglichkeiten
Sich in den Nesseln
Zu setzen leider
Okay
Wie sieht es denn
Mit
Kontexten aus
Bei dem
Entwicklungsteams
Betriebsteams
Oder von mir aus
Auch kombinierte Teams
Im DevOps
Zusammenarbeiten
Oder vielleicht auch
In größeren Kontexten
Wenn man jetzt
Ein Produkt hat
Mit vielen Komponenten
In einem Umfeld
Keine Ahnung
Von mehreren
Hundert
Teammitgliedern
Dass man
Dass man
Einen
BDD-Test hatte
Wirklich
Auf einer
Team-von-Teams-Ebene
Das Verhalten
Eines wirklich
Großen Stücks
Systemtesten
Oder des Gesamtsystems
Meinst du
Ist
Oder
Kann mitunter
Schwierig sein
Muss aber nicht
Wenn ich jetzt
Wirklich sehr weit
An der Oberfläche bin
Um bei unseren
Berühmten
Beispiel zu bleiben
Von dem Login-Fenster
Jetzt von diesem
Online-Shop
Was weiß denn ich
Wie viele Services
Da im Hintergrund
Daran beteiligt sind
An der Oberfläche
Sag ich jetzt erstmal
Ich kipp da halt
Irgendwie ein Passwort rein
Und drück auf
Okay
Und dann erwarte ich
Direktion des Systems
Und es kann ja sein
Dass da hinten
Eine riesen Maschinerie
Dran hängt
Aber das seh ich
Auf der Ebene
Vielleicht gar nicht
Kann aber natürlich
Auch anders sein
Insbesondere wenn es
Wenn man versucht
Teilsysteme zu testen
Und insbesondere
Wenn man versucht
Oder wenn man
Wenn man
Gezwungen ist
Komplexe Setups zu machen
Wenn ich jetzt
Ganz ganz viele
Givens hab
Um überhaupt
Meine verschiedenen
Teilsysteme
Erstmal
An die richtige
Stelle zu bewegen
Na wenn ich
Mitten im Bestellprozess
Bist
Genau
Und dann geht’s darum
Mach ich’s mit der Kreditkarte
Oder mach ich’s auf Rechnung
Oder sowas
Dann muss ich halt schon mal
So einen riesen
Kleider der Dutch
Vorne weg machen
Bis ich überhaupt mal
An dem Punkt
Angekommen bin
Um den es mir
Eigentlich geht
Da kann’s
Kann
Kann
.
Ganz mühselig sein
Sag ich mal
Aber ich glaube
Gerade in solchen
Komplexen Kontexten
Zeigt sich dann auch
Wirklich der große Wert
Weil jeder
Einzelne in dieser Kette
Kann einfach zu jedem
Zeitpunkt diesen Test
Diesen Test aus dem Regal
Nehmen und sagen
Funktioniert’s noch
Wenn ich jetzt
Mein Teilsystem
In der folgenden Weise
Abändere
Geht das Gesamtsystem noch
Das wird wahnsinnig
Machtvoll
Weil du dir noch
So eine
So eine Sicherungsebene
Einziehst
Auf dieser
Hohen Ebene
Auf der funktionalen Ebene
Auf der Systeme
Ebene
Auf der Teams-von-Teams-Ebene
Okay
Kann ich mir gut vorstellen
Dann ist so ein bisschen
Die Frage
Wie hängt das Ganze zusammen
Mit dem Zuschnitt
Von Anforderungen
Also
User-Stories auf Team-Ebene
Vielleicht auch
Features
Capabilities
Epics
Auf übergeordneten Ebenen
Ja also
Grundsätzlich
Kann ich’s auf all diesen
Ebenen einsetzen
Auch parallel
Es hindert dich ja
Überhaupt niemand daran
BDD-Style
Tests zu schreiben
Auf der User-Story
Ebene
Und das
Innerhalb des Teams
Einzusetzen
Für den Nachweis
Dass meine Teilkomponente
Macht was sie soll
Und das zugleich zu machen
Vielleicht auf der Epic-Ebene
Oder sowas
Und zu sagen
Naja
Ein ganz großer
Abschnitt meines Systems
Kann ich hier
Durch automatisierte
Akzeptanz-Tests
Zum Beispiel
Einfangen
Und ausdrücken
Kann ich machen
Okay
Sind das dann
Letztendlich
Das was man sonst
Als Erfolgs- oder
Akzeptanz-Tests
Oder Akzeptanz-Kriterien
Zu jedem dieser Elemente
In einem Backlog
Mit
Aufschreiben würde
Einfach in einer anderen Syntax
Damit es dann
Realisierbar ist
Ja und nein
In einem gewissen Sinne schon
Aber in einem gewissen Sinne
Andere
In einem gewissen anderen Sinne
Nicht
Insofern als
Sich das einstellt
Was man auch von Unit-Tests
Vielleicht kennt
Dass
Für ein gegebenes Stück System
Man eine Mehrzahl von Tests braucht
Vielleicht
Wenn du einen
Natürlichsprachigen Akzeptanz-Test
Ein
Natürlichsprachigen
Ein manuellen hättest
Dann würdest du sagen
Keine Ahnung
Das System soll nur
Gültige Logins zulassen
Oder sowas
Kannst du stumpf hinschreiben
Und der Tester füllt das dann mit Leben
Und sagt
Aha okay
Da muss ich
Falsches Passwort
Falscher Username
Leeres Passwort
Was auch immer
Der sich da so für Testfälle ausdenkt
Während so
Wenn ich das mit BDD mache
Dann
An irgendeinem Punkt
Muss ich das dann halt auch wirklich
Aufdröseln
Und sagen
Diese verschiedenen Varianten gibt’s
Und das sind die verschiedenen Reaktionen
Des Systems
Die ich erwarte
Also hinter
Gültiges Login
Dann halt
Die ganzen
Testfälle
Abbilden
Irgendwie über
Keine Ahnung
Was ist denn das
Tabellenübersichten
Oder
Wie
Baut man sowas dann auf
Tolle Frage
Genau
Weil
Vielleicht hat auch
Die ein oder andere Hörerin
Schon mit den Ohren
Mit den Augen gerollt
Wenn man sich jetzt vorstellt
Man müsste für jeden Testfall
Wieder so ein
Gesatzel sich schreiben
Given
So und so
When
Das und das
Das und das
Then
Bla bla bla
Da wirst du irre
Wenn ich mir jetzt
Login ist ja ein typischer Fall
Da kann ich mir ja locker
Weiß nicht
20 verschiedene Testfälle ausdenken
Von Benutzernamen
Passwortkombinationen
Und den entsprechenden Reaktionen
Für den Fall
Bieten die meisten Frameworks
Auch Vereinfachungen
Zum Beispiel
So wie du es gerade gesagt hast
Tabellen
Einfach wirklich ASCII Tabellen
Und dann kommt natürlich
Die Stärke von parametrierten
Testfunktionen
Zum Tragen
Dann kannst du sagen
Okay ich habe hier
Keine Ahnung
Die Spalte Username
Und da steht dann drin
Einmal der richtige
Und fünfmal der falsche
Und dann habe ich die Spalte
Passwort
Und da steht dann auch
Einmal das richtige
Und fünfmal das falsche
Und so
Und dann habe ich von mir aus
Eine Spalte Resultat
Und da steht dann
Einmal
Kommt rein
Und fünfmal
Wird zurückgewiesen
Oder so
Und auf diese Weise
Kann ich das dann schon
Sehr schön kurz und knackig
Formulieren
Und auch lesbar machen
Und erträglich machen
Sage ich mal
Insbesondere
Wiederum
Für Fachexperten
Die da vielleicht
Keinen Bock drauf haben
Sich durch
50 Seiten
Given when thens
Durchzukämpfen
Das klingt auf jeden Fall gut
Macht es einfacher
Gibt es weitere
Best Practices
Die hilfreich sind
Im Umgang mit
BDD
Behavior Driven
Development
Best Practices
Also
Wichtig ist
Ist glaube ich eben
Dass man sich überlegt
Auf welcher Ebene
Formuliert man das Ganze
Und dann
Zum Beispiel
Bilde ich
Verschiedene
Seiten
Meiner Web-Anwendung
Durch URLs ab
Oder bilde ich die
Durch Begriffe ab
Login-Seite
Hauptseite
Willkommensseite
Und so fort
Wie gehe ich damit um
Was bringt das für mich
Für Vor- oder Nachteile
Das hängt auch immer
So ein bisschen davon ab
Was die Frameworks
Jeweils dann für Möglichkeiten
Bieten um vielleicht
Aliasse zu definieren
Und solche Dinge mehr
Ähm
Also
Ich muss mir Gedanken machen
Wie ich
Wie ich meine Testfälle
Auf verschiedene Dateien aufteile
Darüber haben wir noch
Gar nicht gesprochen
Das sind ja immer
Textdateien
Oder das ist der übliche Fall
Das sind einfach Textdateien
Und es bietet sich dann häufig an
Einzelne Dateien auszuführen
Wenn ich mir jetzt vorstelle
Ich habe eine riesen Test-Suite
Mit ein paar hundert
BDD-Testfällen
Das kann schon mal
Erklägliche Zeit dauern
Bis die mal durchgeraten sind
Und dann macht es natürlich Sinn
Sich da schöne
Teilmengen zu überlegen
Zu sagen
Okay
Das da ist
Keine Ahnung
Dieser Microservice
Oder
Das da sind
Genau die Funktionen
Die momentan gerade heiß sind
Oder
Das sind die besonders
Wichtigen Kernfunktionen
Die müssen
Auf alle Fälle gehen
Oder sowas
Da
Gibt es also
Ähm
Best Practices kann ich jetzt nicht gut formulieren
Insbesondere nicht in einem Podcast
Da werden einfach alle irre
Wenn ich jetzt anfange
Irgendwie Pfade runterzurattern
Oder sowas
Aber das sind halt so
So Dinge mit die man
Die man im Hinterkopf haben muss
Wenn man sich überlegt
Wie baue ich
Meine Tests konkret auf
Und das ist genau der Grund
Aus dem ich sage
Es empfiehlt sich da einfach
Sich mal mit jemandem zu unterhalten
Der das schon mal gemacht hat
Und der da irgendwie
Fast grundsätzlich
Auch schon mal auf die Fresse geflogen ist dabei
Ähm
Damit man
Diese Fehler nach Möglichkeit
Ähm
Nicht macht
Mhm
Gut
Man kann natürlich mit Leuten reden
Die das schon gemacht haben
Direkte Erfahrungen gesammelt haben
Oder auch
Ähm
Vielleicht
In der Literatur ein Stück
Nachschlagen
Gibt es denn
Aus deiner Sicht
Beispiele
Bücher
Ähm
Andere Quellen
Die sinnvoll sind
Über die man
Ähm
Sich das Thema
Ein Stück näher bringen kann
Ja also
Das klassische Buch dazu
Ist glaube ich
Ähm
Specification by example
Von Gojko Adzic
Ähm
Ähm
Liest sich ganz gut
Ist auch nicht allzu dick
Das sind
Lass mich lügen
180 Seiten oder so
Ähm
Das ist wirklich
Eine schöne Einführung
In das Thema
Ansonsten
Ähm
Lustigerweise
Das kann man vielleicht auch sagen
Das ist
Das scheint so stark
Abhängig von der jeweiligen
Ähm
Von
Von der jeweiligen
Vertikalen zu sein
In der man unterwegs ist
Wie stark BDD
Genutzt wird
Das scheint im Banken
Und Versicherungssektor
Recht weit verbreitet zu sein
Ähm
Ähm
Aber in anderen Sektoren
Zum Beispiel nicht so sehr
Insofern
Ähm
Wenn man Glück hat
Findet man da auch schon
Kollegen in eigenen Unternehmen
Die das mal ausprobiert haben
Und äh
Bei denen man sich dann
Erfahrungen abholen kann
Ansonsten kann man natürlich auch
Ähm
Sich Hilfe von außen holen
Vielleicht
Kann ich an der Stelle
Kurz erwähnen
Ähm
Ja
Auch
Auch Vampure bietet dazu
Ähm
Kurse und Workshops an
Und äh
Und Beratung
Genau
Aber
Um das wirklich nochmal abschließend zu sagen
Ich wünschte
Mehr Leute würden es verwenden
Weil ich find’s
So ein tolles Werkzeug
Und es ist eigentlich
Nicht so aufwendig
Damit anzufangen
Und man kann ja auch
Man kann ja erstmal echt
Kleine Brötchen backen
Dann machst du halt mal
Nur fünf Testfälle
Das sind immer noch
Das sind immerhin noch
Fünf mehr als gar nix
Und das ist
Und die können
Einem so viel
Sicherheit geben
Auf dieser Ebene
Des Gesamtsystems
Und dann kann man ja
In aller Ruhe
Erfahrungen sammeln
Und kann in aller Ruhe
Herausfinden
Wofür eine
Da die goldene Mitte liegt
Na wie viele
BDD Testfälle
Möchte ich denn eigentlich
Ganz gerne haben
Wie viele
Funktionale Tests
Möchte ich gerne haben
Wieder na
Die Testpyramide
Wie dick will ich dann
Die Spitze von der Pyramide machen
Und dann
Ja so dick
Dass sie halt auch noch
Getragen werden kann
Von dem Rest
Und weiter gepflegt werden kann
Wo sind denn
Bei größeren Produkten
Die Grenzen
Wie viele
BDD
Testfälle
Sind denn noch
Handelbar
Also das
Für komplexe Produkte
Bei Organisationen
Die es damit ernst meinen
Da kann das auch mal
In die Tausende gehen
Na wenn man
Mittelprächtige
Irgendwie Anwendung hast
Und du machst das
Wirklich
Systematisch
Du lädst deine
Deine
Fachleute ein
Deine
Abteilungsexperten ein
Jeder gibt da
Seinen Senf dazu
Und gießt
Na jede
Jede
Jede beliebige
Verhaltensweise
So wie es ja üblich ist
Dann in
Eine Mehrzahl von Testfällen
Dann habe ich immer
Meinen Happy Path
Und dann habe ich noch
Verschiedene Fehlerfälle
Und so
Das geht ruckzuck
Aber
Ich finde es ist eben auch
Überhaupt keine
Schadensfälle
Schande zu sagen
Wir machen das wirklich
Nur als Smoke Test
Wir machen uns da
Beispielshaft
Fünf
Happy Paths
Und wir weisen uns nach
Dass wenigstens
Die
Weiterhin
Zucken
Und alles andere
Machen wir auf niedrigeren
Ebenen
Wie viel Pflegeaufwand
Steckt denn in so einer
Test Suite
Für Behavior Driven
Development
Ähm
Ähm
, häufig
Lass mich zweiteilen
Ähm, auf der Code-Ebene
Auf der Ebene der Testimplementierung
Ist der Aufwand häufig
Überraschend gering
Weil es sind nämlich häufig
Gar nicht so viele
Wenn du eine Web-Anwendung hast
Schlussendlich so viele
Verschiedene Interaktionen
Mit der hast du ja gar nicht
Halt auf vielen verschiedenen Seiten
Und in vielen verschiedenen Kontexten
Aber ein Textfeld ist ein Textfeld
Und ein Button ist ein Button
Fertig, ne?
Wenn ich einmal den Code habe
Um Buttons zu klicken
Dann kann ich halt
Alle tausend Buttons
Auf meiner Webseite klicken
Das ist also vergleichsweise
Überschaubar häufig
Wo häufig der Teufel drinsteckt
Ist
In der Spezifikation
Und zwar nicht nur
In den einzelnen Spezifikationen
Wie die verfasst sind
Sondern vor allen Dingen
In ihrem Zusammenhang
Ob die weiterhin
In ihrer Struktur
Gut zusammenpassen
Ob die sich vernünftig
Testen lassen
Ähm
Dass ich da den
Zwischen den
Ausrüstungs-
Also Aufwand
Akzeptabel halte
Um mir eine neue
Testumgebung zu bauen
Und so
Da kann also ganz viel
Refactoring-Aufwand
Drin stecken leider
Und deswegen ist es halt
Auch so kritisch
Dass man sich da
Ein gutes System überlegt
Ähm
Dass einem da
Die Möglichkeit
Weiterhin offen lässt
Sich auch mal zu verändern
Weil das wird passieren
Hm
Gut
Wir sind letztendlich
Oh ziemlich
Am Ende der
Geplanten
Länge
Der Session
Ähm
Ähm
Ähm
Ähm
Ähm
Ähm
Ähm
Ähm
Ähm
Hast du noch
Punkte
Die wir bis jetzt
Nicht besprochen haben
Die du gerne noch
Reden möchtest
Oder noch
Ein Hinweis
Auf eine Quelle
Geben
Oder irgendwas
Was hilfreich ist
Für
Jemanden
Der sich
Weiter mit dem
Thema
Behavior-Driven
Development
Befassen möchte
Also
Vielleicht als
Als weiteren
Literatur-Hinweis
Im weitesten Sinne
Ich finde
Zum Beispiel
Die Wikipedia-Seite
Über
Behavior-Driven
Development
Ganz gut gemacht
Die hat ein paar
Schöne Beispiele
Und
Ähm
Und das Witzige
Bei BDD ist
Das ist so
So schlank
Irgendwie
Ähm
Damit ist dann schon
Schier alles gesagt
Also auch
Das Buch von
Gojko Adzic
Zum Beispiel
Das hält sich mal
Kurz drei Seiten
Damit auf dir zu sagen
Also es gibt dann
Ein Given
Und ein When
Und ein Then
Plus extra Würste
Und sich dann
Den Rest des Buches
Damit aufhält
Zu sagen
Und so macht man es richtig
Und so sollte man es
Besser nicht machen
Und
Wie gesagt
Probiert es aus
Ähm
Es soll euer Schaden
Nicht sein
Und wie gesagt
Ich ändere nochmal
An mein Eingangsbeispiel
Wir hatten
Ein Produkt
Wo wir nur
Einen einzigen Test hatten
Es war also
Fast ein bisschen
Übers Ziel hinausgeschossen
Dass wir das als BDD
Formuliert haben
Aber es war einfach
Hilfreich für uns
Damals auch zu durchdenken
Was
Was wollen wir denn
Was soll das Ding denn machen
Und dann hatten wir schon
So formuliert
Dann haben wir es direkt
So gelassen
Ähm
Das ist so machtvoll
Diese
Diese Sicherung
Im Rücken zu haben
Dass man sagt
Ganz grundsätzlich
Kann ich das Gesamtsystem
Automatisiert
Durchtesten
Okay
Dann
Würde ich sagen
Vielen Dank
Für
All deine
Gedanken und Beiträge
Ich hoffe
Unsere
Hörer interessieren sich
Auch für
Ähm
Das Thema BDD
Dadurch mehr als zuvor
Gibt vielleicht
Eine Anregung
Für den einen oder anderen
Es wirklich zu tun
Ähm
Du hast erwähnt
Die Wikipedia-Seite
Du hast das
Äh
Die Schulungen und Workshops
Die es bei
Bei Vampio
Also unter
Vampio.de
Ähm
Gibt
Ähm
Wenn ihr
Feedback
An uns habt
Könnt ihr natürlich auch gern
Über den Weg
Mit uns in Kontakt
Treten
Uns Hinweise geben
Vielleicht habt ihr auch mal Lust
In ähm
Dem Podcast
Mit aufzutreten
Und ähm
Ganz andere Stich
Äh
Ganz andere Sichtweisen
Ähm
Vielleicht mit uns zu diskutieren
Ähm
Kommt auf uns zu
Wir freuen uns darauf
Und ähm
Wünschen euch
Bis zur nächsten Folge
Eine gute Zeit
Vielleicht mit BDDs
Genau
Also vielen Dank fürs Zuhören
Macht’s gut
Bis bald
Ciao
Ciao
Ciao

Folge 59: Observability mit Alden Peterson 2/2 [EN]

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Observability (kurz: O11y) ist eine wichtige Komponente von DevOps. Darüber sprechen wir mit dem QA-Experten und Observability-Fanatiker Alden Peterson von Netflix.

Dies ist der zweite Teil der Unterhaltung, die wir in der vergangenen Folge begonnen haben.

In this episode of the DevOps podcast, the hosts Luca Ingianni and Falko Werner, along with their guest Alden Peterson, delve into the practical side of observability within DevOps. They transition from a philosophical overview to concrete applications, emphasizing the importance of understanding and defining problems in DevOps environments. The discussion includes practical advice on starting with observability, the significance of synthetic transactions, and the integration of various elements like monitoring, logging, and security. They also explore the challenges in quantifying observability’s impact and the role of engineers in enhancing system reliability and customer value.

Inhalt

  • Introduction to Observability in DevOps
  • Transition from Philosophical to Practical Aspects of Observability
  • Starting with Observability: Challenges and Steps
  • Role of Synthetic Transactions in Observability
  • Monitoring, Logging, Alerting, and Testing in DevOps
  • The Impact of Observability on Engineering and Product Development
  • Integration of Security in Observability (DevSecOps)
  • Quantifying the Impact of Observability
  • Case Studies and Real-life Applications
  • Closing Remarks on Observability and its Future in DevOps

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

Folge 58: Observability mit Alden Peterson 1/2 [EN]

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Observability (kurz: O11y) ist eine wichtige Komponente von DevOps. Darüber sprechen wir mit dem QA-Experten und Observability-Fanatiker Alden Peterson von Netflix.

Diese Unterhaltung war so fruchtbar und interessant, daß wir uns ein weiteres Mal dazu entschlossen haben, sie in zwei Teile aufzuspalten.

In this episode, the hosts, Luca Ingianni and Falko Werner, along with guest Alden Peterson, delve into the nuances of observability in software engineering, discussing its intersection with QA, DevOps, and SRE. They emphasize the importance of understanding and managing risks in software deployment, highlighting the shift from traditional QA towards a more integrated approach within the software development lifecycle (SDLC). The conversation revolves around the challenges in creating confidence and trust in software systems, the role of observability in different stages of the SDLC, and the impact of team structure and organizational priorities on software quality.

Inhalt

  • Introduction to observability and its relation to QA and DevOps
  • Alden Peterson’s career journey and perspective on software development
  • The concept of observability in software engineering
  • The role of QA in the context of modern software development and deployment
  • Integration of SRE practices and philosophies in QA and DevOps
  • Challenges in maintaining software quality and reliability
  • Importance of confidence and risk management in the software release process
  • Tactical and philosophical approaches to improving software observability
  • Organizational structure and its impact on software development and observability

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

Welcome to a new episode of DevOps auf die Ohren und ins Hirn.
Or in English, DevOps from your ears straight to your brain.
Usually, this is a German-language podcast, but we sometimes make exceptions for international guests.
Today is one such exception.
My name is Luca Ingianni, and I host this podcast together with my colleagues Dirk Sörner and Falko Werner.
We’re DevOps consultants, trainers and coaches, trying to get teams to work together better and create better products for their customers.
Today, it will be Falko and me running the episode.
And we’re joined by Alden Peterson, who has lived in the DevOps and SRE and Observability space.
Alden has worked as an SDET, Software Development Engineer and Test, Systems Development Engineer,
and now a Senior Software Engineer, but has always been passionate about working in the QA and Observability space.
Whether that’s building tools for production monitoring, DevOps tooling, or helping teams understand observability,
he has spent most of his software career working to help teams have better insights and confidence into operating and building software.
Alden, thanks for being here.
Yeah, thank you.
Thank you so much for having me.
So that was quite a mouthful of an introduction.
That sounds like an awesome career.
To be honest, you know, I started my work as a test engineer, and to me, it’s still the most fun of all the different aspects of software development.
Is that the same for you?
Yeah, I like, I like the general space.
It’s interesting to me to see some people really like writing feature code, and like they just live for that.
For me, I get bored because it feels like you’re doing something else.
Yeah, I get bored because it feels like you’re doing something else.
Yeah, I get bored because it feels like you’re doing something else.
I get bored because it feels like you’re doing the same thing over and over again.
And I understand why people would love that, because there’s something to create.
You know, I think one of the challenges, whether it’s DevOps or testing or observability,
is you have a lot less of a tangible thing that you’re making.
You know, you might make a dashboard, or you might make some metrics.
And for a lot of people, that’s just not satisfying.
You know, it’s like you spend two days or a week, and then what do you have?
You know, if you write feature code, it’s like, look at this beautiful UI I wrote.
Or look at this, like, great service I wrote.
And then, you know, kind of in this…
This whole space of, you know, supporting engineering work.
I can understand why people don’t like it.
I personally think it’s fun, because I feel like you get much more interesting challenges,
because you’re always doing something different.
You know, you’re doing kind of the same ultimate goals,
but all of the tools are always different.
So for me, I’ve loved it.
You know, my career has been very strange.
Even before I was in software, I worked as a manufacturing engineer.
So I worked…
You know, my background is actually mechanical engineering.
So I’ve kind of had, like, a very…
Yeah, I’ve had a very…
You know, roundabout way to get into tech.
And I just…
I think it’s interesting.
It is interesting, I suppose, that it seems to me…
Maybe that’s some kind of observation bias,
but there’s a lot of mechanical engineers in, broadly speaking, the QA space.
Yeah, I think that of all of the engineering disciplines,
mechanical engineering is the closest to software,
because, you know, part of the reason I ended up in software
is because programming solves a lot of problems,
in the mechanical engineering space, too.
You know, in my undergraduate, I had some internships
where I basically programmed stuff.
This was in VBA.
So if you’ve ever worked in Excel and VBA,
that was my introduction to learning how to program.
And it was something.
But, you know, there’s a lot of business problems
that you can solve in that space.
And I think, like, mechanical engineering,
of all of the engineering disciplines, has more of that.
And I think, too, a lot of people have this grand idea
in that I’m going to design, like, you know, cars or tractors
or, you know, rocket ships.
And then, you know, you realize that, well,
you might design, like, tiny components
that go into, you know, a larger component of that machine.
And I think a lot of people get a little disillusioned by that,
just because, you know, it’s kind of like what I was talking about before.
You want to own this thing.
And it’s like, I don’t really want to own, like,
you know, a tiny subcomponent of a subcomponent type of thing.
Yeah, what I like about software and mechanical engineering,
since I’m a computer science for engineering master,
so…
I see that it’s helping, like, developing software
for creating and designing mechanical systems
and managing it.
And that’s also a part where you see the difference
and the ways of integrating both ways of work.
Absolutely.
Right.
Anyway, this was a very roundabout way, I think,
of getting to today’s topic.
Which is supposed to be observability.
Alden, what the hell is observability?
Yeah, so I think it’s an interesting question.
So I’ll give a couple different answers,
because I think the answers, the most common answer,
I think, is more of, like, maybe I’ll call it, like,
the classical SRE approach.
So, you know, kind of like Google’s SRE book,
which is, I think, a little bit higher level
than what I would personally define,
but kind of what is going on, right, in the system.
And whether that’s trying to get to some sort of,
you know, kind of, you know, kind of, you know, kind of, you know,
you know, error budget or, you know, uptime percentages
or, you know, monitoring, alerting.
I think that’s where a lot of people gravitate.
I think, from my perspective, it’s more like,
what is giving you confidence that what you’re building
and operating works?
You know, is that, and this is where I think, you know,
when we first met, I think some of our conversations are,
you know, so I’ve kind of lived in the QA space.
I don’t, I have very strong opinions about QA.
And I think longer term QA and SRE and even DevOps
all kind of merge together, because they’re all kind of answering
that same question, which is, how do we know
that we can have confidence that what we’re building works?
And then also, how do we actually do it, right?
So I think, like, there’s an aspect to observability,
which is kind of philosophical, but then tactically,
I think it breaks down, and I can talk more about this, too.
I can go on for a long time, because this is interesting to me.
But, you know, there’s, I think QA is a big part of observability.
I think DevOps, which is very much an overloaded term,
but the DevOps, like, methodology, I think,
is a lot of observability.
You know, if you’re going to,
if you’re going to fully do CICD,
you have to know what’s going on, right?
You can’t just, like, ship code to prod
and just, like, cross your fingers that it works.
You know, if you’re doing really continuous deployment,
you need to have some idea that what I just deployed works.
Maybe that’s metrics coming off the service.
Maybe that’s some smoke testing.
Maybe that’s, you know, some sort of synthetic monitoring,
so you’re running customer, you have to have something.
Otherwise, you have no idea what you’re deploying to prod.
And I think, like, that’s an aspect to observability.
And I guess I’d be curious what you both
would define observability as, too.
I found that it’s one of those terms
that a lot of people have very different interpretations on,
kind of based on their background
and where specifically they look at.
Yeah, that’s an interesting question.
So, because similarly to DevOps,
I’m kind of struggling how to define observability.
I suppose some people define it
from a very technical point of view, right?
It’s, you know, it’s the thing with the dashboards
or something like that.
Same, like, to question,
quite a few people,
DevOps is about CI pipelines,
which in a sense it is,
but on the other hand,
those people, I suppose,
are missing the point, aren’t they?
And maybe that’s the same way
it works for observability, isn’t it?
Yeah, I think from when I think about stuff,
whether it’s observability, QA,
and even really even DevOps,
like, I think it’s easier to define it
with kind of, like, the high-level vision.
So, like, I’ve talked with a lot of folks on my team
that my job is to bring confidence to the SDLC.
So, whether that’s building,
whether that’s releasing,
whether that’s deploying,
whether that’s testing,
all of that sort of parts of the SDLC.
And I think observability is how you actually trust
that your confidence works, right?
You can’t, you know,
you can build this really cool system,
but if you don’t actually understand
what the system is doing,
like, are you really going to get that confidence?
And I think for most people,
that answer is no,
especially when you start considering,
okay, well, maybe the engineers trust this system.
And, like, candidly,
I think engineers are much more willing
to trust really opaque,
like, black box systems that, you know,
they understand it worked at one point
and it probably works now.
But I think once you start expanding more
towards product management
or engineering leadership,
there’s not quite the same confidence that that gives
because, you know,
some sort of bash script
that’s in the build process
that does a bunch of magic
isn’t really going to give your PM
a lot of confidence generally.
And so I think, like,
some of the outward artifacts of,
you know, what are we testing?
What are we monitoring?
What are we seeing
about our production system?
How do we debug errors?
I think you do need something more dashboardy.
I don’t like calling it just dashboards
because there’s so much more to this
than just dashboards,
but you need something more tangible
so that you can actually have conversations with people
other than the people
who are very intimately aware of the system.
That’s so interesting.
This whole conversation about trust,
like, can you trust your system?
Can you know that it works,
like, you know, on a visceral level?
Yeah, that’s the word I often use is confidence
because I think, I mean,
if you work in the tech world very long,
you’ll know, like,
you’re never going to have 100% confidence, right?
Because, you know, like, last, was it December?
Log4j, right?
I don’t think anybody on the planet would have thought,
oh, you know, I’m going to expect that a core library
in the Java library is going to cause a giant headache.
It’s like, there’s reasonable assumptions you take.
And I think when we start thinking about confidence,
one of the reasons I like thinking about it in this way
is that it’s just a risk analysis.
Right?
You’re wanting to lower the risk of whatever,
you know, whether that’s buggy features,
whether that’s, I don’t know,
one of the things we’ve been dealing with is
someone’s basically doing a denial of service attack
on one of our services.
You know, you’re wanting confidence
that you can handle those sorts of things,
but also that it just works.
And I think one of the interesting parts of observability,
and this goes across whether it’s kind of
the DevOps aspects of observability,
the SRE aspects or the QA aspects,
is you could spend years on a relatively basic system
to get 100% confidence.
And you won’t get 100%,
but maybe you get five nines of confidence
or something silly.
You know, but like all of us work in companies
where we can’t just dedicate that much effort into things.
And so you have to be very pragmatic about,
okay, what is actually important to do?
And for me, I think that’s an interesting thing
because it’s just, you have to make analysis
around what gives you that confidence.
And whether you call that trust,
I think trust is a very similar thing.
I think I would probably call that the same.
I think Luca used the word trust, confidence.
The word,
I like the word confidence
because I think for non-engineers,
I find that word resonates more
because I think people outside of the engineering space
are like, I don’t know.
Like, I don’t know if this is going to work.
Like, you guys are releasing this large chunk of software
and how do we know it’s going to work?
You know, I think there’s a confidence factor there
that it just, it resonates more.
But I think it’s basically trust, right?
It’s both.
It’s both feelings from what I would say.
So how do you get those types of,
feelings into people?
So what do they need to be trusty
or to have confidence in the product?
So that’s a really interesting question
because I think that can depend entirely
on what the existing failure modes have been,
as well as kind of the more holistic,
what should you be doing with, you know,
I’m saying should, should is maybe not the right word.
What is the ideal instrumentation, telemetry,
whatever observability aspects?
You know, I think one of the interesting things,
I joined my current team the end of last year
and it was interesting because some of the major pain points
that my team was having were very specific
to certain failure modes.
Like we were just, we had random production blips,
like stuff just, and it was like two, three minutes.
And so it was very hard to track down.
And so it was from a confidence perspective,
it’s a lot easier if you say, okay, well,
I’m going to like prove that those are happening
because now you can prove that they’re not happening.
And so on my team, that’s a very,
that was a very key thing for me when I first joined was,
okay, let’s set up some just like really basic checks
to see what our site’s doing on a regular basis.
And so in that case, that’s a major confidence booster.
Well, it’s a major insight into what is causing
the lack of confidence, I should say.
Knowing that your site goes down on knowing the exact times
is actually confidence inspiring
versus it just randomly goes down
and we don’t understand it,
but we know we get random customer reports
that we can’t really reproduce.
And I think like one of the challenges,
and so one of the reasons I think like the QA,
SRE, DevOps space all kind of eventually merge together,
is because I think one of the pitfalls
of having those as separate orgs or separate silos
or separate disciplines or whatever you want to call that,
is that each of those has a very different answer
to the question that you just asked.
Because QA, for example, is going to say,
well, any bugs are problems.
You know, DevOps, if I broadly generalize
and say anybody with a DevOps title,
which we could probably have a whole conversation
and that nobody should have a DevOps title,
but that’s a common enough thing in orgs still,
that that’s like, well, the infrastructure,
underlying infrastructure is stable.
And, you know, if you’re an SRE,
like how do those kind of interact together?
But like you’re more looking at much more
of the customer impacting aspect of that.
And I think like all of those are parts
of the answer to the question that you just asked.
And I think one of the challenges is,
especially in an orgs,
if you’re like a dedicated QA org
and a dedicated like some sort of infrastructure organization,
you end up with each of those groups
caring about very specific windows
into that observability question.
And then I don’t know that I’ve seen,
at least in my experience,
I would actually be curious if you both have seen this,
but I don’t see a lot of reconciliation
of how all of those pieces fit together
because they all do fit together, right?
You know, if you have an,
let’s say your infrastructure is bad,
you know, and one of my previous companies,
we dealt with this all the time.
We ran into all sorts of failures on like test deployments
because the infrastructure underlying
the whole thing was just flaky.
And so is that like a QA problem?
Is that an infrastructure problem?
It’s like, no, it’s like,
it’s this confidence observability issue, right?
Yeah, but isn’t this exactly
this model of the wall of confusion
that, you know, is this sort of founding myth of DevOps, right?
That you don’t make this distinction of,
you know, production being up is Ops‘ problem
and bugs not being present is Dev’s problem.
And you replace that by the common perspective,
are we providing value to the customer?
By, you know, shipping a feature
and making sure that it’s stable.
If we can’t achieve both of those,
then we’re all, you know, missing the point, aren’t we?
Yeah, I completely agree
with that.
That’s one of the things I struggle with
is what do I describe myself as?
You know, like, I don’t want to be a,
I’m not a DevOps engineer.
I’m not a QA person.
And so I’ve started calling myself an applied SRE.
This isn’t really the right terminology
because there’s a whole bunch of pitfalls
with that title too.
But like, I like the idea.
And, you know, Luca, to your point,
I think you want someone on the team
who can think about those sorts of things.
And like, that’s the team question, you know,
like the full stack engineer approach
has become really common.
And that’s in an ideal world.
Then your team owns, you know, your infrastructure,
you own your deployments, you own everything.
And then the team can be responsible for that.
But you need that team, someone on the team
to kind of understand and care about this issue.
And that’s, in my experience,
one of the challenges in this space
is that there’s so much going on
from a prioritization perspective
that is very challenging for folks to really,
not so much care, but have the ability to care.
You know, if you’re required to ship features
and kind of you’re accountable for features,
observability can very easily slip away.
And whether that’s observability through like testing,
whether that’s observability through monitoring,
whether that’s pipeline, you know,
like the more quote unquote DevOps-y side
of the release process,
it’s very easy in my experience
to see that kind of slip away as a secondary concern,
which, you know, I’m pretty pragmatic.
Sometimes that is the case.
You know, if you’re a startup,
like you might not have the budget
to like survive long enough
if, you know, you don’t ship feature code.
You know, you might,
your company might die.
You know, you might go bankrupt
if you don’t have feature code.
In which case, yet again,
you’re not providing value to the customer.
So you can still very easily loop it back to,
am I offering the best value to my customer,
either through stability or through my existence?
Yeah, and that’s like,
I think one of the things that I like doing,
I haven’t really thought of the phrasing,
the value to the customer.
I think that’s very similar
to kind of what I’ve thought about this
because you want to determine like what actually matters.
You know, not being like,
oh, we need monitoring
because we need monitoring
for the sake of monitoring.
Like, I think all of us would probably agree,
monitoring is most always valuable,
but that doesn’t mean that every single project
needs somebody who’s, you know,
creating tons of dashboards and tons of metrics.
Like, because at some points it just doesn’t matter.
You know, if you build an internal app,
you know, one of the apps I used,
I wrote years ago now,
was a team.
I sat on the team.
I was on the team I was writing this for
and I had some like really basic error handling.
So any error got emailed to me.
You know, I wouldn’t really say
this is like the best observability,
but it was good.
It was good enough for that team
because the most, you know,
they sat next to me.
You know, if something really went wrong,
they would just walk over 10,
you know, a meter, five meters, whatever,
and go say, hey, Alden, what’s up with this?
It’s like, you know,
there’s a different level of observability there.
And I think it’s just,
it is a challenge because I have found,
especially in the QA space,
that there’s a very like idealistic approach
when it comes to a lot of the things.
It’s like, you need to do this
because this is important.
And it misses the practical realities
that everybody’s busy
and there’s,
there’s almost always more
than you can do than actually do.
And I think really to what you,
the way you’re describing it is kind of,
I actually like,
I’ll probably steal that
and use that terminology
because I think that is like a better way
to talk about that trade-off.
It’s also interesting
what you talked about in terms of,
do you treat this as a QA problem
or how do you look at it?
It reminds me of myself
when I decided
I was going to be a freelancer.
I thought, you know what?
I’m going to be a professional QA person
because testing,
it’s fun.
This is, you know,
this is going to be awesome.
And I came to the shocking realization
that I could not actually
offer quality to my customers
unless I took control
of the entire SDLC.
And so I accidentally found myself
doing DevOps by necessity.
That was,
that’s so funny
because that is how I got into DevOps,
sort of falling backwards into it.
Yeah.
And that’s very similar to my approach.
My first,
I guess,
you could call it a QA job
was when I was hired as an SDET
or Software Development Engineer and Test,
which speaking of titles
that are kind of meaningless.
But, you know,
one of the first things
that I did on that team
was I realized like the PR process
just was bad
because the build took forever.
And so people would, you know,
just not really pay attention to it.
And it was just a headache.
And really,
I think one of the first things
I did on that team
that really improved
the overall quality of the products,
I just reduced the entire CI process time.
But, you know,
and in that case,
nobody had looked at it.
It was really,
it was years later,
so I can say,
it was pretty easy
if you just look at it
and spend the time to do it.
I think it was something like
an 80% reduction
in the total CI time.
And it’s like,
nobody just put the time
in to look at that.
You know,
I think part of it is,
that is like a QA concern,
I think.
I’ve talked to a lot of people,
like,
I think QA,
you end up going to the DevOps side
for the exact same reasons
you were talking about, Luca,
that you end up with,
okay,
so I can write a bunch of tests,
but like a bunch of tests don’t matter
because when do I write,
when do I execute these tests?
How do they get executed?
Well,
you have to think about
where the deployment process is.
Okay,
now you’re talking about
the deployment process,
so now you’re thinking about
the pipeline,
if you’re using some sort
of pipeline thing.
And now suddenly,
you’re thinking about
like the whole DevOps philosophy.
And I think that
that’s almost a requirement
if you want to have
like a QA process
that’s not just write some tests
that get executed
against like a,
you know,
I don’t know,
a build or a test environment.
Yeah, okay.
So,
what is
the
requirement
I don’t know,
system of
observability
looking into?
Is it
all of those things?
The software itself?
The pipeline?
The people?
I think,
yeah.
I think a lot of this
will again depend on
what your role is
on the team.
Because I think
like leadership will say
it’s all of those.
I don’t know that,
I mean,
it’s a challenge, right?
Because where does that,
where does that bubble stop?
You know,
one of the things that I’ve,
I’ve often told people
is that
most of the
hard technical problems
aren’t really technical problems,
but they’re like a mix
of how people and technology
are interacting.
And I think observability
is almost
perfectly in this, right?
Like one of the things
that I’ve talked to
a lot of people about
is I tell people,
if you’re not
going to action an alert,
either turn it off entirely
or put it into a channel
that’s basically
like ignored alerts
or something.
You know,
some people just have
like an obsessive,
I really want to see
all these alerts
because I don’t,
I don’t understand it.
I can’t empathize with it
because for me,
any sort of alert noise
just drives me nuts.
But some people really
have a hard time
turning off an alert
that they know is valuable
but don’t do anything with.
And I think like
that’s a very interesting
combination of like
a people
and a technology thing,
right?
Because you can have
a bunch of valid alerts
that should be
done something with.
But if nobody’s
doing something with them,
is that a technology problem
or is that a people problem?
And I don’t think
you can answer that
either way.
I think it’s a mix
because, you know,
maybe there’s an aspect
to people want to,
but they’re just
so overloaded
because they have so many,
maybe product management
is pushing a ton of like
we need to do feature,
feature, feature.
And, you know,
the poor engineers
are just feeling guilty
about these alerts
they’re ignoring.
You know,
that’s probably
not a common situation.
Sometimes people
just don’t care.
You know,
some automated template
creates a bunch of alerts
and then there’s,
you know,
either they don’t understand
why the alerts
could be useful
or they don’t correlate
to any sort of,
you know,
customer impacts.
So it’s kind of just like,
well, whatever.
And I think it’s,
I think it’s definitely a mix.
I think it’s easier
to focus on the technical side.
And I think this is
one of the things
where I think,
you know,
going back to the beginning,
I think a lot of observability
stuff that I’ve read
focuses more
on the technical side
because it’s easier
to quantify.
You know,
it’s easier to look at,
okay,
you need to,
okay,
like let’s look at
availability and uptime,
right?
Like this is a good example.
It’s,
you can measure it,
you know,
and people like metrics,
you know,
it’s a good,
and the metrics are valuable
and it’s easier to say,
okay,
we’re making an impact
because we went from,
I don’t know,
98% uptime
to 99.5%
or,
you know,
something like that.
And I think like a lot of times
the people aspect
can get missed
because it’s harder.
You know,
you’re both consultants,
so you probably deal
with this all the time.
You’re basically doing,
I would guess,
and this is speculation
since I’m not on your roles,
but I would guess
that the technical parts
are really easy.
It’s the parts,
like getting people
to adopt them
and changing people’s
either preconceived notions
or some of the,
you know,
organizational challenges
that make doing
more of DevOps harder.
Like that’s,
that’s been the experience
I’ve had.
I would,
I’m actually really curious
if that’s how
you would both say it
to you from kind of
the consulting side
doing on that
DevOps-y side.
Yeah,
it’s both,
I think.
You have to have
people with the skills
to get the things
up and running
and to find
a good starting point
to measure.
I think sometimes
you have no measurements
at all
except how many
bugs or service requests
or,
or issues are coming in.
So that’s kind of
the first level
of transparency
or measurement
or looking into
service availability
or uptime,
whatever.
And then when you start,
you get into it
step by step
and need to develop skills
in terms of tools,
in terms of
how to work
with the data
that you can get.
And measure the,
the important things
or at least alert
on the things
that are helpful
for the customers,
for the team as well.
I would even want
to step one step
further back
and try to get
a better handle
on observability.
I think it’s
a broad term
kind of
getting lots of things
together.
You said in a
quite abstract way
create content,
confidence,
or Lukas said
in also similar way
to create trust
or build trust.
I think when I,
when I hear the term
without the,
that deep view
on the technology side,
I feel it’s making things visible
that are somewhere hidden
in the black box system
that you,
that you mentioned
in the processes,
in the tools,
in the tool chains.
What is there
to promote
a solution
to a way
to make
better
the people
in your place
and one that
I think
we need
to say
it can be
or can be
anbeeping
over
I mean
yeah,
it’s still
different
now
from
from
one
view one observability i think that’s that’s good i don’t know that i would say that that’s less
abstract um i think like to make it more more tangible i think it’s really like can you easily
understand what’s going on and maybe that’s maybe that’s just a shorter way to say what you were
saying it might just be a shorter way but i think like so one of the things i really like doing is
setting up synthetic transactions and so like basically a synthetic transaction is hey what’s
a common customer action or behavior whether that’s like a ui you know clicking through an
actual web interface or whether that’s an api call you know whatever your customer is and just
setting up a scheduled version of that because and one of the reasons i like that is because
it bypasses a lot of the pitfalls of like tuning alerts tuning metrics and that sort of thing and
you basically say this is what we’re defining our thing that does you know maybe i don’t know
maybe it’s a you know i’m trying to think of example you know maybe maybe you have some sort
of like
basic i don’t know payment system we’ll run a like figure out a way to run a fake payment
through that system run it every minute or every five minutes or whatever and this comes down to
like what’s the customer expectations on this but you know if you run that every minute it’s kind of
a non-negotiable this is what our system is supposed to do and if this fails it’s a big deal
type of thing and one of the reasons i like doing that and i i think that’s a very insightful thing
because at first it forces you to define what is that critical path for your service or your
website or whatever you know whatever the
application here is it can be a this applies across whether you run like an amazon.com level
website or whether you just have a simple web service that’s kind of a you know a microservice
your app does something fundamental that your customers or users have an expectation of
and just verify that that works and i think one of the reasons i like doing that is because
it simplifies a lot of the complexity around well what is like what what’s confidence what
like all of those things it’s like no we’ve this is like
what our thing is supposed to do and it stopped doing it that’s a problem you know and maybe we’ll
Maybe latency matters, maybe latency doesn’t matter.
You know, you can like build into that sort of really simple check a lot of useful things.
And then you also have a repeatable environment to run it from, too.
One of the challenges in using like real user monitoring, which I’m sure you’re both familiar with at RUM,
is that maybe you have the one person who’s off on, you know, rural Internet in the middle of nowhere
and their site just doesn’t work because, and it’s not because of your site,
it’s because, you know, they’ve got, you know, 20 bits per second of, you know, Internet speed.
And you don’t necessarily know that from metrics.
And in my experience, tuning metrics can be a lot of work, especially for lower volume sites.
You know, if you run a site like Amazon.com or, you know, Netflix.com or something,
where you’re getting millions upon millions of like customer interactions potentially per second,
it becomes a lot easier to define like actual metrics based on site interactions because you have so much data available.
But a lot of us work in spaces where we don’t have that level of clear impacting like data.
And in those cases…
I really think like just doing like some sort of basic synthetic transaction can sort of answer the question that you’re asking, Falco,
because it’s basically what is our, what does this do?
Like, what is, what is the core value proposition?
You know, like we were on this like podcasting app now, like maybe they should just, that like a good example there was like,
just start a podcast and verify like stuff works, you know, that’s, you know, the Zencastr podcast.
That’s, you know, it’s kind of like they’ve got one thing, right?
Like it’s to record and create podcasts.
And so.
So if they wanted to know that, they could certainly try to look at metrics.
I don’t know how many people use this site, you know, maybe there’s enough people using this that they could just look at how many podcasts get started and saved every X minutes and figure it out.
I don’t know, but you know, my guess is it’s one of the sites where, you know, if you looked at, you know, midnight on Friday night, there’s probably not a lot of people that recording podcasts, you know, or, you know, like that’s, you know, one of my previous apps was heavily business cycle dependent.
So we basically made an app that was used as a business app.
Well, yeah, I’m like midnight on Saturday that almost nobody was using it.
But if somebody was using it.
At that time, it was really, really important because that meant some like person was doing some work that was like really time sensitive, generally.
And so we had to be very mindful of that because you can look at your metrics and say, OK, great, our app is running.
But then, OK, Friday night comes and no user traffic and somebody takes down the cluster by accident and now you don’t even know if that app is failing.
That’s I could talk a lot about this because I think synthetic transactions are a really good way to bypass a lot of the pitfalls with observability because you’re you don’t have to tune anything.
You basically decide what’s the key thing here.
OK, but now I need to ask you a question because I’m kind of confused.
Is there a difference between observability and using synthetic test cases and just fairly regular acceptance tests?
Well, so that I think is a good question, because I think acceptance tests in some ways can be useful as synthetic transactions.
I don’t know that I I’m not a huge fan of to the point where you have to.
Run like a large test suite against product.
I don’t I think you can do that.
But I think if you’re feeling like you need to do that, it probably means you have gaps elsewhere in your process.
So, like, for example, if you I guess let me take a step back.
I think acceptance tests should be a lot more about verifying like functionality works and the integration pieces are correct rather than necessarily is my app like core business logic working.
And so in previous companies, what I’ve what I’ve done and actually talked to people about is maybe you have 100 either acceptance integration tests.
Whatever tests that you run against a deployed environment, you don’t need to run all 100 of those as synthetics, but you might just be able to say, okay, these two are actually the core.
So we’ll run those two.
And I think this is part of why I think like observability, QA, DevOps, SRE, all of that morphs together, because when you start thinking about it from this perspective, what you just said is a very natural thing, right?
Like, let’s say you have a QA org that writes tests against the test environment and engineering org owns production monitoring, which I think is a real, really common situation, actually.
Is.
Yeah.
So maybe at this point, we really need to pull back a little bit and kind of figure out what is the relationship between QA and SRE?
And DevOps and observability, and if you want also SRE, how do they fit together?
How are they, how are they traditionally viewed as separate and should they be viewed that same way still?
I’m guessing your answer will be no.
Yeah.
So I think from my perspective, the QA industry is undergoing a similar transition that kind of the systems administrator, DevOps side of did.
And I mean, it’s still it’s still undergoing.
But and that is.
I think people are recognizing that you can’t have the siloed component to your your your engineering org as a broader whole, because with it with SAS, I guess we should probably clarify a lot of this mostly applies to SAS, because it’s very easy, for example, to roll back software in the SAS space.
Generally, you know, one of my previous companies, I worked for John Deere, and if we you know, one of the teams that I was close to the team I was on, they did the firmware update types of stuff.
So they would do over the wire updates.
Well, that’s a very different failure mode if you screw that up.
You could potentially like brick or prevent every single piece of equipment that’s on the field from working.
That’s a very different failure mode.
And so I think with SAS, it’s a little easier to to trust in like a process that will auto roll back, for example.
And so that disclaimer aside, I think QA historically has tried to answer like, do we have bugs in the product?
And often that happens on like, do we have bugs in the product?
Let’s make sure we don’t have bugs in the product before we deploy to production.
I think that’s I’m generalizing horribly.
But I think that’s a pretty decent explanation of what QA often is.
And so you will often see orgs who have quality problems say, let’s hire a bunch of QA people so we can make sure we don’t have bugs before we ship it to the customer.
Well, that’s so interesting.
I’d never thought about it in those terms.
But it sounds like what you’re saying is the the harder it is for you to deploy software, you know, either for reasons within your product, like, you know, it’s a tractor or because your processes are just terrible.
So so the harder it is to deploy into prod, the more you need a separate QA stage and a separate QA team, but make sure that nothing bad goes into prod.
Yeah, I think that’s I think that’s a fair statement.
I think there is an aspect to this that if you’ve made the process hard and it doesn’t have to be hard, you create a higher chance that you have issues, you know, like if let’s say you have, like going back to this podcast, let’s say they push updates once a year.
Well, it’s almost guaranteed.
Like I think most people in tech would say that’s probably more likely to come back.
Yeah.
major issues than if they ship once a week or every commit or some variant on that. So I think
you do have to be a little careful. Now, that being said, I think like oftentimes people’s
first tendency is, okay, we have quality problems. Let’s batch up all of our releases so we can
make sure that they work right. And you kind of get yourself into this cycle.
But I think one of the things I try to be careful of is in these sorts of conversation is
recognizing there are valid cases where a lot of this is, there’s just different constraints.
I’m not sure, the spaces I’ve lived in and I actually much prefer because of this are like
the SaaS spaces where we’re deploying some sort of web application or some sort of internal service
that it’s really nice to not have to worry about a lot of like, you know, I’ve not worked for
companies where there’s major compliancy things, you know, like this whole conversation changes a
little bit if you start talking about, well, maybe you make medical software, you know, or maybe you
make software for governmental approval processes. But I’m so I’m just kind of ignoring that space.
There’s a, I’m probably not the right person for that because there’s a lot of regulatory issues
there.
Yeah, but let me speak to that a little bit, because I have worked on safety critical
software before, like up to ACLD, which means that if your component fails, somebody’s going
to die. And that does influence the way you build your product, doesn’t it? But it only really
changes sort of the last step, which is actually moving it into production, like bolting it into
a vehicle in our case. All of the rest is still very much the same. And, and, and, and, and, and,
but all of these considerations that we talked about in terms of production software would maybe
just be, you know, would be worked on in a pre-production setting, you know, if it’s a
physical thing, you know, in a, in a prototype environment, in a test drive environment,
stuff like that. So we’re still back to the same confidence conversation. We just need to be,
we just need to be sure that our confidence level is way, way higher before we actually
unleash this on the unsuspecting public, right? Right. You know, and,
and this conversation has been pretty philosophical. And I think one of the
things that from my perspective is the case is that a lot of the way you help
influence people on this topic is just thinking about this differently. You know, I think we,
we’ve had a lot of like higher level conversation here, like without as much tactical stuff. And I,
I think that’s, from my perspective, that’s the hard part. The tactical part often is pretty
straightforward, but that’s also very specific to whether it’s the constraints that you’re dealing
with. You know, we were just talking about, you know, whether it’s safety critical software,
there’s going to be different constraints than,
I don’t know, making like the next social media app. But I think like one of the things is like
this whole philosophy. I think if you’re really thinking about observability from a more holistic
perspective and you’re really understanding what is it, what is this idea of observability trying
to do? I think it really translates really nicely to any of the domains that you’re in. You know,
a lot of the times it’s like, and this is something I have definitely experienced is if you’ve worked
in a place where you have decent observability around your software process, I love writing
code in that situation because I, I just don’t worry. You know, I trust that if I merge code,
it’s going to, I’ll either, it’ll either work. It’ll either be some weird edge case I didn’t
know about, or I’ll get an alert or something will fail. And I love that. And I think like
that observability, like is like kind of the key to get you there. And, and again, I think like
this, cause we were, I think talking about this right at the beginning, you know, what is the,
where is the boundary of observability? And I think you can make it wherever you want. You can
really tightly scope it to say like observability.
Is production monitoring and production alerting. And I think, I mean, I guess you could do that,
but I think really you’re trying to like that confidence answer is the whole process. You can
even say like build time observability too. You know, a lot of people have like dealing issues
with flaky tests. Like that’s a common thing and we can call it flaky unit tests, flaky integration
tests, whatever. Well, like if you don’t know, like, let’s say that one of them is super flaky
all the time. It’s going to, it’s going to like break your confidence in the bill and it’s going
to break your confidence that like those unit tests are actually useful.
And maybe you just don’t understand like, like that test fails 50% of the time. And like,
I think some of the newer like APM like tools are doing a lot of work in this space. Like
Datadog I know is building, it’s some sort of flaky test detector. And part of the reason is
because if you can start getting rid of those false positives, you know, it’s the same as
alerting. You know, if you’re dealing with production alerts, false positives are the worst,
you know, especially if you’re talking about paging. You know, if you page someone with a
false positive, you’re basically ruining the ability for people to care about production
pages very quickly. Because, you know, it’s, it’s, it’s, it’s the natural human instinct. If
you keep telling me, hey, something’s on fire and I look and it’s like nothing on fire. And then you
do it five times in a row. Like it’s totally, it’s a normal human response. I think I don’t
fault people at all for not paying attention or not caring about things. Like, why would you care
about, you know, if you get an, if you have an alert channel, that is a stream of alerts that
nobody cares about because they’re pointless. And then there’s one that matters. Why wouldn’t
the world, would somebody actually look at that? But I think like, there’s an aspect to
this where all of this kind of this thinking approach in this philosophy approach is very
useful for creating more of the tactical side of things on like, what, what does that look like
tactically? Well, it’s going to look different tactically. One of, one of the challenges I have
when I talk with people is people, I’ve had a lot of conversations now where it’s something along
the lines of, hey, we’re thinking about QA. We don’t really know what we want and we don’t really
want QA, but we like know you’ve got opinions on this topic. What’s, what’s, what, how to think
about this?
And a lot of times people are basically saying like, we lack confidence in our release process.
We lack confidence in production monitoring, but we don’t know how to talk about it. I don’t know,
I’m sure if that makes sense, but I think like it’s, it’s harder for me to tactically like
describe, you know, a lot of times I think people are looking for like, here, what are the five
things I can do? You know, like I, we have observability problems, we have quality problems,
we have observability problems, we have whatever. And people are like, give me the five tactical
things. And I think people like jump to that. And I think it’s more, you need to think about it,
like kind of the way we’ve been talking about it.
And then the tactical things become really obvious, I think, because, you know, like you
know, it might look like something like I’m trying to think here, maybe, maybe you have production
incidents that take two hours to debug because you can’t figure out what’s going on. Like that’s a
really clear tactical win pretty quickly. You know, there’s, there’s a lot of the philosophical
side of things that I think translates at an organization level pretty easily. And I think
that applies really like this whole space, you know, whether that’s, I’m kind of going on like a
rabbit, rabbit trail, as they say.
But like, you know, QA is the same thing, observability, whether that’s like the SDLC
observability, whether that’s a DevOps side of things and how the infrastructure works, how that
all works, like any, it’s, it’s all kind of the same thing.
Yeah. And I think what the, what the thing is, is the system, which is, you know, the product
itself, plus the people building it and operating it, this whole looping structure, you know,
feedback structure.
And this is, I think, where it closes the loop and where you say, you know, if I have flaky tests, well, that breaks that system, doesn’t it? It doesn’t break it in the, in the, let’s call it forward direction of, you know, features flowing towards the customer, but it does break the feedback direction. And as such, it will break the system as a whole.
Yeah.
I think Falco, you were asking this question earlier, like, is it a people or is it a technology thing? And I think this is why it’s hard for me to answer that. You know, when it, when we think about more of like, do you have production, like for more of like the production monitoring or production kind of incident responses? Yes, it’s both. You know, look at what you’re saying. Do you have runbooks?
I think it’s a hard to answer at all, because the system is both the technology and the people. If you don’t have the people as the sort of reactive, creative part of the system, then you’re not going to be able to do that.
If you don’t have the people as the sort of reactive, creative part of the system, then, you know, who’s going to react to problems? Of course, it’s going to be the people. Yes, of course, they need technological support, be it dashboards or be it something else that, that enables them to observe what’s going on, hence observability, and react to it in a meaningful way. But I think here we are.
Okay. But are you measuring or evaluating the responses of the human or social part of the system as well?
Is this part of observability? Do you look into it?
So that that is a harder question for me to answer. And I think the reason that it’s harder is, I would answer yes. But I think I’m also aware that that becomes very challenging based on where people’s abilities to influence and organizations are to say yes. I think for the average engineer, I think the answer to that’s more of a no, because so much of that is organizational and prioritization. Like, for example, I think we at the very beginning, we were talking a little bit about whether if you’re being pushed to create features.
You know, if you’re getting like, let’s say 100% of your bandwidth is allocated towards feature development, and you want to put time into, say, observability or monitoring or testing or any of that sort of stuff. It’s hard for me to say that that’s the engineers problem to deal with. That’s a much more of an organizational issue as far as how the organization prioritizes the SDLC engineering work. And I think, so I think it depends on your role. And I don’t. So if like, let’s say if you’re an engineering manager listening to this, or a
Let’s say, if you’re an engineering manager listening to this
or a PM listening to this, I think the answer
is a lot more of, yeah, it’s your
responsibility to balance.
We had
a relatively minor incident
recently, but I was very
glad we had it, because it was a very clear
okay, these are the areas
we have problems addressing
this incident. And if we have a real issue,
unlike when this product is more actively used,
we’re going to have some serious issues because of these
things. And that was very easy for our PM
to go, wow, yeah, okay, let’s prioritize.
And so I think, I don’t know if I’d call
that a metric.
It’s not a metric. You can’t quantify it.
What are the gaps? But being able to quantify the risks
I think is really helpful. And you can call
that a metric. I mean, you can’t put a specific
risk to it. But I think that’s
one of the things from my perspective that I think
is really important in this whole thing, too. Because
let’s be honest, the reality is
we’re never, most
of us work in non-life-or-death
situations. Luca, you were talking about that
people could potentially die in your thing.
Most of us don’t work on that.
That type of system. And so the reality
is, when we talk about the risk trade-off
of how do we get confidence,
the desired confidence doesn’t
have to be 100.0%.
Most of us are, I don’t know what percentage,
I don’t want to put a number here because I’ll get
a bunch of people saying, oh, it needs to be slightly
higher. But most of us are below 100%
for what we need from a business perspective
confidence. But you need to be able
to more tangibly say,
okay, we don’t have good logging,
we don’t have good monitoring, we don’t have
good understanding.
So if we have another issue in Pro, we might have to
wait several hours
to make a new bill that has more debugging
or something like that. I think being
able to quantify that from an engineering perspective
can be still useful. But ultimately
I think if you live in an organization
where the value incentive structure is
just not going to support that, I don’t think you can really
you’re kind of stuck. And so that’s where
I think it’s hard to say it’s a people problem
as an engineer. But I think, yeah, if you’re in the leadership
role or you have influence on this, it’s absolutely a mix
of both.
I’m also sort of thinking,
back to
when I was working in safety-critical
products, having this awareness
that people’s lives depended
on you doing your job well
gave a lot of clarity to those conversations
because, you know, it was much
easier to say, no, I don’t feel
confident shipping this yet. And everybody
would be like, oh, okay.
It’s like, okay, fine, we have deadlines, but
also we potentially
have dead people. So
I know where my trade-off lies.
One of the reasons I don’t like
having a separate QA org is because I think
you want the QA org to be responsible for
answering that same type of, more of a risk
analysis rather than a we don’t want bugs.
Because in companies that
there’s a separate QA org, I think what happens
is QA feels responsible for stopping
all bugs, period. Not
stopping enough bugs to justify
still shipping. And so I think one of
the reasons I’m pretty passionate that I think
QA should be ultimately
reporting to some, the
leader who’s responsible for the product, whether
that’s a first-line engineering manager,
whether that’s a director, it doesn’t really matter.
But I think QA is providing that insight.
And this goes back to your question, Falco, really
about people are process or people
are technology. Yeah, QA
needs to bring the risks up. But if
ultimately product or engineering
or whoever’s making that decision says that’s an
acceptable risk, I don’t have a problem
with that. As long as it’s an
intentional decision. I do have a problem if it’s a
non-intentional decision and it just happens.
And I think that’s unfortunately often the case
where people don’t consciously
think about it and just say, well, we need to ship this away.
Yeah. And yet
again, this reminds me of like
one of the projects I was working on was
a steering column lock. So it was
an amazingly stupid
piece of hardware. It could go click or clack,
right?
And there was a very
because it was safety
critical, there was a very deliberate,
very careful risk assessment. And of
course, the assessment said, actually,
it opening at the wrong point in time
is completely
irrelevant. Like, whatever, let it open.
The only people
who are going to complain about it are the
car insurance, whatever.
But if you’re going
200 kilometers an hour down the autobahn
and this thing closes,
you’re going to have a bad day. And having
this clarity about your risk assessment.
And so for the same sort of bolt
moving, we had very different
risk assessments for it moving forwards and for it
moving backwards. One was
whatever and the other one was highly, highly
safety critical. And by the way,
even in this case, we couldn’t
possibly go for 100% safety
because that would have required
infinite effort.
Yeah, that’s a good example, too. We’ve been talking
about this. One of the interesting
things to me in a lot of this space, and I think
having a mechanical engineering background,
we’re both coming from a very different
background, but it’s
observability. I think
in tech, there’s a common thing like, oh, this is
like, we are like unique, special
industry. We’re the only industry that ever deals with
problem XYZ.
And I don’t know,
maybe it’s because I came from a different
industry. I just, it’s not that
way. And so it’s
that issue you’re talking
about, I think it’s like the same thing that
at a core observability
and monitoring, it’s all trying to answer
there, right?
Other industries have the same
challenges, too.
And maybe that’s why it’s easier for me to think
about this in more of a philosophical sense.
When I was an intern, I was working on a project with
an
anhydrous ammonia, which is not
something you want to be around if it goes
wrong. It’s a bad day because
it’s a very dangerous thing.
It’s using farming and fertilizing.
And it’s kind of the same thing you were just
talking about, right? There’s a very different risk
factor there. We were doing something because
farmers are
less, they’re very prone
to just doing what they want because they want
to do it and like customizing stuff. So you have to be really
careful because it’s not just like somebody
randomly shifting wrong on the interstate
or on the autobahn. It’s like, oh, I want
this just to work differently. So I’m going to go in and like,
change how this works, types of things. And it
is, it’s just, it’s different failure mode, but it’s like the
same problems. You know, you have, you have the same thing
like, is this working the way it’s supposed to? You have all of
these problems you have. Then you want to build
systems to prevent it from, from being,
you know, like in that case, like a safety concern.
But, you know, it’s fundamentally like you
want to build processes to prevent
and be aware of when things aren’t working right.
Well, it’s like, that’s like the same thing
we’ve just been talking about in the software industry.
You know, like, yes,
it’s the exact same thing. It’s now
certainly that the tooling is different.
You know, you’re not going to put like synthetic
transactions that, you know, going back to that
on these sorts of things, but like
it’s the same fundamental philosophy.
And that’s, I think earlier I was
talking about that. And I think back to that point
of it’s the way you like help people
influence people is you just think about it like this.
You know, I think
all of us probably just kind of naturally
think about this as kind of a risk
assessment or prioritization assessment
when you’re talking to people.
Like, I think we all naturally think of it that way
just because of the nature of our roles. But
I don’t know that a lot of people
see it as like a, it’s just more, well,
I’m not directly responsible for this. So
I have a whole bunch of other work. So I guess
I’ll do that. You know, I don’t think people are consciously
doing this. But that’s one of the things I’ve talked to a lot of people
internally here about is, if this
is good and you want to make it, if you’ve believed in
this as a priority, then you have to shift priorities.
Period. You can’t just like tack it on.
Okay. Dear listeners,
as we were recording this podcast,
we discovered that we
couldn’t really do the topic justice
in just one episode. And so
while we were doing the recording, we
decided we were going to keep going
and record a second half
of this conversation and publish that
as a separate episode.
So this is the end of this
first episode, which was maybe on
a somewhat higher level,
on more of a level of
philosophy of culture. And in
the next episode, we will
try to go down to a more
practical level and talk about
how to actually approach, how to actually
implement observability
in your own organizations, in your own products.
So please stay tuned for
the second episode of this conversation,
for the second half of this conversation with Alden,
which I think you’ll enjoy
greatly. I know I did.
Thank you.

Dierk und Luca bei APMG LevelUp

Dierk und Luca waren beim APMG LevelUp Event als Diskussionsteilnehmer eingeladen. Das Thema war: „After Service Management, should I learn DevOps and SRE?“

Die Unterhaltung streifte verschiedene Sichtweisen auf SRE, DevOps und ITIL, und wie man die drei Ansätze am besten in Einklang bringen könnte.

Dierk und mir hat es gut gefallen: die Diskussionen waren fachlich spannend und menschlich sehr angenehm.

Wer sich die Aufzeichnung ansehen möchte, findet sie unter diesem Link: https://www.youtube.com/watch?v=0BLYZJgM-3w