0:04

Welcome to Definitely Maybe Agile , the

0:06

podcast where Peter Maddison and David Sharrock

0:09

discuss the complexities of adopting

0:11

new ways of working at scale .

0:12

Peter , I'm looking forward to this conversation . Good to see

0:15

you again . Good to see you again , Dave . You

0:17

had a topic in mind .

0:19

We were going to talk about developer experience

0:21

and all the different aspects of that

0:23

, and there's many different avenues of this and there's many different avenues of this

0:26

we could potentially explore , but I'm interested to see where

0:28

this conversation goes . It's something that has been

0:30

coming up both through the

0:32

industry , press and the media

0:35

and through our clients as well . There's a lot of focus

0:37

on it and some of

0:39

it driving from like a developer productivity

0:42

angle , like developer productivity

0:44

versus developer experience or an

0:46

AI . What's the impact

0:48

of things like co-pilot and

0:51

the impact on organization as we start to

0:54

see these AI tools ? So

0:58

how does that impact the role of software

1:00

engineers and organizations and what does

1:03

that look like ? And how does that look like ? So how

1:05

does that change ?

1:05

developers experience . So , I mean , it's

1:07

an interesting market that we're talking about

1:09

here as well , because you know , we're going from a few

1:12

years ago when developers could do no

1:14

harm and they were . It could do no wrong

1:16

, I should say and they it was a

1:18

growth market . Everybody needed

1:20

developers and now over the last couple of years

1:23

, we've seen literally thousands of developers

1:25

being shed from organizations . So

1:28

when we start , whenever I think of developer experience

1:31

, one of the primary things I think of

1:33

is how comfortable do they feel where they're

1:35

at ? Do they feel valued ? Is it clear

1:37

that you know what their role

1:40

is in an organization , how they're creating

1:42

value , how their careers may be progressing

1:44

is in an organization , how they're creating value

1:46

, how their careers may be progressing ? I

1:50

think there's a safety element and a make me feel like I'm part of this organization element

1:52

that comes in .

1:52

To start with , I would say that and it's interesting

1:54

when you're starting from that but that's looking

1:56

at it from the developer's point of view into the organization

1:59

.

2:00

So you did say developer experience

2:02

.

2:02

Right yeah , developer experience . There's

2:04

the view of the organization

2:07

wanting to then measure this .

2:10

Yeah , but already now we're kind of tripping over

2:12

our feet a little bit .

2:15

So what is a developer's experience in the organization

2:17

? Why might we want to measure ? This is

2:19

an interesting topic . So

2:24

how are developers experiencing it ? It's going to

2:26

vary based on the culture

2:28

of the organization and a lot of different elements

2:30

like how easy is it for the developer

2:32

to get their job done Some of the

2:35

immediate sort of pushback

2:37

against the hey . Well

2:40

, copilot will replace all the developers

2:42

. Well , it helps them with

2:44

a portion of their job and their role

2:46

. But there are a lot of other activities , especially

2:49

in a large organization , that developers are involved

2:51

in , other than just writing

2:53

code . There is also this

2:55

piece , which is well

2:58

, do we want them to spend more time writing code or

3:00

less time writing code ?

3:03

So let me pull you back before we dive

3:05

off into what does the developer do and

3:07

how do they contribute to the organization . You

3:10

made a comment which has been

3:12

sort of zipping around my head , which is

3:14

about measuring productivity I

3:16

think you were going to talk about , but certainly a

3:18

little bit more about developers and

3:20

what good do they offer the

3:23

company . How do we know we're getting what

3:25

we need to from the developers ? Something along those

3:27

lines what's being measured or what's not being measured

3:29

? Can you talk a bit more about that ?

3:31

well , it's a , it's a question

3:33

that is being asked . I mean , there's

3:35

a couple of things , there's a couple of

3:37

forces which are causing the

3:39

sort of organization

3:41

to share developers . One of them is the macro economic

3:43

situation rising interest rates . Money's

3:45

not free . We probably overstaffed

3:48

previously and so they've cut

3:50

down on the size of it , but

3:52

the number of developers that they have to

3:54

be able to do these things . So there's that

3:57

side of it . There's also

3:59

then there's the impact of AI coming in

4:01

, and I

4:03

don't know how much that's actually impacted

4:06

that . I think the first one of those things , the sort

4:08

of the macroeconomic piece , is the primary reason

4:10

at this point that the AI piece I don't think

4:12

has caused organizations necessarily to

4:14

immediately say , oh , that looks like it can

4:16

do the job of all these developers , I'll fire everyone . I

4:19

don't think that's quite how that's gone down

4:22

myself , but I think there is

4:24

a desire , an understandable desire , to

4:28

understand well , how does this impact

4:30

the developer footprint ? Do I have the right

4:32

developers ? How can I use these tools

4:34

to get more from

4:37

my developers , to help my developers improve

4:39

, as improved and on the positive side , I mean where

4:41

we look at it like , how do I bring these in in

4:43

a way that they they improve the

4:46

outcomes that I'm getting from my

4:48

, from the development teams that I have . Uh

4:50

, what couldn't ? How can I get more

4:52

productivity out of them ? As in and

4:55

productivity is a bit of a loaded my goodness

4:57

, I think you've been .

4:58

You've been hanging around managers way too long

5:00

and leaders like here's what here's what I'm

5:02

hearing you say , which is we need to see

5:04

productivity grow from our development

5:07

, from everywhere . Of course , everything is about growing

5:09

productivity over time . And how do you

5:11

know your developers are improving their

5:13

outcomes , right , and and I

5:16

, but what worries me about this ? So when I'm

5:18

thinking about talking to developers and developer

5:20

experience , i'm'm thinking in the Dan

5:22

Pink mastery and autonomy

5:24

perspective Mastery , autonomy , purpose

5:26

, exactly , but I'm thinking

5:28

specifically about mastery and autonomy

5:30

, as in I want my developers to be

5:32

in an environment where they can see

5:35

a path towards mastery , so they're getting

5:37

the feedback . When I think about developer

5:39

experience , I'm thinking are they getting

5:41

the support they need ? Are they getting the direction

5:43

? Are they getting the tools and the environment so they

5:45

can become stronger and stronger

5:47

, can master their craft and the autonomy

5:50

to be able to go out and do those things ? And what

5:52

I find interesting is the information

5:55

that you need to be able to provide that

5:57

to your developer community is very

5:59

, very , very similar to the information

6:01

that managers might use to start

6:03

thinking about is my team X

6:06

as productive as team Y

6:08

, and things like this . The data is often

6:10

the same .

6:11

It's how it's

6:13

used Right and there's a lot into that as well

6:15

is that you can't look point in time . You have

6:17

to be looking at the system trends over time . You

6:20

need to be looking at common

6:22

cause versus special cause , statistical variation

6:24

, all sorts of fun things you can get into there

6:26

. The one of the interesting pieces

6:28

, let's say so . There's a lot of talk about this

6:31

. So dora , as uh , is

6:33

kind of the common sort of from

6:35

the accelerate book and , like

6:37

a lot of people , stop at the sort of we've

6:39

talked about this before . The four main metrics

6:42

which they showed are correlated to high

6:44

performance , forming organizations

6:46

, which really give you a

6:49

view of your technical capabilities , their outcome

6:51

metrics . If you look at these

6:53

, the outcome is that your technical capability is improving

6:55

. But they're not the only thing that you should measure . In

6:58

fact , not long after

7:00

Dora , a couple of years , they came with

7:03

Space , which extends Dora

7:05

in a lot of ways , and Space Metrics

7:07

adds some of the pieces

7:09

you're talking about . So you're talking about what you want

7:11

to see from the developers . I'm talking about

7:13

it from the organization side , about how

7:16

do we know that we have those things ? So if we

7:18

can get agreement that , yes , we want the

7:20

developers to have a path to master

7:23

. We want them to have autonomy . And how

7:25

do we know that we've created that in our organization

7:27

? Like , how do we know we're going in the right direction

7:29

to create that

7:32

developer experience in the organization and

7:34

so things like space , and

7:37

give the sort of the additional pieces

7:39

into that , or guidance

7:41

around what some metrics you might want to measure

7:43

, around that which it marries

7:46

up the sort of the qualitative and quantitative

7:48

sides of measurement to

7:51

start to understand what is the developer's

7:53

experience .

7:55

I think we're sort of circling around

7:57

that whole productivity question again , kind

7:59

of coming back to it from a different perspective

8:02

or with a little bit more information . And it

8:04

is absolutely correct that organizations

8:07

are obsessed with productivity

8:09

. It's a competitive advantage

8:11

, it's something that you know . There

8:13

are lots of different perspectives on

8:16

where productivity has gone in the last few decades

8:18

, but basically I mean , if you look at something like

8:20

AI and you look at the cutting edge things

8:22

on the technology , the reality is that

8:24

productivity should be growing a lot . Right

8:27

, we should be seeing these tools

8:29

augment what people are doing and

8:31

being able to improve productivity in that

8:33

area . So productivity growth is on everybody's

8:35

agenda . Again , one of the things that really bugs

8:38

me about this is and we've talked about this

8:40

the power of things like bringing teams

8:42

together . There's an intangible element to

8:44

productivity growth and it's really

8:46

easy to look at it from hey , you've got access

8:48

to co-pilot , we're doing this , we're doing the

8:50

other , we're , and all of that's going to speed

8:53

you up . But this is just a modern way of

8:55

saying . We should teach our developers how

8:57

to type quickly so that

8:59

we get more code and then the problem

9:01

, of course , that more doesn't mean

9:03

better in the development process , Absolutely

9:06

yeah , so I mean

9:08

.

9:08

The way I typically give the example

9:10

is that the developer who spends

9:12

seven hours thinking about a problem to write one

9:15

line of code that makes you a billion dollars is

9:17

better than the one who spends eight hours creating a thousand

9:19

lines of code that don't do anything for you . So

9:23

you can't measure lines of code , as you've

9:25

got to look at the outcomes of like is

9:27

this helping me get to the solutions

9:30

that generate the outcomes I want faster

9:32

? Am I ? Am I enabling my doctors to be

9:34

able to solve those solutions ? And then things

9:36

like code are incredibly valuable

9:38

if they help them with doing that . So and

9:41

then . So that's where we start to look

9:43

at it from that perspective .

9:44

Yeah , and if we come back

9:46

to the question , what would you pick up from

9:48

a developer experience ? What

9:50

is it that you think are the top three

9:53

things that need to be on the table for a conversation

9:55

there ?

9:55

I think that it varies by organization

9:58

and I'm not the only one to see that there's

10:00

lots of information out

10:02

there . But finding what

10:05

way you're like , I think it is important to measure

10:07

it . I think it's very , very important to measure it

10:09

. I think it is important that you don't

10:12

measure it based purely on activity , that

10:14

you base it on understanding

10:16

the

10:19

correlation of lots of different metrics and

10:21

not just one . There's no one metric that

10:23

will tell you everything about developer productivity

10:25

. There isn't one . It just doesn't exist . So

10:28

you've got to look at lots of different

10:30

elements and some

10:32

of those elements need to be qualitative

10:35

. You need to go talk to the people and understand

10:37

, like , how are they feeling ? Because it's

10:39

like telemetry and other pieces , just

10:41

because it looks like things are going better

10:44

based on the numbers you're getting from the system

10:46

. If you don't go and talk to the people and understand

10:48

like , well , what's getting in the way of

10:50

you improving ? Like , what would help

10:52

you the way of you improving , what would help you get better ? What

10:54

else might you be able If I could remove barriers

10:57

for you ? How could we improve further

10:59

? So if you don't go and ask those questions

11:01

, you're not really going to be looking

11:03

at developer experience but there are some great

11:05

articles out there which talk to . Maybe

11:07

we can link them in the

11:09

show around , like

11:12

talking about the different types of

11:14

metrics that high-performing organizations

11:16

measure in the developer experience

11:18

space and looking at how

11:20

that might , how those get applied

11:23

in different situations , because

11:25

it might not even be the same across all of

11:27

your organization , different parts of your organization

11:29

. You may want to measure different

11:31

things for that part of the organization due

11:33

to the technologies they're using , the types

11:35

of systems they're dealing with , the client

11:38

interactions that they're working

11:40

with . All of these types of things .

11:41

What you're describing there . I keep coming back

11:43

to the idea that there's these metrics

11:45

and data and information . If

11:47

it's made available to the development teams

11:50

themselves , you don't need to use it

11:52

to manage . And the reason I say that

11:54

is developers . They're very numerate , they're

11:56

going to look at the data , they're

12:02

going to draw conclusions and comparisons and challenge one another without any sort of prodding

12:04

or oversight or anything from a management perspective , and yet it's the

12:06

same information . So it's

12:08

a difficult . That nuance is really

12:10

important , though . One of the experiences

12:13

I remember many years ago now probably

12:15

20 plus years ago working with an organization

12:17

that had some of the best metrics I've ever

12:20

seen from a developer perspective , like they

12:22

had and I I mean , I know these numbers

12:24

on their own are garbage numbers

12:26

but they had things like lines of code and how many defects

12:28

did the reviewers find as a percentage

12:31

of the number of lines of code

12:33

they were reviewing , and so on . So they had

12:35

level of detail like loads

12:37

of information about really minute

12:39

things , which again individually rubbish

12:42

. But as you put a lot of these things

12:44

together , you start getting a picture of

12:46

how those developers were working

12:48

. What was really powerful is that was made

12:50

transparently visible to

12:53

the developers , and the managers were

12:55

not allowed to use that data , and so

12:57

what that meant was the developers held

12:59

one another accountable to a very high

13:01

standard that mastery and autonomy piece

13:03

because they felt safe , that their managers

13:05

weren't going to come in and have a conversation

13:08

with them about , hey , you know what ? The

13:10

number of lines of code you're writing is not nearly as many

13:12

as so-and-so right All of these things

13:14

that can be abused if they're not done correctly

13:17

and that's the bit that I'm hearing . It's a really

13:19

difficult piece to get to right . We need

13:21

to understand our system , our organization and

13:23

how productive that is and what's going on there

13:25

. But how do you do that without

13:28

getting into the individual performances

13:30

conversation ?

13:34

Yes , yeah , exactly a . It's not measuring the individual , it's measuring the system

13:37

and , uh , and making that transparent

13:39

. I agree , I think . I think that's a good way

13:41

of looking at it , to make sure that , uh

13:43

, the it doesn't become something

13:46

that's going to be like weaponized essentially

13:49

, which is always the danger when you start

13:51

to measure things . That , and always

13:53

the fear as well . So it's the

13:55

other good reason to make it visible to everybody

13:57

so that , uh , it takes

13:59

away some of that fear . Awesome . So

14:02

, um , do you , do you have any particular

14:04

points you want to help ?

14:05

us . I was trying to get you to summarize

14:07

with the top three . I think this is very definitely

14:09

close to your heart , so maybe just pull

14:12

out .

14:12

Pull out a short two or three things that

14:14

we should take away from our conversation all right , so

14:16

so my my top sort of three

14:18

things that I I typically uh

14:20

want to talk about this there is no one single

14:23

metric that allows you to measure uh developer

14:25

productivity . You're far better looking

14:27

at um your , your development

14:30

productivity versus your developer productivity

14:32

. You want

14:34

to look at the system and not the individual , so

14:38

that counts as two or three .

14:40

It's a good place to stop . I think that's a great phrase

14:43

to kind of close out with is to focus

14:45

on the development productivity , not

14:47

the developer productivity .

14:49

Awesome . Well , thank you . As always , don't forget

14:51

to hit subscribe and

14:53

yeah , so you can get to us at feedback

14:55

at definitelymaybeagilecom . Until next time

14:57

. Until next time , peter , thanks . You've been

14:59

listening to Definitely Maybe Agile

15:01

, the podcast where your hosts , peter

15:04

Madison and David Sharrock , focus

15:06

on the art and science of digital , agile

15:08

and DevOps at scale .