google-site-verification=ELxx8BxZxh0FRvrpsz3X3djO2LXa4N0xnq_ADRpt8wA Continuous Delivery, Platforms as Product and Value Stream Mapping - Loving Legacy

Episode 25

Continuous Delivery, Platforms as Product and Value Stream Mapping

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]

Transcript
Richard Bown:

Hello, and welcome to the loving legacy podcast.

Richard Bown:

Episode 25.

Richard Bown:

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

Richard Bown:

This time.

Richard Bown:

It's a good one.

Richard Bown:

It's a long one, too.

Richard Bown:

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

Richard Bown:

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

Richard Bown:

Interesting discussion.

Richard Bown:

I hope you enjoy it.

Richard Bown:

Let's crack on.

Richard Bown:

thanks for joining me today.

Richard Bown:

Jacob.

Richard Bown:

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

Richard Bown:

you work for and what you do

Jacob Lafors:

Yeah.

Jacob Lafors:

So nice to be here.

Jacob Lafors:

Thanks for inviting me.

Jacob Lafors:

So my name's Jacob.

Jacob Lafors:

I'm based close to Helsinki in Finland.

Jacob Lafors:

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

Jacob Lafors:

in founding a small consultancy where we practiced things like CICD

Jacob Lafors:

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

Jacob Lafors:

software teams deliver good software.

Jacob Lafors:

So that's it in a nutshell.

Richard Bown:

Nice.

Richard Bown:

And how long has the company been going for?

Jacob Lafors:

Yeah.

Jacob Lafors:

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

Jacob Lafors:

a name and hired our first employee.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

It was more about building a nice place to work.

Richard Bown:

And how did you kind of transition to

Richard Bown:

that idea that I wanna start.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

resellers of, um, testing tools.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

CNC plus plus in the embedded space.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

was, you know, just taking off.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

Uh,

Richard Bown:

So when was this?

Richard Bown:

Time wise.

Jacob Lafors:

Uh, 2011, 2000 and, and 12 ish.

Jacob Lafors:

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

Jacob Lafors:

this cuz people are using it.

Jacob Lafors:

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

Jacob Lafors:

basically helping teams to implement static analysis and unit testing

Jacob Lafors:

as, as, as part of CI as well.

Jacob Lafors:

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

Jacob Lafors:

E of that business.

Jacob Lafors:

So the same company name.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

I wanted to just be helping people implementing these tools.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

So that's when that started.

Jacob Lafors:

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

Jacob Lafors:

an idea of what we were going to do.

Jacob Lafors:

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

Jacob Lafors:

And that project scaled quite quickly.

Jacob Lafors:

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

Richard Bown:

Wow.

Jacob Lafors:

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

Jacob Lafors:

golden nugget right at the beginning.

Richard Bown:

Thought everything was easy at that point.

Richard Bown:

Simple customers.

Richard Bown:

Yeah,

Jacob Lafors:

exactly.

Jacob Lafors:

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

Jacob Lafors:

again, at least not as easily.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

that project won't last forever.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

project, but find them a project.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

things open in, in a dashboard as well.

Jacob Lafors:

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

Jacob Lafors:

we working enough to be sustainable?

Jacob Lafors:

Um, and the goal is 10% profit.

Jacob Lafors:

People are quite autonomous in making their.

Jacob Lafors:

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

Jacob Lafors:

involved with, and which they wouldn't.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

So,

Richard Bown:

Amazing.

Richard Bown:

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

Richard Bown:

enterprise in some ways as well?

Jacob Lafors:

yeah, I mean the, there are now these consultancies

Jacob Lafors:

that are, um, coming out.

Jacob Lafors:

Like you, you're basically a freelancer.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

the, the amount new bill as well.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

versus, you know, you're a freelancer.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

there's sort of two, two models.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

And that, that was always a goal.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Richard Bown:

Yeah, yeah, exactly.

Richard Bown:

A lot more like a collective.

Richard Bown:

Really.

Richard Bown:

Excellent.

Richard Bown:

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

Richard Bown:

take into your work as well.

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

still this, you know, like challenge.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

The ecosystem wasn't as well integrated.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

things and helping teams with it.

Jacob Lafors:

And now, nowadays we're still really hands.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

once a day, overnight kind of thing.

Jacob Lafors:

Yeah.

Jacob Lafors:

Yeah.

Jacob Lafors:

Absolutely.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

Uh, should be a goal though.

Jacob Lafors:

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

Jacob Lafors:

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

Richard Bown:

No.

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

testing is almost meaningless.

Richard Bown:

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

Richard Bown:

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

Richard Bown:

context which works, which works for you.

Richard Bown:

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

Jacob Lafors:

yeah, absolutely.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

that I've made in my work.

Jacob Lafors:

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

Jacob Lafors:

better ways to deliver software.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

and seduced by all these new things.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

you know, you should be doing this.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

that's when it really, it really depends.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

I mean, it wasn't anything ludicrous.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

Um,

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

Completely.

Richard Bown:

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

Richard Bown:

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

Richard Bown:

is, it's never as simple as that.

Richard Bown:

Of course as well.

Richard Bown:

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

Richard Bown:

other departments are depending upon.

Richard Bown:

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

Richard Bown:

you read Team Topologies at all?

Jacob Lafors:

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

Jacob Lafors:

I'm still in the process of reading it.

Richard Bown:

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

Richard Bown:

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

Richard Bown:

just talking there around Yeah.

Richard Bown:

The, the communication.

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

or have things within their control.

Richard Bown:

But secondly, defining the interfaces of the communication interfaces

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

together over a period of years.

Richard Bown:

Very difficult to unpick the social technical kind of buzzword

Richard Bown:

thing, but it's very true.

Richard Bown:

The social technical side of software development is

Richard Bown:

really coming to the fore now.

Richard Bown:

I think it's not a moment too soon.

Jacob Lafors:

Yeah, Yeah.

Jacob Lafors:

Completely agree.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

also the architecture of software.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

you are releasing software.

Jacob Lafors:

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

Jacob Lafors:

the idea of platform engineering now.

Jacob Lafors:

So platform engineering as a product almost within companies.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Richard Bown:

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

Richard Bown:

the buzzword at the moment isn't it?

Richard Bown:

As well.

Richard Bown:

Like, DevOps is dead platform engineering.

Richard Bown:

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

Richard Bown:

to do with each other, essentially.

Richard Bown:

I, I see.

Richard Bown:

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

Jacob Lafors:

yeah.

Jacob Lafors:

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

Jacob Lafors:

his master thesis the relationship between configuration management and DevOps.

Jacob Lafors:

Cause he is really into conflict management at least.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

now, people just call, you know, DevOps

Jacob Lafors:

. And to, to have called that, uh,

Jacob Lafors:

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

Jacob Lafors:

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

Richard Bown:

That's it.

Richard Bown:

Well, why do we need to name?

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

You have to build your own tools, basically.

Richard Bown:

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

Richard Bown:

developer platforms things like Backstage.

Richard Bown:

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

Richard Bown:

10 plus years already.

Richard Bown:

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

Jacob Lafors:

Yeah, I think, I think I.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

know, it happens all the time.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

around, you know, the reconciliation.

Jacob Lafors:

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

Jacob Lafors:

and state management and so on.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

teams, it's a collection of tools.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

he equals it design by accident.

Jacob Lafors:

Um, so nobody really masterminded this platform.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

whatever, uh, could be any platform.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

That's helpful.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

I think there's more to it than that.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

To facilitate that.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

your dashboarding access.

Richard Bown:

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

Richard Bown:

So how does that work?

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

and I think that's a wrong assumption.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

central team does the upfront work.

Jacob Lafors:

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

Jacob Lafors:

some kind of like wrapper around it.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

you don't need to know Kubernetes.

Jacob Lafors:

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

Jacob Lafors:

one is green and one is red

Jacob Lafors:

. Richard Bown: Mm-hmm.

Jacob Lafors:

I think having that abstraction layer for

Jacob Lafors:

the typical people is good.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

Just give us access to the api.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

platform is such a difficult thing to do.

Richard Bown:

For everybody though?

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

done it before somewhere else.

Richard Bown:

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

Richard Bown:

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

Richard Bown:

they're making mistakes as they go.

Richard Bown:

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

Richard Bown:

is, layer is not really there yet.

Richard Bown:

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

Richard Bown:

still dunno what Docker is, you know?

Richard Bown:

So, and that's fair.

Richard Bown:

That's fine.

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

Essentially, since everything has become more software oriented, including

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

productization there as well.

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

to deliver something which is meaningful.

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Jacob Lafors:

Yeah.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

and make sure these tools are all great.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

or giving something that they work.

Jacob Lafors:

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

Jacob Lafors:

big effect on your user base.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

from that perspective at this level.

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

So is that wrong?

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

that even too abstract to contemplate?

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

on the Kubernetes bandwagon as well.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

you know, G K E create cluster.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

Kubernetes APIs for the most part.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

It's not gonna take much time.

Jacob Lafors:

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

Jacob Lafors:

It's not a possibility.

Jacob Lafors:

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

Jacob Lafors:

you know, the, the scalability of it.

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

spend time, uh, accordingly, I suppose.

Jacob Lafors:

Exactly.

Jacob Lafors:

Yeah.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

as a service kind of thing.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

to upgrade, to rollback, to, you

Richard Bown:

indeed.

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

systems and see benefit, I suppose?

Richard Bown:

Or is it just gonna slow things down?

Jacob Lafors:

This is a really good segue into the reason how,

Jacob Lafors:

how, how we got in contact as well.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

the, with the different software teams

Richard Bown:

so how would you go about that then?

Richard Bown:

How would you Yeah.

Richard Bown:

Engage with teams in the first instance?

Jacob Lafors:

Yeah.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

colleagues that I work with.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

box and these sorts of things in it.

Jacob Lafors:

We just do it very informally.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

or, you know, into an online tool.

Jacob Lafors:

So what do you do?

Jacob Lafors:

Do you, do you create a branch?

Jacob Lafors:

Do you start hacking, coding?

Jacob Lafors:

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

Jacob Lafors:

and how's your merging process?

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

Like what happens if CI fails?

Jacob Lafors:

What happens if something in production fails?

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

that exist with, with software.

Jacob Lafors:

Yeah.

Jacob Lafors:

But then we have some waste cards.

Jacob Lafors:

we have eight categories of waste.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

So where do you experience waste during this process?

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

wastes are themselves the problem.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

upstream or some waste upstream.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

you know, the edge cases and things.

Jacob Lafors:

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

Jacob Lafors:

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

Richard Bown:

Yeah, indeed.

Richard Bown:

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

Richard Bown:

potentially the backlog as well.

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

stream mapping at all, uh, as well.

Richard Bown:

Sorry?

Richard Bown:

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

Jacob Lafors:

Um, mean, value stream mapping is the, is

Jacob Lafors:

the, is the process, right?

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

distracted and people put a waste there.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

the other waste cards that we have.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

to think that the problem is upstream.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

How do you approach that?

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

which is called Getting Naked.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

know the good, the good consultancy.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Richard Bown:

Yeah.

Jacob Lafors:

in the open.

Jacob Lafors:

So

Richard Bown:

Wow.

Richard Bown:

I'm definitely gonna read that book.

Richard Bown:

That will link that as well in the notes.

Richard Bown:

Um, that's so, okay.

Richard Bown:

So just to maybe wrap this.

Richard Bown:

Up a bit.

Richard Bown:

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

Richard Bown:

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

Richard Bown:

And I got into value stream mapping.

Richard Bown:

I read that from your website as well.

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

know that we're doing a good job?

Richard Bown:

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

Jacob Lafors:

Yeah.

Jacob Lafors:

Yeah.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

if you, even, if you even need to.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

gonna solve and help with this.

Jacob Lafors:

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

Jacob Lafors:

Take or how much time it's gonna cost.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

because they produce this data for you.

Jacob Lafors:

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

Jacob Lafors:

so much waste here in the process.

Jacob Lafors:

We wanna fix this.

Jacob Lafors:

Um, let us, let us fix this.

Jacob Lafors:

Here's what we're gonna save.

Jacob Lafors:

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

Jacob Lafors:

know, we, we can do that for you.

Jacob Lafors:

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

Jacob Lafors:

a lot of waste in the process.

Jacob Lafors:

Yeah.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

I mean, the DORA metrics are good.

Jacob Lafors:

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

Jacob Lafors:

sake of having my own metrics.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

Probably not.

Jacob Lafors:

No.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

and, and adaptability and so on.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

on, um, then I would probably optimize.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

doing something totally different.

Jacob Lafors:

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

Jacob Lafors:

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

Richard Bown:

Well, that's very interesting.

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

process, and this has to be reviewed.

Richard Bown:

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

Richard Bown:

actually I wanna bring up.

Richard Bown:

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

Richard Bown:

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

Richard Bown:

it'll be be lumped under technical debt.

Richard Bown:

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

Richard Bown:

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

Richard Bown:

And it's lumped into technical debt.

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

You know what?

Richard Bown:

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

Richard Bown:

typically in a lot of companies.

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Jacob Lafors:

Yeah.

Jacob Lafors:

I mean, yeah.

Jacob Lafors:

Um, yeah, I guess, yeah.

Jacob Lafors:

That's, that's nice.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

we do, it creates a snapshot, right?

Jacob Lafors:

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

Jacob Lafors:

Um, I, I don't think it.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

value stream but didn't really help us.

Jacob Lafors:

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

Jacob Lafors:

opinions of how you're releasing software.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

you know, that involvement with the team.

Jacob Lafors:

That, that to me is the real value.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

reports and things afterwards.

Jacob Lafors:

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

Richard Bown:

Yeah.

Richard Bown:

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

Richard Bown:

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

Jacob Lafors:

exactly.

Jacob Lafors:

Yeah.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

needs to be done, but how urgent is it?

Jacob Lafors:

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

Jacob Lafors:

what, what, what should be done.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

good grounds to make good decisions on.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

Cause everyone thinks that like code smells are bad.

Jacob Lafors:

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

Jacob Lafors:

up all these code smells?

Jacob Lafors:

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

Jacob Lafors:

smells do have a negative effect on it.

Jacob Lafors:

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

Jacob Lafors:

uh, stuff is really important too.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

value stream and nobody mentions it.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

So should you then start cleaning up these backlog technical

Jacob Lafors:

debt issues for that code base?

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Richard Bown:

Brilliant.

Richard Bown:

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

Richard Bown:

You know, it would be lovely if.

Richard Bown:

Could prioritize improving our delivery process all the time.

Richard Bown:

But we live in the real world.

Richard Bown:

But that isn't always the case.

Richard Bown:

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

Richard Bown:

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

Richard Bown:

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

Richard Bown:

So how do we know that?

Richard Bown:

And I presume DORA metrics there would help you.

Jacob Lafors:

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

Jacob Lafors:

mapping and start implementing change basically in investing in performance.

Richard Bown:

Yeah.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

Uh, let's fix that.

Jacob Lafors:

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

Jacob Lafors:

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

Jacob Lafors:

cycle time and improve your lead times.

Jacob Lafors:

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

Jacob Lafors:

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

Richard Bown:

And we wrapped up things there.

Richard Bown:

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

Richard Bown:

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

Richard Bown:

may have to revisit in time.

Richard Bown:

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

Richard Bown:

or wherever you consume your podcasts.

Richard Bown:

And please also subscribe.

Richard Bown:

It helps me keep doing what I'm doing.

Richard Bown:

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

About the Podcast

Show artwork for Loving Legacy
Loving Legacy
How to deliver successful real-world IT and software projects

About your host

Profile picture for Richard Bown

Richard Bown

I’m an independent consultant who helps software businesses maximise their legacy investment.