 Hello everybody, this is episode 98 of the Agile Podcast and today is a landmark, not numerically, but we've got our first ever patron guest. So from our lovely patrons who support us, we've taken someone, a volunteer, and they are going to be our guest ale on this show. We've got Gareth, Gareth Thomas from Lincoln and we spent a good time talking about technical stuff which for me and Paul is a bit of a stretch as you know, but Gareth is a very technically minded organisational leader. So we talked about different levels of testing. We talked about how we might help get people to see the value in test first. We talked about leading and lagging indicators, the short term and the long term focus. We talked about how that impacts on sustainable pace. We talked about something to do with Japan and making things out of metal. Very interesting. We hope you enjoy it and if you'd like to be in with a chance of being a guest on a future episode then become a patron and every now and again you'll be invited to have a chat with us live on the podcast. Speak to you soon everybody, take care. Hello Jeff. Hello Paul. We are very lucky today. We have a guest. Guest ale in the bar. Yes. What's on special offer this week? Well I've got Ribena. Hello. Hello, I'm Gareth. Hey Gareth. Gareth is one of our patrons, our lovely patrons. So if this was a regular bar, Gareth would be basically keeping us in business. He would have his own seat at the bar. His own seat and probably his own tank at hanging from the roof. He'd come in and he wouldn't, he'd get his own glass. Absolutely. Cheers Gareth. Nice to see you. You too. Whereabouts are you? Lincoln. Lincoln. Somewhere in England. Because we have a global audience. Do you want to give our global listeners a bit of a clue as to where Lincoln is? If you look at the big map of the UK, there will be some major cities in the middle and there are some bits on the right hand edge where nobody ever goes, that's Lincoln. So sort of east coast, not particularly north. Although they think they're northern here. Yeah. I would have said power from the sea. That was going to be my next question, how close to the coast are you now? You know this, you know this but our listeners probably do it. My grandfather used to play football for Lincoln City. So I used to have a Lincoln City football scarf when I was probably about single figures years old. Probably the only person outside Lincoln. And Lincoln, they weren't particularly good but he did, he did nearly join Derby. He was, Derby tried to buy him for £5 I think. Which at the time was a lot of money as they always say. Anyway, enough of that. Are you actually drinking ribena? Actually it's hot Robinson's ribena type stuff. Type slip? Okay. It's mixed fruit berry drink. Is this to ward off the cold? It's been a long day, I didn't sleep so if I have alcohol I'll be asleep at the end of this. Well, that could still happen because if it was ribena I was going to give you another interesting fact about myself is that again when I was single figures years old, I don't know whether you know this Paul, this might be a fact that you don't know. Add it to the list, yeah go on. Do you know anything about me and ribena? No, I don't think it's ever come up in conversation. I nearly turned diabetic by drinking so much ribena. Oh I think you have told me that before. You had a mild addiction didn't you? Yeah, I used to drink it very, very concentrated as well, so it's a black current flavour drink for anybody else. You didn't used to drink it neat did you? No, but sort of 50-50 which is quite... Half a glass of ribena cordial and half a glass of water on top. I think when I was at rock bottom that's pretty much what it was. Rock bottom. I thought you were mild type. I hated you, that's expensive. It is expensive, yeah. Must have ruined your teeth as well. Yeah, not great for the teeth but I have lovely teeth. So what's the moral there? Rot them early, go back and set. Drink fruity, drink responsibly kids. So now I don't drink ribena, I drink a stout. I've gone for a stout today Paul, nice dark drink there. It's called Last Minutes and Lost Evenings. Another one from my local day at Brewery. Last Minutes and Lost Evenings. It's very dark, I don't think they need me mate, they're doing very well. I've got just plain ol' thatchers here, it's very boring, it's the only thing I've got in the fridge right now. But it's fruity. So cheers. Cheers, cheers everyone. Cheers. Yeah, this one's I would describe as sort of burnt chocolate. What a lovely description. Well I quite like that. I quite like a dark chocolate rather than a milk chocolate. To drink though. I wouldn't have wanted this earlier on in the day because it was quite warm today. But now it's sort of a nice coolish evening dusk. And it's pleasant, it's nice. A few marshmallows, some squirty cream. Maybe not, it's 8%. Woo! Straight to bed after that. Well we'll see, we'll see. So how's your day been going? You say long day, hard day? Or was it just because you didn't sleep last night? It's been first day back in the office actually. Physically back in the office? Actually in the office. Yeah, so we've been planning our year end activities. So I work in the education sector. So we got our sort of end of year presentations on Thursday. So coming together, planning out what that looks like, writing slides, working out stats to present. And how was it back in the office? Well there was only four of us in a place that was going to be 50. So it was quite socially distant. Odd, it was very echoey, very nice. Yeah, anything left in the fridge? No, we had one man work the entire lockdown there because he hasn't got any way to work at home. So he's worked his way through all the leftover stuff. Keeping the plants alive? Yeah. Or devs desks who just covered in plants now. Are there plans soonish to bring people, more people back in the office, Gareth, or not? First of August, we're thinking of starting to let people choose to come back in. But we're quite packed, so it's very difficult to get them everyone back in and have decent social distancing. So it's going to be a phase return. And I think it'll be harder than being fully remote. I think a few people and a few people not will really divide the team up. It'll really be an odd dynamic to manage. How was your meet-up, Group Paul? Oh, it was very, very meaty. A very meaty upy. That was good. I've been missed a meet-up this last two weeks. You've been getting around, haven't you? Two weeks, two meet-ups. I was at Agile Northeast this time last week and I was at Agile Bath in Bristol today. That is one of the good things. I mean, it's a benefit. I know there's lots of drawbacks to what's happened and we've talked a lot about that about those things. But people from Germany turning up to meet-up technically that's listed in Bristol. So it's fantastic, isn't it? I'm meeting people that I probably would never have met on Zoom meet-ups. Now, being able to turn on a Zoom meeting with 15 minutes to go before you start is quite nice. I'm in a very weird position for the first time in my adult life since I was 17 years old. I do not own a car. I know Gareth doesn't own a car. No. You're the only one of us that owns a car, Paul. I know. Well, I don't see myself needing to travel for work for a long time. My main clients aren't going back into that. You've got to kind of leave it. You've got no plans to replace it. Not at the moment, no. My clients aren't... They're committed to not going back into the office until the lease next year. And I'm not... I think they will eventually. But I was speaking to somebody yesterday who said, no, they've already given up the lease of their office. They've decided they're not going to go back. They're absolutely fine working remotely. Because that's surely, that's going to become an issue. Certainly central London, isn't it? With offices, spaces that companies won't be able to afford, it's not worth them paying their lease. And they'll just become empty. Well, the Shard and Canary Wharf are quite worried about it, aren't they? Are they? Yeah, because they've had a few people serve notice because they've realised they can work perfectly fine without having an office on the 12th floor of the Shard. Yeah. And you can only imagine how much that cost. I do quite a lot of work with a Greater Lincolnshire enterprise partnership, which is as exciting as it sounds. And the estate agents are seeing a massive uptick in places like Grantham and Newark, which are an hour by train from London. Yeah. Because people are now going, we don't need to live in London, we don't have to commute all every day. So we're buying houses in walking distance at Grantham Station. Hmm. Yeah, it should. Level out the UK socio-economic divide. A little bit, I think. Yeah, I think even the UK government's thinking about relocating for a while up north somewhere, isn't it? Leeds, I heard Boris Johnson was suggesting. They've said that for years, haven't they? But I think they're actually, because they have to, like the houses apart are falling down, aren't they? I mean, it's actually unsafe to use them, I think, almost. So, yeah, yeah. All right. What about the world of Agile? Has anything been happening in the world of Agile? Have you read anything interesting or listened to anything interesting? I had a question. I was going to try and read it to you now. Well, you've been asked a question. Yeah, it's a techie question. It's a techie question. In the XP, I'll just read it verbatim. In the XP world, do you find that the continuous refactoring of code breaks a lot of the automated tests and therefore there is a substantial amount of work in keeping these up-to-date? My team moans a lot about wasted effort in the rewrite of tests. They're doing it wrong. Absolutely. Okay, I'll just make a note of that. And if they're breaking tests, then that is the point of the test, the catch is the catch breakage. So if the test is breaking unexpectedly, that's indicating that they've refactoring correctly. So you don't fix the test, you fix your code to the test passes again. That's the point of the code. But I think, yeah, so seeing it as a cost, seeing as because it is a slightly more, well, is it an inefficiency in trying to actually write tests and rewrite tests? Because if we're actually rewriting tests it may well be a good thing if they're going to be improved, surely. There's, I'm thinking now, there we go. So, you're testing more of that on their job. You need more things. This is serious chat, this is serious chat. Your tests, your safety gates, they're the thing that protects you from releasing broken code. They're the thing that stops you putting it alive. I think you don't understand. So your test failing is good because it's called a bug. And if you've got a bug in live, it means your tests were bad and you should refactor your test and work out what test you actually needed to catch that bug back before you wrote it. So you should be investing time in tests. But if in the normal run of work, you're breaking tests, that implies a deeper issue in your practices because you've probably got too much coupling. You've probably got to domestic dependence between parts of the systems. You've probably changed code, you're breaking things downstream and all your tests are very dependent on data or the shape of your code. So your tests are wrong. So probably look further out, look at something in BDD, look at something a bit more abstract from the code and get into your sort of your testing onion if you're into that sort of thing. I'm trying not to get way too geeky because you know I can. But in terms of certainly, it's a continuous attention to that testing element on every day of a sprint, surely. It's not something yet we should try and, because I've made a gripe with me and I won't name names, but some of the people used to work at Nokia. They would say- Not Ian. No, Ian didn't work at Nokia, did he? He worked in team. There must have been Ian at Nokia. There was plenty of Ian's. But let's call him Craig. Okay, this one, we'll call him Craig. He used to say, I said, end of the sprint is coming up. So we've got, it's kind of, I've finished my tasks now. I'll tell you what, I'll go and write some unit tests. That, it was a, it was seen. It was seen, for the benefit of the take, Gareth just put his head in his hands. So it was seen as a frivolous kind of task that I'll fill up some time. It's like, you know, tidy up your bedroom or whatever. But instead of seeing it as a proactive, it was something I'd do just to make it look like I'm busy at the end of the sprint and take up some time. I used to really get my goat at the time. And they're probably completely worthless as well. Probably tests to have coverage. But in terms of metrics, what they would be, what was observed and what was measured was if their unit test coverage, if they had lots of unit tests, didn't matter how good they were. It was just, it looked good. It looked good on the balance sheet, right? So on the dashboard. I memorably on one day reduced test coverage on one co-base I was working on by 57% because I started making some changes. All the tests broke and then I looked at the tests and they were just there to get coverage. They could write tests in such a way that it just looks like the code's working. It doesn't actually test anything. And I thought I can either spend three weeks rewriting all the tests or I can bin them, stop lying and then actually put a meaningful test in and then write my code because I'm of the school where you write your tests first and then you prove your test. You just got your red, green refactor. It's a continuous cycle of writing code until your test passes and then once you've passed your test, you stop writing code and then your test... Do you still find that difficult to convince people about? Yes. The idea of test first. And what do you think, because you've been doing this for a while, what do you think is the sort of mental or cognitive stumbling block for people? It feels like a waste. Going back to the original question, you want to crack open your editor and start writing code. You want to start solving the problem. A lot of people think in code and going test driven, you start having to express your changes in the tests. You have to think about the shape of your code in tests and start writing tests and then you can start writing the code to prove your tests because it's almost like you have to think about the required first. You go test first, you think about requirements, not around feature. So you start thinking about what the customer actually wants and how you would prove that you're doing what the customer wants rather than how to make a thing happen on the computer. It's flipping the mindset. Yeah, so as someone who you quite openly said, you enjoy coding, you still enjoy coding. Do you see writing tests as something fundamentally different to coding? Depends on the test. Because to a non-technical person, to me... That's Jeff, by the way. Very non-technical person. To me, tests are still technical gobbledygook. And I know they can be written in plain English, I know. But to me, one of the... I've always assumed that a developer thinks of themselves as wanting to write code and tests aren't code. But the more test driven you are for someone who's non-technical, you're still writing code. You're just writing the code in a test format. Yes. Is that too naive? It depends on the layer of the test. So you have multiple different ways of looking it in. And there's a really good Scrum.org trainer up north and I can't remember his name now. And he does a fantastic talk on the layers of testing and how you build it in. I'll have to find his name. But he talks about starting on the outside and having your requirements in tests. You always document your entire system using something like Gherkin, using plain English that you have systems that can understand. So you say like writing a test in English, not behavior-driven development, but sort of feature-driven development. So it was even set further than behavior. That's old school. Yeah. And then you go in and start thinking about the behavior. So you go, I want an ATM machine. It's always the classic experiment thing. And then you go through and all the different things that it needs to do and the sequence of things in English, that enshrines your product owners or your stakeholders' actual view of how the feature should work. And then you write another layer of tests under that, which proves that. And those are your unit tests. And each of them are slower. Each of them have more independence between other systems and each of them have more complexity to them and are slightly more fragile, but they test less. And your product owners should be thinking really at the outer side. It's that MVP feature first. What problem am I trying to solve? Something that features what's the problem that we're trying to fix with this thing. And then as you move down the layers, you get more technical. And then the testing turns from being a proof of the requirement to a proof of the code. Make sense to me. That's a success then. Even for Jeff, even for Jeff, you put that into words that even he can understand. What light bulb are you going to turn on there, Paul, with your? Well, I was just going to ask, does great testing have to come from, is it a mindset? It is a different mindset. I think developers can get there. So some of the best testers I know, which is now different to unit testing. That's the different skill now is actually your integration verification testing. But the best tests some of us I know come from either a sysadmin or a development background. They know how to break the system. One of the practices that I quite like and it's very hard to get them to do is like pair programming, pair testing. So you have your tester in your team and instead of them testing the code, we're going to go, this is testing, you drag the tester over, he sits next to you and you pair on it and he breaks it in front of your eyes on your computer. Does he come with a pack of tissues too? Yeah, some Glen Fiddler in an arm around the shoulder. But it makes the developer think about testing on their machine because the sooner you break it, the sooner you can fix it and the cheaper it is. So you don't want your tester sat at the end of the conveyor belt waiting for all these things to come in and then raising tickets in the backlog and moving things left. You want it breaking before it even gets to integration. I think it is a very different mindset, isn't it? I remember using Meetup, this was a Meetup group I did donkeys years ago, but it was, I think, actually, coincidentally, the Bath and Bristol one, but they did a testing Meetup. I think it was the other one. But they just used it as basically an opportunity for testers to get together and basically try and break core functionality in some of the major websites like Amazon and places like Google and try and see if they could just test the hell out of their live systems to see if they could find floors in it and find gaps and holes in it. And some of them. Would that be a sort of badge of pride if they could? Yes. Is there, do you think there might be something in a sense of pride from a development point of view in that why do I really need to write tests? I know my code will work because I'm good. They say it's, writing tests is the distraction from writing code. And they're often judged by how many tickets they ship. And writing a test is often seen as a thing that prevents them from shipping tickets. Yeah, okay. So is that something you've had to tweak in terms of perspective outcomes, outputs type thing? You have to change the duration of which you're looking because I don't know if anyone from work will actually listen to this. But there we go. At the moment we're seeing quite a lot of defects because we're on high velocity and we're working on part of the system that has very poor test coverage. It's written in the framework, you can't test with unit tests. So we put a lot of selenium type automated testing which aren't as good. And our defect rate is so high that we are probably having a P1 every two days over the last couple of weeks, just on, oh, this is broken, this is falling over, school can't access this. And schools probably don't notice, but you see the rework and the amount of time we're losing to doing those tickets again. So it's not just how quickly I ship that ticket. So how many times does it come back? How many times are we fixing it? And if you zoom out to look at over six months, teams are good testing, ship more code. Yeah, how do we get people to stop thinking about it? Because so the short term is such a big pull, isn't it? We are short term head nests at heart human beings. You can knock your scrub now and go, that's why we plan, you're planning on two week cycles and that's got to limit your view. And now we're going all our tickets done in that sprint. So, so part of that's my definition of done. Wow, there we go, done or done done? Done, done, done. But the, it's making the wider business take a step back and looking at what's shipped over a longer period, which comes back to what I've been doing today really. What have you achieved in the last year in work? And stop looking at the next month and start thinking about what have we achieved in the last year? And I'm not plan this really short horizons and going, we need to have all these features out next week to meet this arbitrary deadline. It's a combination of leading indicators and lagging indicators, right? Is the long term thing, you're not going to see the results obviously for a while, but to know that you're going in the right direction, you have some proxy metrics, test coverage is one, things like that. But having that longer term horizon in conjunction with the short term speed and reactiveness that reactive nature that Scrum can give you is what we need. We need that kind of balance, don't we? It's how it's, you have in multiple feedback loops. It's in my previous life, I was a process control engineer and you have your slow feedback loop but your fast feedback loop and you have proxy metrics don't able to control the fast one, but you still need to measure the slow and the fast to know where you're going and if you're on the right bearing. I've got, I was going to ask one thing and it's kind of related. And it was a question that came out on this meetup route tonight. And the question was, my team is experiencing high stress situation now because of the lockdown situation because there's a tendency that we need fixing to fix things fast and how much the current lockdown COVID type environment has probably focused people on the short term of finding a fix now and trying to find resolution quickly because we don't like this whole world of uncertainty we're living in, especially if you're the product development area. The need for any sense of stability is a positive and she was really struggling with them. How do I calm, basically how do I slow and calm my team down because they're highly strung just because of the situation? Is that, have you seen that Gareth? Is that, has the environment played out on how teams are developing at the moment for you? Well, we've probably a slightly different industry to everyone else. Everyone will say that. But obviously we work with schools. We do the management systems that run the schools. So coming into the lockdown, we had a really high stress time because we became obvious that the government didn't know how many children were in school and we had to very, very rapidly release a lot of code with like a day's notice to record things for the department to allow schools to work at how many kids are in school and why they are locked down. We turned around all the government's guidance in about four days, which required quite big system changes. So we've been having these massive periods of frenetic activity in quite a lowed coal base because it was in some of the older parts of the system as well, but to make it so that schools could go back and they could recall their bubbles and they could do track and trace within schools. And that's actually brought the teams together. We've had this really productive, really bonding experience because there's high stress, but high rewards. High purpose, yeah. Yeah. I mean, at one point we were probably the canonical source of data and the number of children in UK schools because the government don't have it, we do. And we were writing BI reports to give to the department showing aggregate school numbers. And then I was seeing them reported on the BBC. This is what the numbers that the government were using. Yeah. And to create a massive sense of pride in the team that we're making a real difference. But then there's a massive deflation because then you're doing, and now we're just doing something to make money. We're just doing a product and now it doesn't feel as exciting. I think it's an interesting as to how the current environment has galvanized or in some cases stressed teams out in terms of, oh my God, we have to do this now and increase the pressure. That can be inspiring, but it can be frightening, I imagine. Well, as you know, I focus on language a lot. And you said that, oh my God, we have to do this now. And so for organizations without a, it's not necessarily an altruistic purpose. I mean, you're a company that makes money. You're a for-profit company, Gareth, right? But what you're doing is actually contributing towards the national cause. It's contributing towards something that everybody can humanize and relate to and empathize with, because they all know people who have children, they've all been to school themselves. And so they can see that they're actually solving a problem that's quite close to them as a human being. And that galvanized, that's something they want to do. Yeah, they're being paid to do it, but they also want to do it. But if there isn't that sort of connection, if there isn't that humanized factor, then it is something that they have to do and that becomes an obligation to chore and a source of stress. And that's, for me, one of the big areas that affects the big, almost invisible factors around sustainable pace. So while Gareth has described, what Gareth has described in there, the amount of energy going in from that team for something that was what the country and families and schools and society absolutely needed at that point in time would have been absolutely unsustainable for the team that's stressed because they have to do something very, very quickly. But for that team, it was actually energizing, it was bonding. And that's a massive thing for me. The interesting is the response, maybe from people outside the team. So you get a lot of praise coming in and everyone's amazed at what they're shipping. But then you get people going, why can't they do this every sprint? We're talking like one-day sprints. We literally sprint flying in the morning and then reviewing at lunchtime and then shipping in the afternoon again. Everyone's heard the story of the mother who will lift up a car because it's crushing their child. They have that temporary moment of superhuman strength. So why can't you do that every day of the week? Because that's not happening every day of the week. If it did, it would become normal. And it wouldn't be, isn't it? I don't go saying it does create an expectation while you've done it once. Surely you can, the impossible has become possible, right? Yeah. This makes me think of Japanese template works. I haven't had a single work story. And in Japan, they have pride around their production records on their lines. Okay, yeah. So Nippon Steel will see shifts come in on their own time on downshifts to set new records. So they'll come in, they'll have thought about how are they going to operate in a more precise way to do higher quality or more steel in a shift through a five-stand reduction mill. Don't worry what one of them is. And they will go in and then they will work that shift and set a new production record. And then that becomes the new metric for the line. I mean, they see the quality of the product that goes out the door. They are proud to give it to the customer. And they are proud of having an efficient shift. They're proud of shipping code in a sustainable pace. So the important thing about them coming in is they'll think about how they're going to operate. And they don't flog themselves. They'll put a new process in. They'll inspect and adapt and they will do another shift which is slightly better than the shift before. But they'll trial it and they'll do it themselves because they know that the company will be better for it. And they get a sense of pride in the company doing well. It's a completely different mindset though. So I got to know about Nippon because I worked on a joint working group with British and Chinese and Japanese cold reduction steel systems. And pride's probably the wrong word. It's ownership's probably the better way of thinking about it. So they're not competing with anybody but themselves. And they're not trying to do better than the other five-stand mill because there is usually only one in the works. And they're not competing with the upstream or downstream units because that doesn't make sense. I mean, they consume things from one unit and they give it to the next. And the quality of their work reflects down the path. So I suppose there's pride in giving good things to your colleagues, but not like we're the best but we're giving you good work. And pride or satisfaction to be able to cope with what's coming from the stream. You going at this new metric means that the line below can run faster because that's been upgraded. They can do this work. So now you're not bottlenecking them. It's your fear of constraints with your real-life gold router. So I mean, that's really interesting. I mean, I've seen a lot of that in perhaps different circumstances but that sense of beating your own personal best. I have seen a little bit of inter-company competition actually healthy. Most of the time it's unhealthy but sometimes it can be healthy competition into sort of setting the standard and then another team responding to it and pushing the bar up internally but pushing your own bar up, I see a lot of that. If you've got ownership and you've connected your values to the purpose of the work, then that ownership is quite key. I got asked the question and it was a little bit too technical so I passed but it was around whether the more remote nature has made it easier or harder for teams to keep their quality bar high when it comes to sort of TDD pairing, things like that. And I had to admit I didn't have any data to say either way. My instinct would say it would probably be harder but I imagine also for some teams it might be easier because there'll be fewer distractions. Yes. Have you, just like that, is it? It depends on the person of the team. So we've seen, it's odd because you don't want to put the plans in place and we make this the BAU. Yeah. But some people have collaborated more, they've made more of an effort to always be on a meeting or be invested a lot in remote pairing software before the lockdown and the team were quite used to doing that and everything's got pipelines and everything is centrally stored and so you can ship your code, you can see pipeline builds very, very easily. But other members of the team have just vanished in on themselves and we're making an effort to make sure who's in stand-ups and who's talking and who's being active. I've seen, so I had a chat with a good scrum master friend of mine who's, their team's adapted really well to the whole lockdown thing and they use Google Hangouts and their Google Hangout is open all, literally all day. We know we can see each other all day, two screens. So one with the screen that I'm working on but on the other one is the Google Hangout that's kind of opening, open all day and we just kind of, we will just every now and again tap each other on the shoulder virtually or turn on microphone knowledge and shout something that we need some help with something. Similar with you Garth, is it more ad hoc when you need it, you turn the cameras on? We tried the all day and no one joined it because we find people jumping into different meat to do their bearing and they're not going back in. So it sort of fell by the wayside. What we introduced was a lunchtime catch-up which was optional. I'm more of a sort of a water cooler moment to come around and talk all day. But we've always been big users of Slack and everyone is very focal in Slack all the time and they have been even in the office and I think that's helped because our sort of collaborative work happens in Slack. Even in the office, we'd all be sat there with our headphones on talking to the person next to you on Slack. So it sort of just continues in the same way. I hate to bring our chat to a close, but I'm out. I think we're done. Yeah. That is our leading indicator of whether we're done or not. Is I have an empty pint glass. It's been an absolute pleasure having you on. Yeah, it's nice to have a guest. Our listeners will be thrilled to hear someone other than just me and Paul for once. So yeah, it was brilliant. Thanks for making time and thanks for being a patron obviously. Cheers. Cheers to you, sir. Cheers. Ding, ding, ding. Until next week.