I talk to Jacob Lafors about his company, Verifa, as well as their approach to engagements around platform engineering, CI/CD and how he provides a value stream mapping service to clients. We talk about developer platforms and turning the developer experience into an internal product.

NOTES

The blog where inspiration for this podcast episode came from:

https://verifa.io/blog/unlock-your-continuous-delivery-potential-vsm/

Team Topologies:

https://teamtopologies.com/

DORA Metrics:

https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance

Getting Naked:

https://www.amazon.com/Getting-Naked-Business-Shedding-Sabotage/dp/0787976393

CodeScene:

https://codescene.com/

https://codescene.com/blog/author/adam-tornhill

QUOTES

[07:20] “How do we build a process that  helps bring value to the company?” [JL]

[10:04] “[CI/CD setup] It's really gonna depend on who you have in your team, your team size, the organization that you're part of as well” [JL]

[12:18] “The social technical side of software development is really coming to the fore now. I think it's not a moment too soon” [RB]

[13:02] (TT and Conway’s Law) “the way those technical decisions are made are so heavily influenced by the way the organizations and the teams around us are structured as well” [JL]

[13:20] “ And I think where that, that, that, that is going is, is more on the, the, the idea of platform engineering now” [JL]

[16:41] “and the reason why I don't get so annoyed when I hear these buzzwords because I think there's more to it than that.” [JL]

[18:09] “ if a platform team does extra work to cater for two people, it means that, or two personas, it means that those two personas have less work to do and that's much more scalable that one central team does the upfront work.” [JL]

[18:37] “you don't need to know Kubernetes. You can see the, the resources and you know, you can see one is green and one is red” [JL]

[21:00] On IDPs and product thinking: “getting that product mindset is, it's not difficult if you, if you've been building products before” [JL]

[24:03]  “ the problem we're solving is that we don't want the teams to have to manage and maintain all their own Kubernetes clusters” [JL]

[24:49] “usually the bigger the company and the bigger the teams  the general level of competence that you can assume does go down a little bit.” [JL]

[26:15] VALUE STREAM MAPPING

[26:34] “If I was brought in to build some kind of internal developer platform, the first thing I would go and do is to go and run, uh, value stream mapping workshops with the, with the different software teams.” [JL]

[28:00] “So what do you do? Do you, do you create a branch? Do you start hacking, coding?  What about when you get to, to use version control? and how's your merging process?” [JL]

[31:37] “if you're scared of losing your, your work or your contract or whatever because of what you're say and what you do, then, then, then you're not, you're not getting naked.” [JL]

[32:52] “I was kind of going through a funk at the time where I was like, continuous delivery is seen as a, again, as a hammer.” [RB]

[33:27] re: Continuous Delivery “there is no endgame and time is finite” [JL]

[34:07] “But I feel like for the justification value streams are very good because they produce this data for you.” [JL]

[34:51] “the DORA metrics are good. I wouldn't bother creating my own metrics just for the sake of having my own metrics” [JL]

[35:39] “I would know that if, if our business is very volatile and maybe we're quite young and you know, we need the product market fit and these sorts of things, then I would know that our key goals would be for changeability and, and adaptability and so on.” [JL]

[37:45] “You know, me and me and Bob over there, we got together and drew a value stream but didn't really help us.” [JL]

[37:57 ] “it's not just the diagram that's the value, it's the process of creating it, the process of getting people to talk, the process of, you know, that involvement with the team.” [JL]

[39:10]  “Well if your code doesn't change, then, then why are you cleaning up all these code smells?” [JL]

[40:57] “the DORA metrics aren't goals. I mean they don't tell you what to do.” [JL]

Hello, and welcome to the loving legacy podcast.

Episode 25.

Can't believe we've got to a quarter of a century already.

This time.

It's a good one.

It's a long one, too.

I'm speaking to Jacob Lafors, all about value stream mapping, continuous delivery,

and product as a platform or platform as a product, which way round is it.

Interesting discussion.

I hope you enjoy it.

Let's crack on.

thanks for joining me today.

Jacob.

Maybe you can introduce yourself and tell me who you are and who

you work for and what you do

Yeah.

So nice to be here.

Thanks for inviting me.

So my name's Jacob.

I'm based close to Helsinki in Finland.

And, yeah, I come from a technical background, but I, I was involved

in founding a small consultancy where we practiced things like CICD

and cloud architecture and try and couple those two together, help

software teams deliver good software.

So that's it in a nutshell.

Nice.

And how long has the company been going for?

Yeah.

We, we, we started in 2017, or at least that's when, you know, when we gave it

a name and hired our first employee.

And it was more than just , just me running around doing my own thing.

Growth and scale was never the, like the real goal.

It was more about building a nice place to work.

And how did you kind of transition to

that idea that I wanna start.

Yeah, that's a, that's a really good question.

Um, so I was, I was working for, um, another company who were, who were

resellers of, um, testing tools.

So we were reselling static analysis and, and unit testing tools.

There was other stuff too, but those were the two primary things, mainly for

CNC plus plus in the embedded space.

Um, and they, yeah, they, they were resellers, so they didn't own the tools.

Other companies developed the, the, the, the products, the tools, and then we were,

we were selling them and, and doing, you know, customer support and, uh, also into

implementation integration and these sorts of things for getting it up and running.

So that was when I entered the, the, the, the industry and CI

was, you know, just taking off.

So, uh, people were looking at tools like, um, like cruise control and so on.

And then suddenly the new kid on the block Jenkins appeared.

Uh,

So when was this?

Time wise.

Uh, 2011, 2000 and, and 12 ish.

So, yeah, I got Jenkins sp plunked on my desk, like learned

this cuz people are using it.

Yeah, I got involved in writing plugins and such for that and, and

basically helping teams to implement static analysis and unit testing

as, as, as part of CI as well.

And, um, together with my brother we, we created a franchise.

E of that business.

So the same company name.

And we started the business in the Nordics, which we did for a few years.

It was, it was really fun and, and, and good.

But more and more I felt like I, I didn't wanna be involved in selling tools.

I wanted to just be helping people implementing these tools.

And we, we came across, uh, doing our work, a company called Pragma,

who were based in Denmark also had an office in, in Sweden and Norway.

So, um, uh, that, that, that kinda like sparked the idea that like,

okay, so I could be doing pretty much exactly what I'm doing, but without

having to sell tools and be completely unbiased and really helping teams.

So that's when that started.

So we, we already had some contact in the industry and already had, um, you know,

an idea of what we were going to do.

All we needed was a, you know, was a project to start on.

And that project scaled quite quickly.

So within, within the first year of Verifa, we were like five or six already.

Wow.

uh, and yeah, we didn't realize how we were hand handed a

golden nugget right at the beginning.

Thought everything was easy at that point.

Simple customers.

Yeah,

exactly.

And then, and then nothing like that ever really came along afterwards

again, at least not as easily.

And that was kind of a shock as well coming from the employer perspective

because I think it was almost too easy that, okay, you have, you have project,

they have a need, you know, good people in your network or something.

I just hire one of them and then slowly starts to dawn on you that

that project won't last forever.

Now that person's gonna be off the project and it's kinda your respons.

I, I took it as my responsibility to then not just find me a

project, but find them a project.

And like that pressure was something I hadn't foreseen at the beginning.

I guess the, the lesson I learned now where we are today as a company

is that, um, everything's quite transparent within the company.

We have things like open salary, uh, we have all the, the, the project rates

and the hours that people spend on projects and all of the time sheets and

things open in, in a dashboard as well.

So we can see every month what the hygiene of the company is that are

we working enough to be sustainable?

Um, and the goal is 10% profit.

People are quite autonomous in making their.

Making their own decisions and also have a say in which projects they like to be

involved with, and which they wouldn't.

And I think that that kind of, um, maturity in the company then eases my

burden a lot because people take, take it upon themselves almost to find projects

to make sure they have good work and, and ensuring the rates are good as well.

Cuz everybody has an active interest in, in, in the success of the company.

So,

Amazing.

So it's almost like a, would you say like a B Corp or a social

enterprise in some ways as well?

yeah, I mean the, there are now these consultancies

that are, um, coming out.

Like you, you're basically a freelancer.

Uh, you, you get a minimal salary if you're not on a project.

Um, but then if you're on a project, you get a cut of the, of the, like

the, the amount new bill as well.

Uh, and we explored this kind of models too, which is less like, okay,

you're an employee here, uh, you know, just work and and have your salary

versus, you know, you're a freelancer.

Uh, you get the benefits of being a freelancer without the risk.

Um, and I think we're, I mean, we're somewhere in between.

Um, but there's no, there's no risk.

You know, if you're off, if you're on the bench and you're off work, then, then

you, you know, your salary's not affected.

People know what everyone else's salaries are and what the competitive industry is.

I dunno, any other companies doing this, I only know if

there's sort of two, two models.

So, uh, but I, I think it's, I think it's working.

It certainly creates more of a community within the company as well.

And that, that was always a goal.

I mean, we didn't wanna be a, an empty shell in a way that, you

know, we have all these people working here, but they're off.

On their own projects and you know, we, we we're not a company ourselves.

We really wanted to be our own company as well, so,

Yeah, yeah, exactly.

A lot more like a collective.

Really.

Excellent.

So that kind of also, it seems to be the mission that you

take into your work as well.

So when you go to a company and do, for example, so you mentioned C I C

D, so typically you might go into a company and then what implement or

help with process or how, how does that kind of look on a typical engagement?

Yeah, it varies a lot and it's changed a lot as well.

In the early 2000 tens and, and sort of mid 2000 tens, I think CI was

still this, you know, like challenge.

People would ask if you're doing CI and it really was a yes or no answer,

uh, or like, yeah, you know, we, we, we've automated our build, um,

because it was a challenge, you know, you needed to run your own tools.

The ecosystem wasn't as well integrated.

You couldn't just go on Stack Overflow or ask Chat g pt, like, write me

a get up action pipeline for my no JS project or something, you know?

Um, so it was, it was really like a, a much bigger challenge then.

So we, we were, I would say, much more HandsOn with, with setting up those

things and helping teams with it.

And now, nowadays we're still really hands.

But I would say that the challenge is no longer so much of the, the technical one,

like picking a tool and creating, you know, writing a yammel file or whatever.

It's more like, you know, how how does the team, uh, get value from this?

How do we build a process that helps bring value to the company?

Uh, and it's usually not so much with the ci, the challenge then comes

further downstream, but then you have a massive automotive projects.

We have like millions of lines of code and hugely complex build processes.

And then, you know, you could have an entire team just trying

to solve , like optimizing CI and solving some of the challenges there?

it depends how you define CI as well, because if you're like on

the Dave Farley side where it's like, you really need to do this all the time.

It needs to be fast, as opposed to, we can do it once a night, overnight,

once a day, overnight kind of thing.

Yeah.

Yeah.

Absolutely.

And maybe it's not always a one size fits all.

It's not always, it's not always possible.

Uh, should be a goal though.

It's not always, it's not always so, so straightforward.

You know, you can't just have a docker with, with all the things you need in it,

No.

Cause that in itself is gonna be a configuration headache to create.

It's really kind of looking at a subset of what actually happens in the real

world, because you end up with, um, yeah, there's a piece of software at

the middle of all your stuff, but then there's is huge configuration around

it, which you have to take in account every time you wanna test something.

So that's when CI becomes so complicated because you end up with these, and this

is again, talking of Dave Farley, where I kind of agree about the end-to-end

testing is almost meaningless.

You know, because you have to, you have to look at your stuffing kind of

component size, but then at some point you've gotta do it in a, in a, in a

context which works, which works for you.

And automating to that level is very tricky and takes a lot of time,

yeah, absolutely.

I think my favorite catchphrase at the moment is just, uh, it depends.

I think this is a very interesting point as well that the mistake

that I've made in my work.

So being a consultant and trying to help companies with with CI and

better ways to deliver software.

Uh, I don't want to couple CI and CD together too much because I, I think

they are different disciplines and everyone has a habit of saying c I, cd.

Yeah, for sake of clarity, like, like beyond ci, um, then, then it's very easy

to go and, and do your research and do your reading and, and you know, read some

blog posts about how something amazing save so much they used conferences

and seduced by all these new things.

And, um, you know, I I, I was one of the people who came in and they were using

tooling that I didn't agree with, or ways of doing things that I didn't agree with

or didn't think were, you know, the best.

So I, you know, I, I'd be there actively telling that if you wanna be good,

you know, you should be doing this.

And I just think back how I would do things differently today.

Because, because there is no one size fits all when it comes to, you know, the, the

best practice or, or, you know, what's the, what's the best way of, of, of doing

this, um, It's really gonna depend on who you have in your team, your team size, the

organization that you're part of as well, because some things just might not be in,

in your control or even in your team's control, or it takes so long to change.

So you have to, you have to work with what you've got and, and, and, and

that's when it really, it really depends.

Um, so coming in and trying to tell people how to be better at, at what

they are doing, their day-to-day work is completely the wrong approach.

I mean, it wasn't anything ludicrous.

You know, Jenkins was the CI tool and people were using all kinds

of weird stuff, and we were like, yeah, you should use Jenkins.

I'm sure there's so many people who, who were doing the same thing back then.

Um,

And still are, you know, cause it is difficult for a consultant

coming in because you need to be seen like any, like a manager for example,

when they, when they start in, in anyone who starts in a role, you wanna have

an impact, especially a manager because you feel a bit paranoid about things.

You wanna, oh, let's change something for the sake of it.

But for a consultant coming into a gig, you want to say, okay, we

can change something and we can make an impact straight away.

So making a noise and saying let's change the tooling, whatever is something

that, yeah, I've defaulted to as well.

Completely.

And sometimes it's right, sometimes it's wrong.

What you realize when you get into the weeds of any decision like that

is, it's never as simple as that.

Of course as well.

Especially if it's a, a well integrated tool or something that's people are,

other departments are depending upon.

um, And something I've found really, I dunno if you've have

you read Team Topologies at all?

Yeah I have, I've done lots and lots of research around, and I'm,

I'm still in the process of reading it.

Yeah, there's, um, yeah, there's a, there's a bit in there.

Well, there's a couple of things that spark me when you were

just talking there around Yeah.

The, the communication.

Cause that's one thing that's very clear in team apologies, is getting

your team responsible for its own, its own area of interest as much as

possible so that they can actually release whenever they, they can do

or have things within their control.

But secondly, defining the interfaces of the communication interfaces

between those teams particularly, and tooling is a big part of that.

And that's what I've seen over and over again, the Jira, for example,

or any other, um, project management slash agile tool gets in the way.

And there's maybe been, um, specialized or created in such a way that there's

a, there's a workflow or a template, which some people have kind of put

together over a period of years.

Very difficult to unpick the social technical kind of buzzword

thing, but it's very true.

The social technical side of software development is

really coming to the fore now.

I think it's not a moment too soon.

Yeah, Yeah.

Completely agree.

And, and one of the things that I love about reading the, the beginning

of Team Topologies anyway, the first chapter where it covers this, um, like

the, the architecture of teams and the, the communication channels and

also the architecture of software.

Basically Conway's law described in a really good way and, and like

proving it as well, in some way using existing research and so on.

I, I think that's really interesting because I always

thought software architecture was, you know, like a technical.

More of a technical challenge, but, um, that's really eye-opening to think that

like, sure, when it comes down to it at the end, it is a technical challenge, but

the, the way those technical decisions are made are so heavily influenced

by the way the organizations and the teams around us are structured as well.

Um, I think this applies a lot to, to releasing software as well.

Not just, you know, the software, but the way, like the way

you are releasing software.

And I think where that, that, that, that is going is, is more on the, the,

the idea of platform engineering now.

So platform engineering as a product almost within companies.

every software team is gonna need this, this stack of tools and they're

gonna need to operate within this organization and within these, um, ideas.

if there's some compliance regulations and so on as well that the company

have, then, then not every team should need to reinvent the wheel.

But again, I'm, I'm I yeah, cuz platform engineering's very much

the buzzword at the moment isn't it?

As well.

Like, DevOps is dead platform engineering.

I don't understand how platform engineering and DevOps have anything

to do with each other, essentially.

I, I see.

I, I dunno, I dunno how you see the definition or, or understand it

yeah.

but it's really interesting because, uh, I have a, I have a colleague who did for

his master thesis the relationship between configuration management and DevOps.

Cause he is really into conflict management at least.

I think he is , not quite sure if it's a joke by now or not.

Uh, but yeah, ev everyone's then saying that con configuration management is dead.

And it's, it's the same thing.

It's like, no, it's not dead.

All of the practices and all of the things that were part of configuration management

now, people just call, you know, DevOps

. And to, to have called that, uh,

Um, but it, it was sort of an easy and easy way cuz they needed a name and,

you know, DevOps was this thing about bridging, bridging teams and breaking down

That's it.

Well, why do we need to name?

All of a sudden it's like, now it's like of mode.

But in the back in the day, you would just build tools because you needed good tools.

You know, and I watched the John Romero talk a couple of weeks ago where he

goes over his top 10 programming tips or whatever, and he was, one of them is tools

are the most important thing that you can do to build, to build good software.

You have to build your own tools, basically.

And this is what we're kind of catching up with again now, is like IDPs or

developer platforms things like Backstage.

Navigating all this stuff is getting more, it is been complicated for.

10 plus years already.

It's getting more and more complicated by the minute, almost, you know,

Yeah, I think, I think I.

Yeah, . It depends how many beers I've had.

I'm just so, I'm just so impartial to it now because, you

know, it happens all the time.

Like, gitops came out and suddenly it was, you know, gis, everything, and then people

are like, well, what's wrong with cd?

There actually was a, you know, there is something behind it.

There is a, there is a subtle difference or, or like, there is

some something that gitops is trying to encapsulate, which is primarily

around, you know, the reconciliation.

It's not just ones and forget until next time, but more like reconciliation

and state management and so on.

Um, but I, I, I, I feel like platform engineering it again, is a, is a

buzzword, but there, there is something to it because what I have seen

most DevOps teams or, or what would now be called platform engineering

teams, it's a collection of tools.

They get asked to run tools that they use as part of the development stack.

And, um, Dave Farley video on this as well, to reference him again,

he equals it design by accident.

Um, so nobody really masterminded this platform.

It was more like, okay, here's some dudes.

Uh, we're gonna, you know, we're gonna run all of our stuff in, in AWS e s or

whatever, uh, could be any platform.

And, and here's some, here's some tooling that we're gonna, we're gonna run to

support the, the developers and, and, and kinda like, that's the platform.

And I like, that's Yeah, that's fine.

That's helpful.

But I, what I really like now about the direction this is taking, and

the reason why I don't get so annoyed when I hear these buzzwords because

I think there's more to it than that.

There is the developer experience on top of that and starting to

look at these things with a product mindset really does help to.

To facilitate that.

Um, so things like onboarding and, and offboarding for users and, and

not just, you know, here's, here's the Kubernetes api, write some yammel, but

maybe we should build a CLI because, or, or use something from the crazy

C n CF landscape that, you know, write your code, write some simple

config and you know, we, we know how you're gonna run and deploy platform.

Maybe you don't, that es maybe you just run and then here's

your dashboarding access.

Just, just to drill into that bit, um, a little bit.

So how does that work?

So if you say you have created this great platform for and development team or a

team to build, build a microservice or whatever service on it, when it comes to

support the kind of the, you build it, you run it kind of thing, cuz that still

apply if they don't understand what's going on under the covers in the platform?

I think it depends, and again, it depends . No, but, um, one of,

one of the things that I think people often believe is that a platform needs

to have one, needs to have one api, like have one persona that you cater for,

and I think that's a wrong assumption.

Um, I think catering, like if a platform team does extra work to

cater for two people, it means that, or two personas, it means that those

two personas have less work to do and that's much more scalable that one

central team does the upfront work.

So you could have the people who don't really need to learn and have

some kind of like wrapper around it.

The information that it produces, like, um, logs, some kinda dashboard, um,

you know, may maybe once they visually see that there's pods and that there's

a, a deployment and that there's, you know, different resources, you know,

you don't need to know Kubernetes.

You can see the, the resources and you know, you can see

one is green and one is red

. Richard Bown: Mm-hmm.

I think having that abstraction layer for

the typical people is good.

And then of why not have another abstraction layers for, for the

snowflakes or the ones who, you know, like, oh, we know what we're doing.

Just give us access to the api.

It's like, well, you don't need to use the same abstraction layer.

No, I, I think getting that abstraction layer, uh, the API layer for the

platform is such a difficult thing to do.

For everybody though?

Cause I see, I've seen in various places that I've worked that with

an experience consultancy, know what they're doing in Kubernetes land.

Fine, you can go in there, you can probably create this and you've

done it before somewhere else.

What I've seen typically up until now is that they're, they're inventing

a IDP or a developer platform or a platform for the first time and

they're making mistakes as they go.

So the product, the productization of that Kubernetes or whatever it

is, layer is not really there yet.

So considering how fast things are moving in terms of, it's like some developers

still dunno what Docker is, you know?

So, and that's fair.

That's fine.

You know, they shouldn't have to necessarily, I can't believe that

anyone could consider configuration as a configuration management as a concept to

be dead or even close to dying because as far as I can see, it's only growing, you

know, with all this stuff because it's so vital to what we deliver these days.

And that's, that's the a na, a natural hangover from having said

goodbye to data centers or at always having said goodbye to bare metal.

Essentially, since everything has become more software oriented, including

networking, it's inevitable that software engineers, whoever they are in whatever

shape, way, shape or form, are gonna have more load pushed towards them.

So, uh, it's really interesting that you mentioned, um,

productization there as well.

I think that's really key is that we're really getting product

thinking into what you used to be seeing as more mundane engineering.

Everyday kind of stuff when it comes to building these things.

So you need to be quite multi-dimensional to be able to, and not as a, like a

alien , but you know what I mean, in terms of what, you know, your experience

is, but also what you hope to achieve through your, through your platform, um,

to deliver something which is meaningful.

So I suppose the point I'm trying to make here is that it can depend on

the organization, how much effort you wanna put in, how much money you wanna

spend to be able to get that platform up to a level where it's useful.

Um, and I suppose that's playing out right now.

I don't, there'll be the winners and losers in that kind of world as well too.

Yeah.

And that, that, like, I think, I think getting that product mindset

is, it's not difficult if you, if you've been building products before.

The challenge is that most people haven't maybe been so involved in building

a product where you, where you look more from use cases that we expect

to, to solve and this is how we expect people to interact with the system.

So what's like the minimum thing that we need to do to fulfill this use case?

Um, usually it's more like, okay, we need these tools, so let's test all these tools

and make sure these tools are all great.

And then we'll kind of slap on the thin wrapper for the user at the end.

And I think the, this is what I was talking about with getting the

abstraction layer to be good is, um, and why it's, it's quite difficult as well.

It's very use case driven, you know, how do you expect people to interact with it?

But once you define that abstraction, once you start giving a, or giving

or giving something that they work.

That's like an API now, and changing that is gonna have a

big effect on your user base.

So if you've chosen the wrong abstraction, and they're almost too coupled with your,

with the system, like specifically with tools that you are using in your, in

your stack as well, what if you wanna change that tool and add something else

Now everybody's gonna be affected and you have to migrate everyone.

I think it's very, I mean, it's not like it works every time.

There's obviously gonna be exceptions and so on, but generally aiming, aiming for

that is a, um, is something that often comes too late, um, from, from what I see,

And can it, can it effectively be done as well, I suppose?

Can you, because you're kind of guessing, aren't you?

I suppose when you, when you build that abstraction in the first place,

that something else is gonna come along in five minutes and, and you wanna

add it and suddenly, yeah, I've gotta rethink of my architecture now, and then

suddenly you got backwards compatibility problems potentially, or whatever else.

I've not been involved in a, like, I suppose, um, a platform rollout

from that perspective at this level.

Like when it's productized, I've seen what you, what you've described before,

so I've seen it where it's just kind of like, let's, let's just make it up as

we go along and this will, this will do, and I've known that's to be acceptable.

But then of course you're tightly coupled as you say.

So is that wrong?

Because then underlying that you've got, like, for example, a for Yeah.

for a concrete example, I worked, uh, somewhere where there was, there

was a twin cloud strategy, if you call it a strategy at the time.

Um, so AW, Ws and a Azure and the two platform teams there, you could call them,

um, went on very different strategies for their platforms towards their user base.

So one was very focused around security and identity and access management, and

almost had an intake with teams before they were allowed to use the platform.

The second was very much self-service focused as well, so, , when you

were talking about personas or maybe different ways of looking at it, could,

could, could you be that flexible in a single platform, for example, or is

that even too abstract to contemplate?

I mean, if you have a, if you have a small, fairly small

user base and you know that they are very technically competent and let,

let's say the platform is more solving the problem that, and let's continue

on the Kubernetes bandwagon as well.

Um, so let's say that they're very confident and capable with that.

But what we, what the problem we're solving is that we don't want the

teams to have to manage and maintain all their own Kubernetes clusters.

And, you know, getting a Kubernetes cluster to production is not like,

you know, G K E create cluster.

It's like, okay, you're still gonna want your monitoring and logging.

Maybe you want your secrets management, you probably want some networking and,

uh, you know, you're, Basically add a whole bunch of stuff there afterwards.

So, um, maybe the platform is providing production ready Kubernetes

clusters as a service, in which case the abstraction layer will be the

Kubernetes APIs for the most part.

And maybe that's fine, but if you take a team who's maybe not so comfortable

with using Kubernetes and don't even want to care that that stuff is running

in Kubernetes, then, then you'd wanna move that abstraction layer up, right?

So, and, and usually the bigger the company and the bigger the teams the

general level of competence that you can assume does go down a little bit.

I mean, if you have five people, you need to hold their hands.

It's not gonna take much time.

If you got 500 people, you need to hold their hands.

It's not a possibility.

So it's, it's maybe not just the, the level of competence, but just the,

you know, the, the scalability of it.

So that's where you'll balance your effort, that you'll

basically say, yeah, depending on the size of the organization and how many

users we're gonna have be impacting, then we can put more effort into it and

spend time, uh, accordingly, I suppose.

Exactly.

Yeah.

And again, it's not like you need the one abstraction layer.

You could always start with, you know, Kubernetes as a,

as a service kind of thing.

Um, and then, and then realize that, oh, but actually most of the teams using

this, um, they don't need to, they don't need all the slow level details, so let's

just give them something like a CLI or something that they can, you know, Press

the run button and put it up in CI or, or use something like Argo CD or something

if you wanna do GI and, and, you know, abstract away the, the implementation

of it, but obviously not so far that they have no idea what's going on.

It's not just enabling to deploy, but enabling to debug and to,

to upgrade, to rollback, to, you

indeed.

And that's fine for a greenfield system or systems that we're

creating a new, what about when you're interfacing with existence?

Well, you're gonna be touching on legacy systems at some point as well.

How can you or can you integrate a delivery process around existing

systems and see benefit, I suppose?

Or is it just gonna slow things down?

This is a really good segue into the reason how,

how, how we got in contact as well.

Which is, which is which, which, which is value stream mapping.

Because this is something that I, I really love to do with teams.

Um, and for me if I had to serve software development teams, if, if, if

there were software development teams already working today and, um, I was

brought in to build some kind of internal developer platform, the first thing I

would go and do is to go and run, uh, value stream mapping workshops with

the, with the different software teams

so how would you go about that then?

How would you Yeah.

Engage with teams in the first instance?

Yeah.

Well, I'm not a guru in this area.

Uh, I got introduced to value stream mapping by, by

colleagues that I work with.

So I'm just gonna explain my view of value stream mapping first.

So it was from, you know, factory floors and how to optimize them.

That's where it originated from and it's been adapted to software

and I think most people still do it quite, that you knows a flow.

We from some point to another point how we, we deliver value.

Um, and, um, people put, you know, how much time they spend in each

box and these sorts of things in it.

We just do it very informally.

So we just ask teams that, let's say we start from somewhere.

I mean, ideally you have pretty large coverage, but if we're taking platform

engineering, let's say we, we could say that, let's start from, you have

a, a feature in your backlog, how, how are you gonna take that feature

and put it into production and also get feedback from production that,

that could be a really good scope for a value stream mapping exercise.

And then what I would do is I would ask the teams to, to just start

drawing with, you know, arrows and boxes, either on a whiteboard

or, you know, into an online tool.

So what do you do?

Do you, do you create a branch?

Do you start hacking, coding?

What about when you get to, to use version control?

and how's your merging process?

Do you do trunk based or, you know, whatever.

Um, how's your ci, what does that do?

Once we've got the happy path, cuz that's the, usually the, the easy one.

Then let's start to focus on the edge cases.

Like what happens if CI fails?

What happens if something in production fails?

And now we start to get, you know, the happy path value stream map is

now starting to split and diverge and we start to see the daily struggles

that exist with, with software.

Yeah.

But then we have some waste cards.

we have eight categories of waste.

Things like, uh, manual work handover, q uh, waiting.

But usually we find that waste is part of one of those types.

Um, and we ask people to annotate the, the value stream map.

So where do you experience waste during this process?

Um, and we might do some kind of prioritization there to

find out which wastes are, you know, more severe than others.

And we might talk about, is this a symptom or a problem because, um, some

wastes are themselves the problem.

And if we solve this, then, you know, we, we alleviate it.

But a lot of the time wastes are a symptom because of some problem

upstream or some waste upstream.

And that's kind of like the, the deliverable in a way, in

terms of a diagram, in terms of a value stream is, is just that.

Like, here's how you release software, here's the waste, here's all the,

you know, the edge cases and things.

And, and now we can have a really good constructive conversation about

how to improve because we no longer need to motivate people to change.

Yeah, indeed.

But do you find often you also get stuck in the weeds of

potentially the backlog as well.

So maybe you'd look at the, the existing backlog and say there

are some smells here, for example, that we've got technical debt or we

can't deliver X, Y, and Z and this, that can feed into the value, value

stream mapping at all, uh, as well.

Sorry?

Or would you just kind of ignore that and just take a complete fresh piece of paper?

Um, mean, value stream mapping is the, is

the, is the process, right?

And, and, and if we have, once we're drawing out this thing, you know, feature

to production, there might be a, like I'm writing code and suddenly I get

distracted and people put a waste there.

Like, you know, I get, I get distracted all the time.

Or there's, there's things, unplanned, unplanned was one of

the other waste cards that we have.

Um, and if you know, five people say, they're like, yeah, you know,

there's unplanned work that always comes up, then we might think, start

to think that the problem is upstream.

In the value streamer, probably more of the, you know, things on the backlog and

actual planning for the, for the, for the release cycle or the sprint or whatever

you're doing, maybe wasn't done that well or there's nobody protecting you.

Well indeed that, that's one one point I was keen to look at as well.

So what if it's a cultural problem, I suppose, like if the company itself

is used to working in a certain way, and you identify this through value

stream mapping, so well, basically you're getting interruption all the

time by the boss saying, you need to fix this for our top customer.

How do you approach that?

I mean, again, it's gonna say, I know you're gonna, how to say it depends,

but, um, it, it, it's sometimes not, not purely technical thing.

In fact, probably I would say a lot of the time it's, it's non-technical in nature.

There's a, there's a really great, um, book that we got

introduced to by colleagues as well, and it's now mandatory read in internally,

which is called Getting Naked.

It's a novel, a business f as they called it about two consultancy

companies and, uh, the, the different styles when consulting and, you

know the good, the good consultancy.

I won't ruin it, but one of the things there is about.

Taking a bullet for the, for the team as well, that, um, if you're scared of

losing your, your work or your contract or whatever because of what you're

say and what you do, then, then, then you're not, you're not getting naked.

Um, if you're naked, then you, you will be the one to, to stand up and take a

bullet and maybe say the things that are a bit awkward and emotionally challenging.

Um, and I, I, I feel like if, if we've done a value stream mapping with teams and

the this waste that we're talking about, which is caused by, you know, cultural or

management or whatever, if that's a valid thing that many people have talked about,

then I feel like I'd have enough grounds to stand on to make a point if I need to.

I mean, it might be that the manager is in the room and he's like, whoa, shit.

Like, is, is this the effect I have on you?

Uh, I mean, that's a very likely scenario.

Um, um, it puts these, these things out there, um,

Yeah.

in the open.

So

Wow.

I'm definitely gonna read that book.

That will link that as well in the notes.

Um, that's so, okay.

So just to maybe wrap this.

Up a bit.

We, we originally met and talked about, well, I found your website,

found the, the Verifa website via search about continuous delivery.

And I got into value stream mapping.

I read that from your website as well.

Um, and I was kind of going through a funk at the time where I was like, continuous

delivery is seen as a, again, as a hammer.

So how do you get to a point where you realize that you're doing enough?

Um, and I suppose I'm kind of pushing you in the direction of how do we

know that we're doing a good job?

How do we know that we're doing enough of a good job?

Yeah.

Yeah.

It's, it's a really, I like, I like these questions, um, because usually with

continuous delivery, I mean, you, you are always gonna be able to get better.

Uh, it's, there is, there is no endgame.

Um, I think I wrote in that blog post something like, there is no endgame

and time is finite because I mean, that's, that's the challenge, right?

Um, there's always something you could change and always something you can

do, but how do you know if that's gonna be positive and how do you know

if you, even, if you even need to.

Um, but I think every, like, I, I think we'd be foolish to not not

be aware or not think that there's something we can always improve on.

So really it's, it's about having some justification as to like

a, like a business case that we wanna change this because it's

gonna solve and help with this.

And this is, you know, roughly how much it's gonna.

Take or how much time it's gonna cost.

I mean, it depends where you work, how much justification is, is really needed.

But I feel like for the justification, um, value streams are very good

because they produce this data for you.

Um, they, they basically tell you this, that like, you know, there's

so much waste here in the process.

We wanna fix this.

Um, let us, let us fix this.

Here's what we're gonna save.

If you really need more of a breakdown into this, we, you

know, we, we can do that for you.

But it should be very clear that there's a lot of, like, a lot of,

a lot of waste in the process.

Yeah.

And you talked about, um, are you good enough or, or, or, or so on.

And I know we've spoken before about the, about the DORA metrics as well,

and I, I feel like that's, you know, like that's a good benchmark in a way.

I mean, the DORA metrics are good.

I wouldn't bother creating my own metrics just for the

sake of having my own metrics.

I would just use the Dora metrics because they're, they're well thought

out, they're difficult to cheat and there are like industry benchmarks

that are updated every year, whether you're an elite performer or so on.

Would I, would I use that to say we need to get better or not?

Probably not.

No.

I'd use that more of a Lena, like in, in an interesting thing, the benchmark.

I mean, I mean, I'd use the tric to, to measure do we get better?

I wouldn't use the DORA metrics to say, do we need to get better necessarily?

I would know that if, if our business is very volatile and maybe we're

quite young and you know, we need the product market fit and these sorts

of things, then I would know that our key goals would be for changeability

and, and adaptability and so on.

So I might try and optimize our value stream towards those.

Whereas if, if I'm in a very well established company, very trusted and so

on, um, then I would probably optimize.

I mean, you can't get stability without throughput and so on.

But, you know, I'd still optimize less for, you know, next week we might be

doing something totally different.

it's like, no, let's, you know, like, let's, let's maybe fine tune this value

stream as it's today and, and optimize it generally rather than, you know, um, yeah.

Well, that's very interesting.

The way you put it is like the value stream after you've done the initial

analysis, it sounds like it has to live as a product at that point.

You have to kind of say, well, this is our, the vision of that we have for our

process, and this has to be reviewed.

So how do you then, I mean, I've got a couple of points

actually I wanna bring up.

First one is when we talk about business case, it's almost like, um, for, for doing

more cd it's almost like I, I've seen a lot of backlogs where technical debt,

it'll be be lumped under technical debt.

Oh, we need to do faster ci, or this is failing, or we've.

Read too many broken tests, et cetera, that kind of stuff.

And it's lumped into technical debt.

And maybe at the end of, uh, I dunno if it's a, if it's safe, there'll be

a p a pi, there'll be, um, a sprint at the end to be able to do that.

Or maybe it'll be, they'll have a sprint where we'll reduce that.

You know what?

That, that's the kind of reactive approach that we do see

typically in a lot of companies.

Whereas I think what you are mentioning or, or maybe painting a picture of

here is more like thinking about this as a living thing that we

need to live with alongside all the software they're delivering as well.

So our value stream of our delivery process needs to be a living thing.

Yeah.

I mean, yeah.

Um, yeah, I guess, yeah.

That's, that's nice.

That's a nice way of, of thinking about it.

The, the value stream that we, you know, the, the, the diagram, the exercise that

we do, it creates a snapshot, right?

It's a, it's a snapshot in time.

Um, I, I don't think it.

Super valuable if, you know, there's, and, and I've heard this from teams as

well, like, yeah, we drew a value stream.

You know, me and me and Bob over there, we got together and drew a

value stream but didn't really help us.

And I'm like, well, of course it didn't really help you . That's just your two

opinions of how you're releasing software.

Um, value stream needs to, it's not just the diagram that's the value, it's the

process of creating it, the process of getting people to talk, the process of,

you know, that involvement with the team.

That, that to me is the real value.

I, I don't really care about the diagram at the end.

I mean, I care about the diagram because I usually need to write

reports and things afterwards.

So for me it's more like triggering my memory of, of, of,

Yeah.

But then it's what happens with the reports and what happens next

is, is the vital part, isn't it?

exactly.

Yeah.

But I mean, these, these, these, having, having, um, backlog items to clean up

technical debt or to do whatever, I mean, I mean, sure everybody knows it

needs to be done, but how urgent is it?

Um, there's, it's very difficult to prioritize those things and to know

what, what, what should be done.

But if we, if we, if we can somehow relate this back to the waste in the

value stream and the, the pain that people have raised, you know, it gives us really

good grounds to make good decisions on.

I mean, okay, so we have, we have smells in our code base.

I love this tool called codescene, by the way, cuz it, it kind of does this

and the founder Adam Tohill, um, is really like inspirational guy as well.

Cause everyone thinks that like code smells are bad.

Well if your code doesn't change, then, then why are you cleaning

up all these code smells?

But the parts of the code base that are changing all the time, maybe these code

smells do have a negative effect on it.

And I think these kinda like this, this context aware, it depends,

uh, stuff is really important too.

I mean, your code base could be like, you could have some really old code

base or part of the code base and really bad quality or whatever, and you do a

value stream and nobody mentions it.

You know, like there's not a single waste to say that this horrible part of the

code is a problem because maybe it doesn't change, maybe it doesn't affect anyone.

So should you then start cleaning up these backlog technical

debt issues for that code base?

Well, probably that's not a good use of time.

Um, or it might be, you know, the complete opposite that like, you know,

we just realized that like the three major wastes in our value stream mapping

are related to the bad quality of this code base, you know, various symptoms.

Now we know we really need to clean this up and it's gonna help us tremendously.

So I think that that knowledge of knowing where to invest and what to do is gonna

give you, you know, is gonna give you that, that, that, that decision for you.

Brilliant.

No, I think we're kind of tying it all up a little bit as well.

You know, it would be lovely if.

Could prioritize improving our delivery process all the time.

But we live in the real world.

But that isn't always the case.

So more often than not, it is a project or it's, uh, an initiative.

You know, so you might be brought on board to, to draw a value

stream map and then six months down the line, we wanna see progress.

So how do we know that?

And I presume DORA metrics there would help you.

Yeah, I mean you would hope right, that, that, um, you do value stream

mapping and start implementing change basically in investing in performance.

Yeah.

you'd hope to see some positive effects from that.

And I think you will in the metrics because the DORA metrics aren't goals.

I mean they don't tell you what to do.

It's not like, oh, our, our, our lead time is high.

Uh, let's fix that.

It's like, yeah, but how you fix that doesn't tell you doing that.

But maybe all the things come up, value stream help you reduce your, reduce your

cycle time and improve your lead times.

I mean, yeah you'd hope to see some positive effects and, and I'm

quite confident the DORA metrics would be a good, measure of that.

And we wrapped up things there.

Although we carried on talking for quite a lot longer than that.

We touched on many items in the discussion some of which we

may have to revisit in time.

If you enjoyed the show today, please like us on apple podcasts or Spotify

or wherever you consume your podcasts.

And please also subscribe.

It helps me keep doing what I'm doing.

Until next time, this is Richard Bown wishing you goodbye and good luck.