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.