Don't do estimates, but I can do cadence. 19 50s microphone is in full effect.
Oh, good. Did the 19 50s call you and ask her it back? Is that what happened?
Yes. I went to a play last night. It'll clear about the 19 50s.
Did they have your microphone? Was it in it?
It was about this microphone for 2 hours.
Who says theatre is dead?
Yeah. Too right.
What did you go and see?
It was called Here I Belong. So it was about the post war and baby booming generation. And it was kinda split into 4 acts where it follows one person getting kind of older from 1953 up until 2016.
Are they using more and more modern microphones in each...
Yeah. Pretty much.
...in each part.
So the reason, actually, that I went to see it is that I don't know. There's a lot of generational politics, isn't there? There is. And sometimes it's easy to think and say things from a position of ignorance. So I think it's important to go and find out stuff about, you know, all the different generations that are around you today, and what it was like for them.
Mhmm. And why sometimes you think they don't understand the way the world is now because they look at it through the same lens that they did in 1953.
Yeah. And what's right and wrong and it reminds me of this Douglas Adams quote. We'll find a link to the original source of it, but it was something like, everything that was invented before you were born is just part of the way the world is and is just absolutely normal to you. And everything that's invented between then and when you're age 35 is new and exciting, and perhaps you can even get a job doing something with it. Yeah.
And then everything that's invented after you're 35 is clearly wrong and against the natural order of things and shouldn't be allowed.
Yeah. Too right. See, that's what we went to see. I just think it's important to try and understand. Empathy. More empathy. That's what the world needs. Yeah. Absolutely. Absolutely. Because, you know, I think there's a a lot of media coverage of generational divides now, And it's easy to put people in in buckets, isn't it, based on age or class or all the other things that we're obsessed with?
To be fair, sometimes they march indignantly into the buckets. You don't have to put them there.
Absolutely. But, you know, there's a reason for that too, isn't there?
Yeah. There is.
Uh-huh.
Certainly kept behind more empathy. Sounds very interesting. Is it still running? Mhmm.
It was. Yeah. Yeah. It's on for another few days.
So if you live in Ialkley, you could know that by the time we've edited this podcast, it will have finished, and you can't go and see it. Sorry about that.
Never see it.
I'm sure other companies will put it on in other places.
Other sources of empathy are available.
Thankfully. Because if that was the last one, that would be that would be disappointing. Hello, Ash.
Hello, Ian. How are you?
I'm super duper Super duper. Very excited to be recording this episode within 24 hours of the previous episode going live.
I still don't believe it.
No. Nor do I.
I'm still expecting to to wake up in a from this fever dream at some point.
So this will have to be our Easter episode. There's no other option for it.
Yeah. Absolutely. I propose that we have a 2 year break after this episode to celebrate our, prolificness.
A second second 2 year break.
What's happened to the yeah.
So this could be an Easter special and 2 Christmas specials and probably another Easter special. It's a heavy load for 1 episode to bear.
Well, you know, it's all about we're improving the average, aren't we? Yes. Improving the the mean length of time between between deployments.
Indeed. Yes. That might be topical in a minute.
Maybe we should use the median and then just exclude the 2 year gap, and then we'll look very prolific world.
Yes. Which is, you know, obviously, that's definitely what we should do because we didn't want our measurements to make us look bad.
We might talk about that.
Perhaps we might. So because the episode's only been out one day, we haven't had time to receive much feedback. So, unfortunately, we've got no real external follow-up to chair. Although, I did go through a short period of being a bit nervous because I said in a very bold and unambiguous statement that SMTP came from the 19 eighties. And then I had this horrible moment of self doubt and I went to look it up.
And it came out in 1981, the original spec for it. I believe that would be r f c 822 for those who like to look things up. I'll make a link to that in the show notes because I remember having to spend quite a long time reading it once, and it was quite painful.
They are dry, aren't they?
They are dry.
Yeah. I mean, purposefully dry.
Yes. And to the point.
Yeah. Yeah. But I find the RFCs very arid places to go and find something out. I understand why they are like that.
It's quite interesting watching the process of them because they're still coming out. And that was a conversation stopper, wasn't it?
It was. Well, you know, there's not too much more to say, is there?
Yes. So SMTP 19 eighties victory for Ian's rightness.
Which is what this podcast is all about, really, isn't it?
Well, let's just say, having had some
It's a vehicle for your rightness and perfectionism.
Well, maybe the latter, but I I seem to find myself having been wrong a few times recently. So I just celebrating being right for once.
As long as you accept no feedback, you're always right. Yes.
I'll, put my fingers in my ears under my headphones and sing la la la la la. Just to make sure I hear no feedback at all.
Should we talk about some things?
Oh, I think that is what we do, isn't it? So we probably should. It is.
And, Ian, I believe you have the rare privilege of of going first.
Yes. The,
This time?
Not all that rare. The privilege of going first.
Every other episode privilege of going first?
Yes. 50% of the time. Exactly.
That's not rare. Is it?
No. Percent more. So the thing I wanted to talk about this time is the slightly nebulous version perhaps of the topic of metrics because I I remember someone years ago saying to me, well, if you can't measure it, you can't manage it. So this sunk into my young brain as it was then as opposed to old and grumpy brain that I've got now. And when I was thinking about this thing, I thought, well, let's dig into that a bit.
And and so I found that this quote was being attributed to w Edward Deming, who, famously went to Japan from the United States and worked for Toyota and and, was instrumental in the Toyota system that they put in place in their manufacturing production lines, which has since come back to the IT world and the tech world as lean and all of those kind of practices, so andon cords and worker empowerment and all this kind of stuff. What I discovered was that w Edward Deming actually said the exact literally, it could not have been more the opposite of you if you can't measure it, you can't manage it. What he what he actually said was, it is wrong to suppose that if you can't measure it, you can't manage it. A costly myth. So I found that slightly, slightly shook my confidence in this this thing.
But I thought, well, no. Let's talk about it because I think people are always trying to find ways to measure things. When you start measuring something, all the people who are being measured start aligning their activities towards improving that that measurement. Sure. This is why you get these kind of disasters when people say, oh, well, developers write code, so let's measure them on how many lines of code they write.
It turns out that developers can write an awful lot of lines of code if you measure them or not and you disappear down a horrible hole of technical debt and bloat as a result of it. Mhmm. So sometimes the best thing a developer can do is write minus a 1000 lines of code in a day.
Yes. Yeah. As a as a tester. The common metrics are, obviously, number of bugs found and fixed, and then, number of test cases created and and executed. And I remember my first dedicated testing job.
That was literally your productivity measures. Literally, that was exactly what you were measured on, how many bugs you you found. Actually, they didn't really concern themselves about how many were fixed, which is actually probably the more important one. So you can you can guess the games that were played with that and then how many test cases you created and executed. But it kinda speaks to the same problem as the lines of code, doesn't it?
Yeah. It's like Yeah. You can add a 1,000 lines of code or you can add a 1,000 tests, but it depends what the code is or what the test is that you've added, whether it's the the right test and the most important test. But then with bugs as well, it's like, well, did you find the most important bugs, or did you just raise visual issues? Or, you know, I'd I'm not sure this this shade of blue is exactly as specified in the specification.
Yes. Tick v g. Another test case.
Yep. The bug failed. Absolutely. So all all those things were present there. All those things were present in that in that environment because of the way that testing was measured.
I think this extends to sales incentives and all kinds of things like that as well, where as soon as you set up a system of measurement, especially if it's linked to compensation or annual reviews or things like that, then people will try to find ways to maximize that metric, and they will do things that are not aligned with the outcomes you're trying to achieve. Yeah. But that make that metric increase. Fixing bugs is a great one. I mean, developers can create a bug and then fix it and then tick, got one.
Yeah. Well, in theory, depending on how you look at it, developers are always fixing bugs, aren't they? Yes. From the moment that they begin to create the code, they will have fixed several hundred bugs before the code even gets to somewhere near a tester. It completely depends on the point of view, doesn't it?
I've been looking around, and I have seen one particular view of what a good set of metrics are. But it's interesting. Everything else I've found as I've been looking into this has has been basically various stories about bad metrics. Yeah. But Google have this DevOps research and assessment team.
It's all tied up together with the state of DevOps reports that come out every year. They've identified some metrics that they think are good for technical teams to adhere to, and I think we've all I say we've all, probably probably not true, is it? Many teams in the technology world will have heard of that. Their big four things are deployment frequency, so how often does code in your organisation go to production, the lead time for changes, so how long does it take from the code being committed to it running in production, time to restore service, so if you break production or there's some sort of instant, how long does it take you to recover from that, and change failure rate? So what percentage of changes lead to bad things?
So they argue that these four metrics, if they are coming out well, they indicate a very high performing tech team that's delivering well. Yeah. And they've got different levels of team from elite, high, medium, and low. I guess there's probably an even lower one where they don't or worse, are unable to measure those things.
Yeah. I think that's probably one of them, isn't it? It's like you can't even measure those things because there's just some sufficient level of chaos. That you don't even really know what's happening at any one time.
So if I log on to production and tweak a file, does that count for deployment?
Well, yeah. Exactly. Well, I think underneath the discussion of the big four metrics, this is stuff that's been this data has been collected. It's been peer reviewed, and these are the 4 metrics that the research has settled upon to being the most the most effective. There's still like a layer under there where you've got to think about what your context is, what your model is.
Because it's one thing if you're an ecommerce site and, you know, you have one deploy, and then that pushes it out to whatever your estate is. But I don't know. If you've got an application which needs to be installed independently on multiple different sites, And, obviously, you need to think about well, probably think about your architecture, but also think about, you know, how what that all means for you as well. Yeah. So, generally, I'll talk about the big four as like a place to start because it's based in peer reviewed research.
For the most part, you could describe it as trustworthy, and it's linked to outcomes as well, which is always good. So it's like we've talked about before about the metrics not being anything to do with the outcomes that you wanted. Mhmm. So, you know, because I talked about the bugs found and fixed, and then test cases written and executed. But in that organization, no one ever got what they wanted out of the products that appeared.
They were all still, like, buggy messes, which didn't really do the job. From a distance, they kind of look like what you wanted them to be, but then as soon as you started using them, you were like, oh, this is not what I wanted at all. So the big four are measured in terms of the outcomes that you're trying to achieve. So they're just a good place to start for me, because it's like I say, it's based in peer reviewed research. So start there.
Figure out what it means for you. It doesn't preclude you from doing the figure out what it means for you bit.
No. No. Not at all.
Which is always behind all all of the advice on metrics is they all come with all models come with a proviso unless, you know, they're, so, you know, academically bankrupt, which is like, you need to figure out for yourself what all this means because we don't know your context, so figure it out.
Absolutely. Another thing that always strikes me about them is that they're quite focused in what they're about. And so they're about a technology team delivering stuff into production and managing it in production, and they measure the the way in which that's working. But, obviously, before you get to the techno technical team, you've got business people with their own view of of what's going on. And after it, you've got the end users who are using the thing.
And you probably need some other metrics just to maybe put around that that Yeah. Recognize the greater length of that kind of value chain.
Yeah. Because, you know, in some organizations still, you may not have the ability to put your code into production. Yeah. So it completely depends on, like, the remit of your technical team, doesn't it? And there's nothing more frustrating for a team if you start to measure them on a metric which they don't have any control over.
So if you say, well, how come we haven't done a release to production this week? When you're like, well, actually, we've got 4 releases queued up, but the operations team, because of the way the organization works, they're the only ones who can do it, and they won't let us near it or, you know, whatever what whatever it is. But it's more of a wider point, isn't it? It's like, if you measure something that you don't have control over, then it's it never seems to me like a particularly good measure, and it only leads to frustration for the team that a manager might make responsible for it, but they don't actually control it.
That's really difficult. But on the other hand, I suppose, there's a kind of thing there where the team might find out dispiriting. But actually, the bigger picture is pointing to where the problem is.
I guess that's the next step, isn't it? You have to actually go to where the problem is. Go to where the actual bottleneck is and start to work on it and elevate it and find ways to alleviate it.
We're back to the goal. Yeah. And the factory with the big piles of materials on the input to the deploying it to production station
Yeah. Absolutely.
And seeing where the materials are piling up.
Yeah.
On the inputs to know that that's the thing you should optimize for your end to end Yeah. Process.
So I guess that's the other way to look at metrics is that they're a signal, aren't they? They have something to follow, something to say, oh, hey. Well, why does it take, you know, this long to do this thing from code commit to it running in production? Why is that suddenly so long? Alright, okay.
Because it's, there's actually 4 teams involved in that. Whereas what we should be doing is saying, well, the one team who's responsible for the code should be the ones who are should have control of that process. So then we can get that that metric down rather than it being an an absolute thing linked to
Yeah.
Yeah. I think a danger, like, as you alluded to before, was, like, you bring these things into, like, people's performance.
Oh, yeah. That's just no. No. Don't do that.
See see because, again, it comes back to the a few episodes ago, we talked about, like, 65% of functionality that's ever built is never used Yes. Or rarely used or or whatever it was. And in theory, we should say, well, we should be looking for the, you know, top 20% functionality that makes the most money and brings the most joy and just build that and then take the rest of the time off. But I don't think that would please a metric, would it? No. A certain metric. Sorry.
Metrics are notoriously implacable.
Yes. And they're often linked to productivity as well. And the obsession with productivity, rather than doing the right things, it's doing doing more things.
Yeah. That's an interesting thing, isn't it? Because the other question is what's a metric for? And I think that what you just said about this thing of metrics being used to evaluate people's performance, the more I I think on that, the more anathema that seems to me. Yeah.
I think that seems to be the worst possible idea. Because, actually, what you're trying to do is make a system of moving parts work better end to end. And there's no good blaming a team if there's a big pile of stuff on their input. Yeah. What you need to do is to look at is to look at and try and understand what is the reason for that.
Is it because they are under resourced? Is it because there's something complicated about the way that they have to do their work that we should is it because there's not enough automation? Yeah. Yeah. I mean, clearly, there's a need to evaluate the perform you know, if you're paying people to do things, you need to know that they're doing them to the standard that you're paying them for.
But that seems to be a different conversation than measuring the efficiency of your system that's putting things out into production.
Yeah. Metrics for individual performance and for productivity, most I would say for the most part, they describe, like, local optimization.
Yes.
So as in working furiously on a part of the system which where there's no bottleneck or it doesn't really matter or it doesn't make any difference to the, you know, to that, like I said, the wider delivery of the system. So I guess that's the other thing with metrics as well. Are they used as evidence for or for for local optimizations, or do they push the teams or the people who work on the teams in that direction to look to optimize, like, their little bit? Yeah. I guess that's the point, isn't it?
If you're looking to optimize that little bit, then that's the real cost of chasing metrics, isn't it? Because you end up just locally optimizing and ignoring the wider system.
Yeah. And I guess that's what's so great about the DORA metrics is that they force you to consider at least the technology team's output as a whole. Yeah. And if you are doing pointless local optimizations, then you won't make any difference to those metrics. Yeah. So you probably won't do them.
Yeah. I think what when you look at the those 4, they're actually incredibly well designed, aren't they? Yeah. Yeah. Because they are specific, but they encompass a great many different functions within technology, that you would need in order to, a, be able to measure those things, and, b, in order to get better at them Yeah.
And improve them. So they are very specific, but they I think they do encompass many things that you need in order to be a better delivery of technology function, if you like.
Indeed. This may be an aside, but I always remember being measured on, billable utilization
Me too.
Which was a thing over which I the the people that really controlled that were how good were the salespeople Yeah. Who were selling the projects for me to work on. And if they didn't do very well, there would be no projects to work on, and I would theoretically then be, miss my my target for billable utilization. And it was just I remember being annoyed and frustrated by that at the time. It's all about that thing of can you control the thing you're being measured on.
Because, obviously, sales is an act of trying to trying to achieve the sale. And then but utilization is just you know, it's a fairly sort of static thing, isn't it? You know what I mean? It's just like, well, I am on this thing.
Yeah. It could be a proxy for desirability relative to other similarly skilled people in the organisation.
Yeah. But Yeah.
That's a very vague and hard to measure.
Yeah. But I guess that's the thing. It's like, what about the hard to measure things? Like, how happy people are in their roles?
I know you can measure that.
Is there a happiness index?
There are actually quite a lot of apps that you can buy as a company. I think they're quite expensive, a lot of them. They send out automated one question questionnaires to the team every month Yeah. And the team or every week even. And the team just press a button in the email to to say, I'm feeling happy.
I'm feeling like my work is under control. I don't know. Whatever it might be. And and then they can plot happiness over time, and you can start figuring that out. I think, actually, if they're genuinely anonymous and people believe that they are, then I think that actually works reasonably well. But I'm not sure that I'm I'm not sure that's an answer to your your point. But
No. No. I know what you mean. I guess there's there's, like, different levels, isn't there? You've got you've got kind of that I would describe that as a fairly sort of shallow metric.
Not in that it's not useful, as in, you know, a person receives a a message of some description then clicks on a button to say, yeah, at this moment I'm feeling, you know, good, bad, frustrated, whatever it is, whatever the options are, then, yeah, I think you can get some you can get some good stuff from that. And I think it's yeah. It's I said the anonymous part of that is the important part
as well, isn't it? Yes. It has to be
Ash has clicked. He is frustrated for 2 days in a row. Release the hounds.
Yes. Yes. The, mister Burns School of, Employee Happiness.
Yeah. But, again, that's that's an interesting thing to measure, isn't it? It's like, I I often think of how do we know we're building the right thing, and how do you measure that as well? Oh. Rather than all the tons of stuff that get built that don't do anything or maybe are just context and contributory to other things. But how do you measure that kind of work as well? So, obviously, we then come up with measures like, well, how much money has it made? It's like, well, okay. The
Also, you could, instrument your code. Yeah. So you could, at a feature level, instrument your code to say to increment a counter in a database somewhere whenever someone uses that feature. But Yeah. Yeah. These it's all a bit blunt instrument, isn't it?
Yeah. And it's like, hence, the interpretation as well, isn't it? But I do think there's probably is a role for systems to aggregate and present this data. You know, like, we're talking about, like, happiness data. And it's like, well, actually, could you systems can help and say, well, actually, in this in this particular part of the business, then more people are are clicking.
I'm frustrated. You need to be able to compare it, like, over time as well. So I think systems, they can help with these things, can't they?
Yes. They I think they can. Although it reminds me of I remember playing a role playing game in the 19 eighties called Paranoia, which was a postapocalyptic game. The setting was a place called Alpha Complex, which was the only human underground base that had survived the the terrible nuclear, whatever it was that was imagined. And it was run by this computer who, who pretends to be on your side but isn't really.
I remember the catchphrase from it was, the computer wants you to be happy. If you're not happy, you'll be used as reactor shielding. Don't know why. That's always stuck with me.
I think that's because there's truth there, isn't there?
There there is. Yeah.
Yeah. There
is. So I don't know what the one true answer is for metrics, and I could see the vast array of of bad answers. But I think I agree with you that maybe those, those 4 doro metrics would be the starting place. Yeah. And and getting yourself to the position where you're able to measure them as well because you have to get onto the starting line of now we're gonna track some things that we weren't tracking before.
Yeah. And then it doesn't preclude the we need to think about what this means for us No. Part of it.
No. Although
Which is the that's the really valuable part, isn't it, for the organization?
It is, but it's also the part that you can, if you're cunning, you can defang the whole thing and make it not Yeah.
No. Absolutely.
Have an impact because you're just gonna use oh, well, how it works for us is that, we're only gonna count this, or we're not gonna we're gonna count that as a release to production, or we're gonna Yeah. Yeah. All the equivocations that you might make.
Yeah. So say if your team, doesn't have access to production to deploy, then you could say, well, actually, the team has deployed x number of releases to the staging environment or the customer test environment or whatever it is. And is that okay? It's like, well, you could argue that because then the team could then just pile up thousands upon thousands of releases in customer test, and nothing goes to production.
Ops team in the accountability and the metric.
Yeah. Again, I think it's it's a it's specific, but it's holistic in terms of all the functions that you need in order to make that metric happen. Right? Mhmm. So it's like in your context if you sudden if you don't if you need your operations team to get something into production then your development team or your operations team, by its nature, then have to work together, don't they, to make it happen more often? Yeah. So and that's the the behavior it's trying to encourage, isn't it?
Yeah. Yeah. And there's all the cultural change associated with breaking down those walls between these the walls of blame between the different functions and things like that.
Yeah. All the good stuff. The hard stuff.
Yes. But But interesting stuff. Yeah. Hard but interesting.
Hard but interesting.
Okay. So, yeah, I'd be interested to hear what any of our listeners think about this
No. Indeed.
And, what their experience of metrics, good and bad, might be. And then, if you let us know, then we'll we'll talk about it in the beginning of the next episode.
Yeah. Please
do. You can reach us on Twitter at at what a lot of thing. I still think that's funny after all these years. You can comment on our LinkedIn post for this episode or you could find our Instagram video from 2019.
Marvel at that.
Marvel at that and then comment about metrics underneath it, which would be slightly bizarre, but, you know so, yes, get back to us. Let us know what you think. So that was my thing.
That was a great thing, Ian.
Thank you. Cool. So what's your thing, Ash?
My thing is called well, so it's it's kind of a personal thing as well. So a personal story which feeds into a a a wider trend, if you like, on on the internets. So I've I've called it scrumbashing. Uh-huh. So I came across a a website the other day called, scrumsallegiance.org, which, is a direct parody of the, I think it's the
Scrum Alliance, isn't it?
Scrum Alliance or scrum.org site. It looks very, very similar to one of those. And it talks about how becoming certified in scrum can enable you to become much more average, but get paid more, and how scrum will be about crushing individuals and their creativity and, standardizing everything and making the world a much more terrible place.
I've just opened it up now, and it says, you seek legitimacy. You want certificates. You achieve mediocrity. Your business has been ignoring the challenge. Oh, no. I'm not gonna keep reading it, but, yes, what what you said there.
So I find myself laughing at that. Yeah. But so here's the personal bit. So quite a lot of years ago, I went to do the certified scrum master course. I fought quite hard to be able to go and do that.
Mhmm. You know that thing where you're at an organization and you have to, like, justify going to do a training course to, like Yeah. You know, out of existence, basically. And it's like a you have to close all the logical loopholes as to why you couldn't do something. So, basically, the company can't refuse you anymore on under any reasonable grounds apart from saying that they don't like you.
So I went to Manchester. It was offered in Leeds, obviously. I did the certified scrum master qualification, and I was really proud of it when I got it.
Mhmm. Well, you would be.
And I've been really looking forward to it. And when I did the course, there was a couple of people I met on the course, Steve Trapps and John Fulton, who I'm still in touch with today and still work with sometimes as well. So I made really good friends, learned a lot. Loads of people were there from loads of different size and shape organizations. We talked about loads of great things.
Then when I had it, I I felt confident. I felt good. Yeah. I felt like I'd learned something, and I had something, like, new to contribute. So I was seeing, like, testers were, often moving towards, like, scrum scrum master sort of roles and having the the certification to back up the VAT sort of momentum, if you like, of of moving into these different roles.
I thought, oh, that's pretty cool. So I even took it, like, one step further as well. I went and did the certified scrum product owner course as well.
Oh, wow.
So I was a CSM and a CSP, which, again, I kind of once I'd done that, I I felt like, oh, I've I've gained something else there as well. I've gained a bit more confidence. So when I'm speaking to product owners about things, I've got a bit more insight into what they're thinking. I was like, this is cool. And then the world turned a bit or gradually started to turn.
Maybe certifications just got bigger and bigger business, and everyone started doing them. And then the the sort of chat about them being meaningless tick boxes, which offended me a bit at first. So that sort of started to it started to come out. And that doing scrum, like, wasn't being agile. You know, they're doing versus being.
So you're just doing scrum. You're not being agile. And then, well, scrum's for managers and not developers. Developers hate doing scrum. And then loads of teams were like well, we're gonna be doing Kanban now and so a full on rebellion and then eventually it was like well only, like, the banks and government with that sort of glacial change of, progress.
And now they're doing scrum. And then, of course, you had the scrum dimensionalists. We talked about that a bit Yeah. Yeah. Earlier on as well, didn't we, saying, well, you don't like scrum because you just aren't doing it properly.
You're not following the guide. Yeah. So there was just, like, this constant sort of wave of of negativity which is sort of gradually growing into a bit of a tsunami. And then I find my I find me doing it now as well. So I'll go to, like, a particularly crappy planning session or a pointless retro.
Everybody just bones about things that are outside the team's control. And, you know, you go to a stand up where someone asks you what your status is. So and I find myself complaining about scrum now as well. I said the other day on my last client, actually, I was like, the problem with scrum is that you stop working. You just talk about scrum all the time.
Nobody does anything anymore. You just talk about scrum and all its ceremonies. Uh-huh. And that's that's, like, the team's job for for, like, you know, for the foreseeable future until you decide you you don't wanna do scrum anymore, and you're gonna try Cat and Bun. So I'm just like, how do I get from being proud of my certifications to joining the the cynical masses?
There's so much interesting that you've just sort of said there. And there is this kind of the thing is that the accusation that certifications are just big business is not a 1000000 miles out. No. You know, there's certainly a lot of money that is made sometimes for providing perhaps not all that much. It's a brand thing.
You know? If the Scrum Alliance says I know Scrum, then I then I must do. But the cost to them of asserting that is quite minimal compared to the amount that you have to pay for it. But there's a way in which certifications are brilliant, And it's quite interesting actually if you look at the different disciplines of engineering. If you're a civil engineer, then your job is you design, build bridges, and and, you know, maybe infrastructure things.
And you don't get to just do that. So in the UK, you have to be a member of the Institute of Civil Engineers and you have to be recertified every so often, all those kinds of things in order to continue to design bridges. Because if you let anyone design a bridge, then the chances are that eventually it's gonna fall on somebody and people are gonna get killed. And you look at software and you think, well, actually, software is everywhere now and software can kill people very easily
Yep.
In in many contacts. It can also be very annoying in some context, but I guess, that's doesn't quite have the same seriousness. If software can be safety critical, why isn't there a professional body that you have to be a member of in order to be a software engineer? Yeah. And the answer is it's just not evolved like that.
And in the UK, the British Computer Society has a thing called, certified IT professional, and it has other so they're working on professionalizing IT. You know, you can be an open group certified technology architect. In fact, I was for a bit. And, again, that's, you know, you have to submit case studies and and evidence that you're you're practicing as a as an IT architect or a technology architect with successful results. Otherwise, they won't they won't certify you.
So in some ways, I think that the IT industry needs a level of professionalism in that way to be added to it. I'm not sure how thick a line you can draw from that Yeah. To being a certified scrum master. But I think it's it's important to have professional standards that we must adhere to because the work we do justifies that and it's not always it's not always present. Yeah.
So this is my kind of ambivalence around around certifications. But I always applaud when I see people passing their AWS solution architect Sure. Qualification or the scrum ones or anything else because I believe that you need to build your skills and proving it with these certifications is a is a really I believe it has a lot of value.
Yeah. Yeah. I think, like I said, the internal due have not coalesced around us set of it's probably way too early for that as well, isn't it, to coalesce around a set of standards, if you like?
What? Early days?
Yeah. Early days.
Unlocking Bitcoin.
Early days. Early. I'm gonna get my blockchain certification, and then, you know, 2 minutes later, it'll be out of date. But it's probably, yeah, it's probably too early to coalesce around these in technology. But I also think that whatever certification you've got, there's gonna be some value in there depending on what you're doing.
Right? So I I kind of mentioned the specific use case where it's like a lot of testers were stepping up or stepping into scrum master type roles or doing more of that type of work, whether it was facilitating ceremonies or writing user stories, whatever it is. Yeah? Yeah. So it had very it had some value for me at the time as well.
On the same course that I went on, a particularly large I think it was a building society round around here had sent all of their project managers on it, and they were like, I hate the phrase, but, you know, like, sheet dipping them into scrubs. So that's a that but there's there's kind of another argument there as well where it's like so I had I had I had identified something that I wanted to do that was gonna be useful to me in my context, whereas for for those other people on the course had been they had been, volunteered voluntold to go and do this particular qualification because, someone somewhere in their technology function had said, right, we're doing scrum now. So I guess it's like treating treating certifications with the right degree of skepticism, and then also picking the one that's, like, useful for your context versus everyone in the company must go and do this thing. I see those as as 2 kind of key habits, if you know what I mean, of recognizing how useful certifications are.
Yeah. I mean, the other and I feel like I mean, it's interesting that term sheep dipping is hilarious to me because it's just you know that you're not you can't feel significant in an organization that sheep dipping you in something. You know?
It just removes the ticks, basically.
It puts you in the role of the sheep, which is not a great
No. It's not it's not the nicest phrase. No.
To me, it's coming back to this scrumdomentalist thing
Mhmm.
Since we're, we're making new compound words like Volum Toll. That was very good. But it comes back to this kind of scrumdominalist thing because one of the things that I really believe is that teams should have teams should reflect and then they should change what they do. Yeah. And, yes, this but there's this kind of feeling among some scrum people that teams should do exactly scrum and, not a jot else and not a jot less, which seems to me to be against the idea of reflection and feedback and improving the way you do work.
It seems fundamentally opposed to it. Mhmm. And I don't know what the scrum alliance's position on on this is. I feel as though they have some safeguarding position where they say, well, you know, we're not gonna let you call anything scrum that isn't scrum, for example.
Yeah. From a intellectual property point of view.
But I I feel like if we're not allowing people if we're trying to if we're using it as a straight jacket, I think that's a I think that's profoundly wrong. Maybe it should be a starting off point. Mhmm. Because the other thing that happens is people just change the names of their meetings. Oh, we're not gonna have a product update anymore.
It's gonna be called a stand up. And we're not gonna have Yeah. We're not gonna have the, the wash up meeting anymore. That's gonna be called a retrospective. But the the content of the those those things stays the same. I don't know. I think this is a that's a slightly different point, isn't it?
Well, I don't know. Because, the thing is with things like Scrum, I'm always slightly suspicious that whether or not it was intended in this way, that it it will just be used as camouflage. Yeah. So it's similar to safe, isn't it? It's like, to me and, again, this is my this is this is cynicism coming out. So you could probably include safe bashing as well as scrub bashing, is that, to me, safe just looks like cover for what your organization already does. So
Oh, you heard it first here. Yeah. Fighting talk.
So I would actively avoid safe implementations if someone said, oh, hey, Ash. This is the job of your dreams. We do safe. I'd be like, well, you haven't seen my dreams.
That's the kind of dream you wake up sweating from in the middle of the night, hoping it doesn't come back.
Now, I guess, I have the nagging feeling that scrum, it it probably wasn't intended to be, but it might well be just, like, a a bit of camouflage for what you do now in order to look like things are changing when the behaviors underneath are not. And the the the system the system emerges intact. Yeah. And systems are quite good at that, aren't they?
They are. Yeah.
You know? So, you know, you can start a process and get rid of all the people who did the process and instantiated the process,
Yeah. People don't like that.
Yeah. Yeah. I mean, after I did my, the 2 scrum qualifications, I went and did the I've already collected more, actually, now I think about it. I went and did the the lean kanban foundation course, which was really interesting as well. But, again, that that kind of changed a few things in my head too.
So I was like, that was the first time I'd really been introduced to wider systems. And I think I think there was a certification involved with that, but nothing that had, like, for good or ill, the industry recognition of a certified scrum master or certified product owner. But, again, it was, like, part of my learning journey. So my I guess what I'm trying to say is my sort of learning journey is included certifications, not certifications, other things that are just kind of, you know, off the beaten track a little bit. So but they've all been part of it.
They've all been part of, like, me becoming who I am, and thinking the way that I think. So so maybe I have just, I don't know, maybe because of that appreciation of wider systems, you start to see the limitations of what scrum is. And then you start to sort of think, well, actually, maybe there are a lot of flaws in it which I couldn't see before, and that's why I've become a bit more questioning of it to the point of being a bit cynical sometimes.
Well, I think when you start using things, that's when you discover what their utility is, your real utility is. Because I've remember being fooled loads of times by methods. And you look at a method and and you just think, oh, yes. This is wonderful. If we just did this, it solves all of the things that are causing us all these problems.
It would be wonderful. And you try and do it, and you realize, well, actually, it's still hard. Yeah. There's still, a load of stuff there that will actually it'd be nice if the world matched this, but it doesn't in this case, that kind of thing. So I I I think it's the practice may maybe if they did a scrum certification that was similar to what I remember doing as an architect, as a technology architect, where instead of go going on a course and passing the exam, you write case studies that are peer reviewed.
Yeah. And you explain what you did and and why did you do it and how did your project vary from the scrum methodology? How did it employ it? Why did you take those decisions? And you have to write all that up and explain it to somebody Yeah. Even in an interview or something. But it's that kind of rather than showing that you know facts, it's examining your actual real world usage of it. I think
Yeah. Yeah. You've kind of applied them and then varied them, you know, where you need to.
I found it tremendously difficult to do those things. It took me years of procrastination to write a 3 case study explaining why I'm brilliant. It doesn't come naturally to technical people, I think, quite often.
No. I do remember looking a bit further ahead to the the certified scrum professional program, which I think did say do things like that, you know, write down the case study. Yeah. But then, you know, that was that was too busy doing the work by then, to stop and think about the work. Yeah. So I think you can do things like that. And I think I'm I'm with you there. That's that's where I think the value truly is, isn't it?
Yeah. I mean, that's how to evaluate it. One final thing that has just occurred to me about this is that we've not said there's a word that's been conspicuous to me by its absence. We haven't said the word agile. Why do you think that is?
So I think I said it Okay. I think I did say it once. Well, I wasn't listening. It was more at the start, it was more like just doing scrum wasn't being agile. Yes. So, you know, that but it was meant as a, an accusation rather than a, but I do know what you mean. I do know what you mean. It's like but, again, it's another you could probably we could probably have another thing in the next episode called agile bashing, couldn't we? Which is very kinda similar.
We could get We could get black cards, couldn't he? We're down with this sort of thing written on them.
Down with this sort of thing. Yeah. Yeah. Too right. Too right. So, yeah, I think I I know what you mean, and I do think that there's probably like I said, there's something in it where the 2 have been used interchangeably. I remember going to a talk when someone referred to Scrum as Agile Scrum throughout, and I was like, if you say that one more time, I'm literally gonna get up on stage with you. I didn't. I just thought that.
Would you would you just stand there like the, like the owl?
Get out, mouse.
I I, I'm going to we're gonna have to find a way to link to that that picture of the it's from the first Winnie the Pooh book, which is now in the public domain, and there's a wonderful picture of owl frowning at Winnie the Pooh that we will,
Winnie the Pooh has just said a gel scrum. Yeah. And the owl is frowning at it.
The owl is you.
Cool. That was my thing.
That's a great thing. I feel like we could probably have talked for another hour about it in the kind of Yeah.
Yeah. There's a lot of that as well.
Increasing technology EOR terms. I think that was a brilliant thing because there's just so much of interest in it to talk about. Mhmm.
Yeah. Definitely.
Fabulous.
Okay.
So I forgot. Is this our Easter special? 2024?
It's Valentine's Day special.
Valentine's Day special. Yep. Well, I've gotta say, Ash, that is the tightest deadline you've ever proposed unless you're referring to Valentine's Day in a different year.
Exactly. You see? Now you're understanding my, estimation, quoting, forecasting capability. Yes. Just make it as vague as possible and just let other people fill their assumptions in. I said Valentine's Day. You assume that that I meant the whenever Valentine's Day is.
I was just thinking that romance is not dead in this podcast.
Is not dead. It's not. So, yeah, let other people fill in their their own deadlines. And then they say, Ash, isn't it ready yet? I go, oh, you made up the deadline, not me. I never said that. No wonder no one ever asks me for anything anymore.
I do. That's probably my undoing, isn't it? Is there anything else we have to tell the lovely listeners before we go?
I don't think so. We did the get in contact in the middle, didn't we, this time? We varied we we varied things up.
Yeah. And two instances of laughing at at what a lot of thing would be, well, I think it would put me over the edge, to be honest.
Not that much hilarity.
That much hilarity, but just too much. Mind you, people are joining our LinkedIn group, so it's not just the 2 of us.
Oh, it doesn't feel quite so exclusive anymore.
Candlelit LinkedIn group. See, see, romance, not dead. But, no. We've, we're having a, last time I looked, it was a intimate group of 7. So welcome to all of you who've done that. And all of the rest of you should do that as well.
We'll get you on the certification track soon.
Yes. Certified certified technology EOR.
There you go. Let the madness begin.
Yes. Should we charge £1500, I I guess, for the course?
More than that. More than that.
It's it's a priceless certification, isn't it?
Priceless certification. You just keep paying.
It's because it's the gift that keeps on giving.
Yeah. Too right. So you should keep paying.
Obviously, I think we're gonna have to pay royalty to to Mary who came up with that turn of phrase in her, review of our performance as podcasters.
Okay.
Brilliant. Okay. Well, thank you very much for listening, everybody.
Yeah. Thank you.