Transcript — S2E2 — Learning to Learn

Rhyd: In today’s episode, I’m talking to Karl Scotland, who’s the Agile Transformation Service practice manager at TEKsystems based in Brighton. He’s also a veteran speaker at conferences across the world that specialize in software development. Hey, Karl, thanks for coming on the show.

Karl: Thanks for having me. Good to see you again.

Rhyd: And you, it’s been a while. So Karl, what are you rethinking about at the moment?

Karl: What am I rethinking about? I guess it’s how do we go about transformation? TEKsystems, I’m a lead the Agile Transformation Services practice. We have organizations through agile transformations, but actually it’s not just limited to Agile. It’s Just any sort of change. And I guess the challenges I see most organizations have nothing to do with whether they’re agile or not. It’s just about how they go about a transformation. So I think there’s just huge opportunities there and the the successful organizations, I think, it’s not about the practices and tools that they use. It’s their kind of the culture and their approach to change. And, to put it bluntly, not treating change as a one-off project that you get done and you finish and walk away.

Rhyd: Yes, I understand that. I think my experience companies often think we can just bring some outside people in to help us, and they’ll sort all of our problems out in a short space of time. But, too often they focus on technology when actually it’s not technology the problem, it’s people, it’s culture and all that kind of stuff.

Karl: Yeah. It’s Can you c come in and just give us a solution? Tell us and or just help with the solution. So the, I dunno whether it’s just, I’ve been in different conversations, but hear a lot recently about target operating models and. Blueprints and, we’re just gonna design a blueprint and implement it. And that stuff’s probably been around for a long time. Maybe it’s just as agile scales. We’re hearing more about it in the Agile community. How do we help organizations take a different approach, which is just, one step at a time, running experiments, trying things out, seeing things are improving and learning.

Rhyd: That’s the tricky bit. And like you say there’s no easy solution. It’s often quite difficult and can be protracted, but ultimately, Done right. It can really reinvigorate and help companies, adapt to the fast paced changes that’s happening in the modern world.

Karl: Yeah. And that ability to adapt. So it’s, actually you’re helping organizations to to learn how to learn. So that, we can go in and we can sell ‘em a solution. And that might be the right solution today, but in six months time, it’s probably not gonna be the right solution. If they don’t know how and why that solution was designed the way it was. They’re just gonna keep using it. Whereas if you can help them design their own solution and understand why it’s designed that way then when things change, they can go, oh yeah, now we know how we need to adjust and adapt ourselves.

Rhyd: In addition to the work you’re doing with TEKsystems, I know that having seen you at multiple conferences over the years. You’re, you’re a frequent speaker especially on topics around an agile development I think having a very quick look at your website, you must have spoken at over a hundred conferences over the last 15 years or so. Is there a common myth about being a speaker at sort of these types of conferences that listeners might not realize?

Karl: I think people look at speakers and going, they’re a really good speaker. I couldn’t do that. I don’t think I’m a great speaker, to be honest. I look at other speakers and I go, I wish I could speak like them. And I watch myself back and I go, oh, that was, you know, and, and I come out at the end of every time I do a conference speaking, thinking I forgot to say this. And I, and I messed that up bit up, and I should have explained that in a different order. And yeah, some of that is just, the experience of giving a presentation, and the first time you give a presentation is pretty kind of rubbish. And by the, and generally I’ll, I dunno. I guess I’ll give a presentation for a year. And you give that presentation multiple times over the year and you are iterating on it, so it improves and at some point you go, yes, diminishing returns. Now I’m a bit bored of this one. I don’t wanna get my teeth into another topic or, get, I’ve now got something else I’m more passionate about that I’d rather talk about. And you you move into another cycle of the same thing. But yeah, I guess what people when they’re looking at speakers is you don’t see all that. You just see the talk on the day. You don’t see all the, the work or the thought or the, the cock-ups that have gone and before that. But also you have no idea what the, what that person is thinking and feeling. Things always look better than they actually are. But, I imagine most speakers probably in the, same place I’m at, that they go, I fucking, you can always do things better.

Rhyd: What got you started in it? I’m interested to know how you ended up doing so many.

Karl: A few reasons I guess. One is just, It’s an opportunity to travel.You get to speak as you, you get. But also some of it was I guess giving back a little bit particularly for when it’s, meet-ups rather than big commercial conferences. It’s, I learned a huge amount from the Agile community and by going to meet-ups and meeting people at and kind chatting with them. And there’s a point, it’s actually I think I. I think I can now give that back to the, the new generation or, I can share my experiences with a kind of a people look that can maybe benefit from that. So some of it is that some of it is just giving a talk. And it’s the same with, I found the same with blogging. Writing, giving a talk really forces you and helps you think through a topic cause if you can explain a topic kind of succinctly and clearly to an audience, it probably means you’ve you’ve got your head round it yourself. So some of it is just, it’s just a, it’s an excuse to deep dive into a topic and kind of get your head around it and put a few things together and clarify my thinking. And the talk is just then the thing that pops out at the end of it. Similarly, or sometimes I’ll, I’ll do a talk and actually to help me improve the talk, I’ll write the talk down as a blog poster or an article cause then that kind of, again, that’s a different way of formalizing and getting things. Straight in your head too. So you’ve gotta got a good flow and a good narrative.

Rhyd: Having done it for obviously till 10, 15 years or so, do you ever look back at the stuff you talked about initially and think, oh I wasn’t really on the money there, or have you gone back and thought, actually I’ve learned a lot .

Karl: Yeah, there’s definitely stuff. I guess I’ve not done it, but yeah, some of the early stuff probably, I’d go, I wouldn’t say that now. Because I’ve either learned new stuff and changed my opinion, or I’ve just found better ways of doing, solving that problem or describing those things. A bit of both. I I don’t worry about it, it’s just, in fact, I would probably worry if I hadn’t learned new stuff, cause that would just mean I was stuck in a rut and saying the same old stuff and over again. And that’s, I guess that’s another benefit of doing the conference talking is it forces you to Dive into new areas and figure new things out. And sometimes you’re like, I wanna talk about this subject. But actually I don’t really think I know enough about it. So I’m gonna go off and do some research to make sure that I’m not just, I’m not just using a pithy quote that I’ve picked up from someone. I’ve gone back and read the source and I understand the context and I understand what this person was really trying to. So that, then I guess there’s, I do quite a lot of reading as well around that as well then. So you’re trying to be authentic as possible.

Rhyd: What event made you pause for a moment and rethink work and life?

Karl: I think it was I. going back to when we were first working together. So I started working at the BBC and I’d moved from a job, which was I guess cause I didn’t enjoy I enjoyed the people I was working with and it was, it was good fun, but it was, weekends, long hours. Writing crappy code cause you were being forced into it. With ridiculous requirements that there weren’t requirements. and just, dealing with, it’s like those are things that kind of, there’s gotta be a better way of developing. Like surely not everybody writes software like this. And that’s when. I guess in the process of trying to answer that question, I came across Agile and extreme. It wasn’t even agile back then. It was, cause this was probably 1999. Extreme programming. I think even such a long time ago, my memory was a little bit hazy, but I think it was even before Kent Beck’s extreme programming book got published and it was just stuff on the C3 Wiki. And the might have been an extreme programming mailing list or some sort of, the Yahoo groups as it was back and just getting into that and going this makes sense. It’s like why isn’t everybody doing it like this? And now I understand. What we were doing wrong and now I understand what I’d like to do differently. And the BBC I guess was the opportunity is like clean slate. It was the, like the perfect sweet spot of an environment to try things out. Because we were dealing with, bleeding edge technology just writing code that, was, never gonna be seen by the general public cause we were trying things out and, no real deadlines. We were, I guess in some ways ex extremely privileged to have that luxury. But, great kind of playground to start going, what does unit testing look like in this environment? And let’s play around with pair programming cause there was no real pressure go, you can’t do that. And, mutual friend Chris Young at the time was, was of my manager and was, extremely supportive. So yeah. That, I think that was, that moment. It was like, yeah, this does work. Now I’m of really interested in this passion about it and, complete, I guess career change where I was a developer back then. I’ve written a line of code for, I can’t remember the last time I wrote a kind of line of proper code in anger.

Rhyd: So for listeners who don’t know what Extreme Programming is, I think, it was an antidote to the old style. Software development, which was, what’s the term is banded about quite a lot in our industry was the waterfall approach where, you try and work out all of the things a system should do. You’d write that in a big document, you’d go and discuss it before anyone touched the keyboard, no one actually, wrote any code. And then that whole process would take a long time. So extreme programming or XP was created by people who were frustrated with that. That whole approach is that.

Karl: Yeah. I Yeah, XP I guess grew out of, how do we make life better for programmers? No, it wasn’t exclusively programmers, it’s like programmers shouldn’t have to sit there and work late and do long weekends and be forced to write crappy code. The, we should have a say in this. We’re professionals, so this is how we wanna work. Cause of, can the XP which we think is better for the business and better, for better, for people, is much more humane. So yeah and it really was, yeah that focusing on the value and what’s the small amount of value we can deliver. And that’s the other where the idea of user stories came from. So let’s just take a small story about how the user interacts with the system and let’s make that a reality, and then let’s see what we can learn from that. And then watched the next one. So that then became, highly collaborative, one within the. The team is really working together rather than having these silo specialisms, but also working closely with customers and the business to really understand and what they want and get feedback from them.

Rhyd: When I joined the BBC back in 2003, that was my first proper exposure to that way of working. I remember joining your team and being reasonably surprised by at first it felt a bit chaotic. But in a good way,

Karl: It was sometimes

Rhyd: Yeah. But it wasn’t, it wasn’t like masses of documentation being written. There were index cards, post-it notes everywhere. There was I dunno whether you introduced it or someone else, but it was almost like a gold card day where someone, you could just say, I’m gonna go and work on something that’s not related to anything we’re doing today. I wanna go and learn this. And that was really refreshing to of see, and I look back at that as that’s when I realized that the, like you say, there’s a, there was a different way of working. And having been only a few years out of university, it was a real eye-opener. It definitely laid the foundations for me ever since then to make. The teams that I work with, we’re not wasting time on stuff that doesn’t make sense. And we’re trying to, like you say, build in small increments and that kind of thing. Did that experience then at the BBC did that sort of lay the foundations in for you as well in terms of your career and the decision to go and do talks and that kind of thing?

Karl: Pretty much. I, so I think the first talk I gave was describing the way we worked to the BBC cause we were in this kind of quite a kind of niche context, I think in the technology we were dealing with, which was, the three, I think about it as there were three very distinct technologies, which were the, the two platforms and the back-end stuff. And you couldn’t possibly know about all those three technologies or, that was in a real unicorn. I think, there’s maybe a couple of people that could do that there. I certainly want one of them. So how do you manage that? And also just the nature of the, they were of quite small projects, weren’t they? They were four to six weeks. But by the time when you joined, digital TV had gone live. We weren’t in this kind of playground anymore. So we, we had broadcast deadlines, so we had fixed deadlines and that’s where a lot of that kind of chaos came from. cause it’s like we’ve gotta get something done by this date. But that’s why I think, we couldn’t have done it. Without Agile to give us that kind of slightly chaotic flexibility to go if we wanna do this by this date, and this is this broadcast date, or there’s this thing and it’s gonna broadcast in the autumn, but we don’t know when the broadcast date is and we’re gonna get maybe a week’s notice of when it’s gonna go live. It’s how do you build a I now know concepts about cost of delay and all this stuff which helps it in some way, helps explain intuitively what we were trying to do. But yeah I kind did a talk and it was in, I think it was New Orleans, so going back to that, that opportunity to travel where we described the way we did this and I called it Tetris planning cause we just had a simple spreadsheet and we had these kind of three streams for the three types of technology and a row for each week. And we just blocked out weeks to go well, We think we need four weeks for this project for the back end, but hey, the front end on Sky only needs a couple of weeks and you know what was on digital lens now? Free view, maybe that’s a couple of weeks and we’d just of try and fill in the shape. But it would change every week, again, that was that kind of chaotic bit as we came into we were doing weekly planning and it was alright. Yeah. We think we’re still on track. Or you know what, we’re gonna need another week for this. Or, oh, hang on, we thought we had four weeks. We’ve really only got three weeks. What are we gonna do differently? Because the business, the business couldn’t predict or plan that far ahead. Just cause of the, the nature of the environment we were in. I don’t think we looked much further than two or three months. But yeah, as things got clearer, we were constantly kind going, let’s refine that and what new information do we have?

Rhyd: Yeah, I think that still holds true today, right? Because I often work with companies and people where they want certainty over a 12 month period, a roadmap or a plan saying, what we are doing? And you think in the back of your head who knows? You just writing it on a bit of paper and saying it will happen then is not any way gonna guarantee it does happen because the real world would interact we’ll we will pop up and, we’ll just ruin your plans within an

Karl: Yeah, it’s just blow blows things outta the water. So yeah, it is I’ll I’ll give you certainty on my plan if you give me certainty around the, what you’re gonna want and I know you can’t do that. So what’s the point?

Rhyd: How did you get started? Did you join the BBC straight from university or you mentioned that you’d come from another company…

Karl: I think BBC was my third job. My first job was I was down in Brighton doing multimedia type stuff. I dunno, was compact disc interactive. It never took off. But it was fun. So that was fairly hardcore see and assembly programming. And I look back in those days and, it was, it was really. But very agile in a, in a, in hindsight, we just didn’t know it at the time and, it was, but it was like, there’d be like a developer and a somebody from graphics and somebody who was of a, the producer who was more looking at the business and we just, and maybe a tester and we just just form a little team and swarm on it and crank out the code and test it and fix it and get it done. of that was, so that was quite good days. And then I went to this other, complete shift to a company that was doing neural network based technology. And building out, much more, professional stuff cause it, it wasn’t this fun multimedia stuff. They, because they thought they were professional then it was all, rock and heavy processes and that’s why they were requirements documents that would design documents really. As and I didn’t know any better at the time, but, I just remember the, I went, we went to South Africa and I still remember sitting for a week in a room in South Africa refining. Reviewing and finalizing the requirements document with the partners who were over there and it was requirements like, the database shall contain these columns and I didn’t know any better at the time. And then at some point you again, you get into it, discover extreme programming and user stories than the idea of, what the user wants is like users. Two hoops about the database structure. What they care about is, and it was fraud detection. It’s like what types of fraud do we detect and how do we report on the fraud? And there was nothing about that. I think one of the, one of the last. Stories I have from that kind of time was the kind of chief neuroscientist was out in South Africa trying to, cause we built this thing and it just wasn’t working. cause we built this very technical, like classic, we built a very technical product based on technical requirements without really any thought as to, to how we was gonna get used or what the value was or anything like that. And so the guys, I’m on the phone to me and she’s I figured out how we can detect this type of fraud. You just look at this data pattern. And and look for the highest value. And if you see it, so then that’s kinda, that’s your training data. And if you see a value higher than that in this field, then trigger an alert like you’re joking. That’s an if then statement That’s not a neural network. I could have written that and if, and if and if we’d focused on the value of and the the of solving, detecting the particular type of fraud we’d have probably got there. But no, we got obsessed with the technology and the neural networks and being really clever about it. So yeah, that was a kind of a nice little learning opportunity for me.

Rhyd: Nice. You mentioned RUP, which I think stands to the Rational Unified Process, right?

Karl: Yes.

Rhyd: I’ve not heard that in in probably 15, 20 years. So that brings back just feelings of dread of having to just write reams and reams of documents without really understanding why.

Karl: And UML diagrams, UML design, cloud class diagrams that then as soon as you started writing the code, were just go out the window. cause there’s only, when you wrote the coder, you figured out what there’s, which again, when you then get into extreme programming and the idea of test driven development and start small, write just enough code to make a test pass. Refactor the code to so to, so it’s a good design. And then do that and over again, the design evolve, evolves and the design evolves to, so it’s fit for purpose, for the functionality of writing rather than trying to guess that, and not only guess it in advance, but trying to figure out how to make that look nice on a pretty picture, on a piece of paper.

Rhyd: Is there any, what, is there anything you wish you’d known when you first started?

Karl: I mean everything surely, but I, dunno. Yeah, I think the flippant answer, and I guess the other side of that flippant answer is if you know everything, then you’re gonna learn anything to me that, there’s the joy of learning. Yeah, obviously you wish you’d known stuff, but then would you ever really know it in the same way? And is it realistic to know stuff? You look back and if I’d known this stuff now, if I’d known back when we were at the BBC, what I know now, we’d have probably done things slightly differently. But you know what, but all we’d have done is been tweaking what we were doing intuitively. I dunno, does it really make a difference.

Rhyd: Yeah. What you know today wouldn’t have changed the fact that broadcast deadlines were fixed or unknown.

Karl: Yes. Yeah. Yeah.

Rhyd: Yeah. So Karl, what’s coming up next for you?

Karl: Good question. Immediately, I’m starting to travel again, so I’m going to Agile India next month on the conference theme. I guess from a more general kind of professional thing. It’s working with TEKsystems to grow our practice and evolve our business. And I think there’s a, we have a real opportunity with, what we’re doing. trying to be consultants get a bad rap, certainly big consultancy and, so I like to think we’re trying to do big consultancy in the right way and in a good way where we’re not just selling people and. Selling, selling high and putting cheap people in there and all those kind of things you hear are stories. I’d like to think we, we generally have the opportunity to help our customers by, focusing on their challenges and selling them kind of real value and services. And there’s a transformation for our business in doing that. enjoying, enjoying working. You make the difference of working in the business and working on the business. Going out and working with customers and, being billable and utilized and all that, and the stuff that they want me to do, but also, working to help transform our own business is, to think that we’re perfect as a business ourselves is I think, a little bit naive.

Rhyd: Yeah, there’s always room for improvement. And if anyone wants to get in touch with you, Karl, what’s the easiest way

Karl: I was gonna say Twitter, but actually I’m trying to trying to use Twitter less at the moment for reasons that are probably fairly obvious. So I am on Mastodo I can’t remember what If you search for me on Mastodon, you’ll probably find me.

I think I’m, I think I joined Fosstodon? I was just Googling and it came up in a list. I think I’m gonna shift to another one that, I think it’s called hachyderm that I see a lot of kind of peers, colleagues or, yeah, more peers are on. Anyway, so yeah, I’m on. I’m more, more trying to be more active on Mastodon than on Twitter. Or email. Email me. I dunno. We put, you put my email in show notes.

Rhyd: Yeah, I’ve got show notes I’ll add it.

Karl: Or I’m on my blog of Availagility dot co dot uk and there’s a contact form on there which will come to me.

Rhyd: Alright, thanks for your time today. That was Karl Scotland. Thanks very much mate.

Karl: Thanks.

Back to episode