 Thank you so much Tracy for the great introduction, so hello, I'm Bethan, I'm the marketing director at NetCells which is a product and software development agency in the UK, hence my accent which I'm suddenly very aware of being here in the States and people keep on telling me I sound really posh and I'm like, oh no I just sound normal! Ond yma ydych chi am ddechrau gweithio cwmpol wedi cyfloedd yn ddysgu y gwybod hwnnw. Ond mae gennych i ddweud â 5 feddwl ar y cyfleoedd yn ystod. Ynny'n ei hoffi a bryddu i'r bwysig o bwysig yma sy'n meddwl. Afally yn roeddaeth allwch fod yn ffriction ar y cyfleoedd ymddiolill yn ychydig o fforddi'r arferfwydon. Rwy'n dod pwyllwch ar gwellio gan gyddiad yn y gyddoch chi'n fathbwysig ac yn gweithio'r geflau yng nghymru yn y cwmwys ar y pethau, ac mae hynny'n dweud y proses yma yw'r ysgrifennid yw'r cyfnod y mae'r unrhyw o'r tyfnod yw'r ysgrifennid yn gyhoedd yn gyffredinol gwybod gyda'r cymryd, rydych chi'n gweithio gan gyfnod yw'r ysgrifennid yn y cyfnod a'i gilydd yn gwybod yw'r cyfnod yn gweithio ar y cyfnod yw'r cyfnod ar y cyfnod. math ydyf yn gwneud eich cynod hollol a'r cyffredinol. Fe ydych chi'n gwneud yn cyffredinol gyda'r cyfrannu sain, oherwydd mae'n storio'r cyfrannu a'r ymddech chi'n ddiolod maen nhw'n ei ddwylliant gan agor Rydym yn gwneud ddefnyddio hyn a ddim yn cael ei ddweud. A bod gwnaeth aethau'r gwahanol heddiw o'r hwn, yna eu ddechrau'r meddyliad mewn Merthyrăn unknownid a'rhef mwy fydd yn ddefnyddio ar gyfer yllai hwyl i'r CHEF. Felly mae'n oed o'r Abbey, oes 20 min o'r ddaeth yn yng ngyfnod yng Nghymru. Felly mae'n meddwl Abbey, wnaeth wneud i'w gwybod i yng Nghymru. Felly mae gennynnau roedd oedod, maen nhw'n mynd i'n wneud ei gweithio i'r rhanau am gyffredinol sy'n dweud. Felly, rwyf wedi gweld i gydweithio i'r llwyddo fydd ymddangos i'r Ywlch. Roedd yna'r Ysgol, rwyf wedi gweithio i yw'r bydd yw'r Ywlch. Roeddwn ni wedi'i gwirio, ond ti'n gwirio'r Gwyrddion yr Unedig, ond ti'n gwirio'r Gwyrddion yn ystod yng nghydfyrdd, ond o'r cymdeithasol yn ymddangos yng Nghymru, ond y ry'n gweithio'r Chambald penderfynol yn y samech mewn ffawr. Yn ystod, mae'n gweithio'r Harry Potter a Diagonale, a fyddwn ni'n dweud i gael y cyfaniau dda'r siwr. Mae'r gweithio ar y cwm yn y Ynys Gwyrddion Cymdeithasol yn y Deosember. we build software and digital products, platforms for a number of clients working with large corporate entities like Hiscox PLC, which is very large British insurance firm. Down to working with lots of startups who are getting off the ground and trying to build their products. We've seen from both sides that working with organisations where they don't have very collaborative teams, so the teams aren't contributing to each ac mae'r projektyn y pethau ym ni fod yn ymwybod am ymweld gan ymwybod a'r bobl ahol. Mae'n gyfnod o'r ffacol o'r fawr. Rwy'n meddwl i'r ffacol ar y gweithio ar gyfer arni yn y tuthgof. A'i gydig i'r bwysig i ddim yn rhoi arwain. Mae'r gweithio ar y discipline, byddai yn gweithio ffasol i meddwl a cyfle, Not just for consumers, but for practitioners as well, like myself. And there are a number of issues that come with this complexity, which is being driven mostly by technology, and the fact that we've kind of got new platforms, new systems, we've got to be on Instagram, Facebook, all of these things. But it's also being driven by the fact that we're often working in tech companies helping contribute to building products. So my four big marketing challenges when I was working in my previous role and actually these are still challenges today are firstly, organising information. Now, marketing, you end up with lots of disparate pieces of information that can either be kind of held locally on people's machines or out on cloud-based systems or even on pieces of paper in the office. And sometimes it can be very hard to find out what's going on. Secondly, I think marketing as a discipline, again, is transitioning from waterfall to scrum-based methodologies and this is being driven partly by the fact that development's moving that way, but also we're just having to ship faster. I think it's not just a competitive advantage, this kind of continuous delivery that was talked about earlier in the keynote. It's not just a competitive advantage to development teams to be able to go fast. It's also really important that other teams are able to create and ship really quickly. Also, integrating with other teams, again, I've talked a bit about being in those silos and kind of how that can be really problematic and it just leads to work not being as good as it could be. And then I think really the most important thing you can often lose sight of and I've seen this in companies I've worked in, companies I've worked with, people lose sight on what really, really counts and that is, again, customer. We want to build amazing products that customers love to use and if we're not hyper-focused on that and we're focusing on other things and building for the sake of building, we end up, well, we end up losing revenue and revenue is what kind of pays our wages and keeps our companies afloat. So that should really be our ultimate goal, right? Cleasing the customer, delivering things for the customer. So, step one in my journey, I had to unite a divided kingdom. Now, I'm not going to be unapologetic about the medieval metaphors in this. So, kind of the UK, before it was the United Kingdom, it was this kind of mismash of loads of different kingdoms, loads of different kind of tribes, princestums with over 37 different dialects and everyone really had to one, it kind of got to the point where everyone had to work out how to get along because, you know, we were being invaded by the Angles and Ormans, the Vikings, so we had to unite to be able to defend ourselves pretty much and I'm not saying that teams have to unite to defend themselves from any fo, but I think it's really important to be working together and this was our first step, bringing the whole marketing team together. So, marketing is quite an interesting discipline because it's not just marketing and this kind of mirrors what's happening in development where, you know, development isn't just development. You specialize in a number of different languages, frameworks. It's kind of the same in marketing, so on the left-hand side, you've got a list of all the kind of possible, well, it's not all the possible, but most of the possible different kind of sub-disciplines of marketing. A lot of marketeers are either generalists, so they have a broad overview of these. I'm one of those types of marketeers with maybe a deep specialism in one vertical. That's what we call the T-shaped marketeer and you end up with people on your team who are experts in one vertical. So, you end up with this mismash of people working on different stuff. On the other side, I've shown a kind of an example team structure of the type of team I was working in where we had some front-end dev resource, we had UX UI, and we had loads of people with different disciplines. Our real problem, like I said, was everyone was working on different platforms doing different stuff and it was really hard to get a singular overview of what people were doing and to collaborate on our work together. So, it was at this point, I kind of noticed my development team were using this platform called GitLab. It looks pretty cool. I was kind of watching over their shoulder thinking that looks really interesting and they were talking about how they managed their full workflow on GitLab and I thought, wow, this might be the solution to my problem, leading this team of very kind of disparate people who are working on their own things. And a lot of my team had never really heard of Git before. They had no concept of version controller or anything like that. So, we wanted to give them a soft introduction to the world of GitLab. So, actually, what we started off doing was we just started documenting our work in issues. It sounds really simple, it was really simple. We just ended up with some kind of basic templates, made sure everyone was on the right track and we got this kind of full overview of what everyone was working on. After this, we kind of added a little bit more complexity. So, once you've kind of got everyone's documenting their work on the same place, we started to split out in using kind of board functionality. So, this is unashamedly stolen from GitLab's marketing team because they've got so many amazing kind of open source. You can see what they're working on, which I think is really great. And you can see here they've started kind of organising by, actually, they've got product marketing, issue boards, and you can see a full overview of what that particular part of marketing is doing, but everyone within marketing can view it and see what's happening and starting to use the labelling functionality, which was really key in organising this information and giving yourselves a bit of structure. So, really step on is about getting everyone on the platform. And I've put adult users technical and non-technical. I really hate that terminology, but what that essentially means is, if you think someone shouldn't be using GitLab because they won't understand it, that's absolutely not true. It's quite easy to get into. You just might have to give people a little bit of tuition and hand-holding, but that shouldn't be a problem. I think with issues, what we decided was that every issue should contain all the links to all the assets required. Now, we did start using kind of repository functionality to put our copy in there, and I'll talk about that in a minute, but often in marketing, you'll need kind of graphic assets or video assets, and they might not necessarily be able to live on the GitLab platform, but we enforced the fact that every issue should at least link out to where that information was held. So, it became the canonical source for all the information we needed. We standardised with issue templates, that just makes sense, everyone's on the same page, and then we used boards to organise by team and function. So, step two, so you've got everyone on the same page, step two. So, I really tried to find a metaphor for agile and scrum in the medieval period, and I genuinely went to the library. I was like, that's got to be something, they just didn't do it apparently, who knew. But we're at the point, so all of our teams on the same page, we want to start changing the way we're working, the actual fundamental process behind the work we deliver. So, in marketing we have this concept of waterfall marketing, it's very much as you would expect. Requirements are preloaded, you do a lot of long-term planning, so at the beginning of the year, you might have your sales targets or whatever, and you'll do this kind of big plan of how we're going to support sales to meet those targets, and you spend most of the year in execution. So, you might say, we're going to have this quarterly content cycle, we're going to have this six-month campaign, and you do all of that in your execution phase, and then at the end of the year you do your results, you do your reporting, and at that point you're like, it worked or okay, maybe that idea didn't work. And this was a big problem because we weren't getting that immediate feedback on our ideas. And at this time in my organisation, our development team were moving over from waterfall to scrum. And it went from, they were shipping new features every six months, it's quite slow, they went to shipping every six weeks, and that was transformational. And suddenly I didn't have that six-month lead time to work with them on promoting these new features, building a marketing plan around it. I had to be there and ready to react every six weeks. So, we started running our team using scrum and a agile marketing process. So, to do this, as I said, we've started documenting everything into issues. We introduced the concept of a marketing backlog. So, we used kind of all the features labelling, we used weightings, we kind of treated it like, as you would in scrum, your kind of product backlog. And we made sure that everyone could contribute to that backlog and that everyone could see it. And we did our sprint planning meeting where we selected the issues that would go into the sprint. Everyone knows vaguely how that scrum process works. So, we got to the point where we were running sprints. Sprint kickoff, we're into the sprint. We need to be able to track kind of what's happening within the sprint. So, we actually, when we kind of had the issues, we were getting people to estimate, which if you're a brand-side marketeer, so you're a client-side, you're not necessarily working for an agency, the concept of tracking your time, you may not have come across before. So, this was a real culture shift for our team to kind of ask them to track time. And there was a bit of push back there because they were like, what are you trying to check up on us? And how do we, we can't estimate the creative process was feedback I got. And I was like, well, developers managed to do it. Isn't development creative? So, we got to this point where we were running the sprint. What was really fun was because development team were using GitLab, we were using GitLab. We could compare burn-down charts and have a burn-down chart velocity competition. That's pretty sad, isn't it? Hey, we gotta kick somehow. So, we were using this functionality as if we were a development team. Just our work was different. And it was at this point we started introducing the idea of copy as code. And what this meant was as the sprint was progressing and people were doing the work, they would be committing it into the repository. So, a lot of our work was around writing copy content. So, be committing that into the repository, using branches, using merge requests. And that gave us this kind of idea of checking the work as it kind of goes, gets completed so we could have editorial checks. If you've ever had to write a lot, you'll know the importance of having every tutorial checks and a bit of a balancing check and balance process in there. So, really, GitLab enabled us to run a scrum marketing team. We couldn't have done it without it. So, we used milestones to plan our sprints, as you would in a development team, made a lot of sense. And we really kind of enforced this idea that issues should have a really clear deliverable so they should have very clear acceptance criteria. And they wouldn't be selected for the sprint unless they had clear AC which, obviously, we could enforce using issue templates. We use epics in a slightly different way than maybe a development or a product team would. So, epics for us represented large campaigns, not features or anything like that. And that worked really, really nicely. We treated copy as code. That was really great because we started teaching people about concepts of Git as well. Mostly, we were doing this through the web interface, but we did start using terminal and stuff, which was interesting and I broke a load of stuff, but learnt from that mistake. And we also decided at this point that if you... Because, again, we want to stop this kind of information being everywhere and anywhere on Slack, on Jira, on Confluence. We wanted it all in one place. We said key discussion needs to take place in the issues. And what this meant, quite interestingly, was often we would kind of have maybe a bit more of a development question. And what we could do is we could add whatever developer we wanted to ask the question within the issue. They could respond within the issue and it was all kept the right place. Everything in its place is the saying, I think. So, got to the point. Teams using GitHub were running scrum processes. Now, we need to lay siege to team fortresses. So, another interesting fact about me is that my first ever job was working at a castle, a 1,000-year-old castle in Kenneweth in Warwickshire, which is in the middle of England, which is the town I'm actually originally from. And Kenneweth's interesting as a castle because it's the site of the longest siege in British military history. Six months, they held out there in the Second Barrens War in 1264. And hopefully, the process of laying siege to your team fortresses won't take six months. But we do need to start kind of overcoming the barriers of departments of teams. So, I think when we talk about DevOps, in my mind, that terms are very, very concentrated into kind of ops development teams or infrastructure teams. But actually, DevOps is about enabling us to build tech, to build great products. And we can't do that without including every single department. Every single department contributes to that. Otherwise, they wouldn't be part of the business. And I think it's really interesting that often in processes, we kind of leave out people like HR, like marketing, like customer experience from actually being able to integrate themselves into the development process because it's seen as a bit of a hassle to have those kinds of opinions. And a lot of the time, I've had pushback from developers being like, marketing has no place in development. Like, why are you trying to interfere? You're just gonna annoy us and break stuff. But we're just trying to help, right? We just want the same things as you. So, we actually did something quite controversial at this stage, and we asked our developers if we could start committing some code into their repo, which was met with the reaction you can probably imagine. They were like, why do you want to do that? That makes no sense. Well, let's see the thing is, like I said, my team had a bit of kind of front-end responsibility. We had some development resource and often we needed to change very small things. So you can see here it's just a label change. And marketing often wants to make these small front-end changes and I want to change copy on the front-end of a site, tracking templates, buttons, CSS class ideas, all that kind of stuff. And my process before was I'd have to go to a developer and be like, hey, can you do this really small thing for us? And they'd be like, wow, we've got to put it into our back lock and we won't probably do work on it for six weeks. And none of the developers are going to select that issue because it's boring. And that's kind of fair enough. Yeah, it's really boring, but it's really important that this stuff gets worked on. So we kind of said like, look, we know you don't want to work on this kind of stuff. That's absolutely fine, but we need it done. Can you let us commit to the code into production or into staging, really? And they were like, yeah, okay, we'll give it a try. And the fact was they had confidence in us because we were already using GitLab, we understood version control, we were using merge requests, we could evidence that to them. And also we kind of said like, look, you've got checks and balances on this. We're not going to be committing straight into production here. We commit on to staging. You can approve that, package it up and then release into production. You're still in control. So development was still in control of the process, which was great, but we could contribute in a way that was meaningful. Another point here is that marketing as a discipline in force is starting to have its own code. And this is a really, it's a really simple piece of tracking template for my own personal site. It's just hot job tracking code. And there are lots of these little snippets that end up being placed on sites because it allows us to do all the kind of tracking and stuff like that. And in Europe, obviously we have things like GDPR and now you've got the California Privacy Act here. There's a lot more kind of scrutiny on doing stuff like this. And what used to happen was I would have all my little tracking templates, little snippets, they'd live locally on my computer in my notes. And if anyone wanted to review what was on the site, they'd obviously have to go into the site and have a look. But if anyone wanted to use my tracking templates, I'd just copy and paste them into Slack, which didn't work so well. It was a bit annoying. And if they made a little change, that change never got reflected back in my original, so we lost any concept of having canonical source for these snippets. So we just started putting them in the repository and it made a lot of sense because if anyone asked to see them, if we had any regulatory issues, we all knew where they were in one place. Everyone had to have a single source for them as well. And it just made a lot of sense. And this is kind of where I think marketing is moving towards, is owning its own code and owning its own stack and market stack as well. So you can, I hope I've convinced you, you can have marketing safely as part of the development cycle. And I think an interesting twist on this. So I've said we were asking to commit to kind of developers repositories. We also asked if we could be part of their merge request just so we could approve, well, not necessarily approve changes but know what changes were happening in the code. This was especially important in the front end because a lot of front end changes can affect things like SEO, so search engine optimisation and conversion rate optimisation and that marketing is very invested in those things. And I've had instances in my career where a developer's made a change to the site and it's literally destroyed our Google rankings and lost us millions of pounds of revenue, which, if marketing had been part of the conversation and actually been there at the point before stuff was committed, we could kind of said like, I think this is going to potentially cause an issue, this is why, and it's just, it makes a lot of sense to have again a check and balance on things. So you've got to the point. You know, we've got these integrated teams, we're able to commit into each other's repositories, we're collaborating, we're talking to each other. And for anyone who hasn't done Medieval Latin, I did Medieval Latin at university, the most useless course I've ever taken. This is the first time I'm using it in about 10 years. So this is for the people and the glory, but mostly for the people, I think, because like I've said, it's all about the customer. That's what we should be focusing on. And like I've kind of laid out this idea of teams collaborating and working together, but how does the customer fit into that mix? I think there's a really interesting way we can do this. So this next section is a bit more theoretical. It's not necessarily work I've done, but it's where I'd like to move to with GitLab. So obviously in GitLab we have service desk and service desk is really amazing because obviously customers can use it to input back in, send an email to an email address and we can collect those responses. Here I've created a kind of a customer support backlog, essentially, and you can see that we've got service desk integrated into that. I've had to make my own kind of examples here, so I am my own customer in this, which was very confusing. You can see you've got direct injections from service desk, so you've got the voice of the customer in there, but I'd also like to open this up to other teams and I think you can use GitLab as again a canonical source to get feedback from other teams and from the customer. So what you essentially could do is you can set up kind of issue templates where any team member can have access to GitLab. They can submit an issue because, for example, your customer experience team are on the call face with customers every day and they probably hear interesting things about, like, wouldn't it be great if this did this or, like, this isn't working very well for me or we have this use case and that information doesn't necessarily get translated back into the development product process. So if you allow all your kind of team members to have input on here and then it goes into a centralized backlog, it means you're collecting everything in one place. But what to do with it when it's in one place? There's no point collecting customer feedback and team feedback if you're not going to do anything with this. And again, I think this is why we can be really clever with GitLab. So this is where I'd love to get to and there are some hurdles in getting here, but I think this is the ultimate goal. So you can see you would have your backlog of all your kind of customer feedback. You would then have that kind of weighted, prioritized and assigned to teams and teams can obviously kind of debate and discuss who owns what. There will be a little bit of discussion around that, I am sure. I would then love to get to the point where you can see when a piece of customer feedback directly translates to the backlog and you can see exactly how it's been prioritized, who's going to be working on it, all of that kind of stuff. And then even better, you can get to the point where you can have all of the feedback. You can see when it goes actually into a sprint. So when it's being worked on, who it's going to be worked on by. And also this allows for teams to have a bit of discussion of separating out the feedback because some of it might be owned by product or owned by marketing or owned by dev. And then you can then finally see when the issue's actually finally been worked on. Wouldn't that be amazing? That is a direct throughline from customer feedback into development and anyone from the organisation should be able to see this and it should be visible. And to be honest, I think if an organisation is or a certain team is a bit apprehensive about putting this in place, it means they're not aligned around the customer. If that makes sense, if they don't want to have this level of visibility of feedback to development, that probably means they're working on stuff that isn't as important to the customer. That's just my view anyway. So to be truly customer centric, we need to A, be able to collate feedback from everyone, from customers, from our team members. And we then need clear ways of categorising and prioritising that feedback. And the feedback really must integrate with delivery. And I think that's the key linkage that I often see as missing. But when you bring those things together, it can be extremely powerful. And I think service desk, and I don't know whether this is a standard use case for service desk. This is kind of something I've just played around with and I think is really, really cool. And it'd be great to kind of get GitLab's feedback on this. But I think service desk is a really clever thing that you can integrate the voice of the customer directly into delivery. So this talk really has been about how I defeated the great silo or my team silo being on their own, working in a very waterfall process that was very disjointed from the rest of the team. We then bought ourselves kind of in more aligned with our development team. And actually, interestingly, it got to the point where, because we were both development and marketing, we're working in very kind of standardised ways, we could swap issues in and out of the backlog, which was quite fun. And they tried to put a lot of stuff into our backlog and we were like, no, no, we're sure this is a development issue. Please take it back. But that was how interconnected we could be. I think you've got to empower teams to manage their own backlogs. And that was a real kind of key turning point for us, where we realised, OK, we've got to be in control of this and be able to kind of understand who's working on what and when. We then obviously used kind of sprint-based methodology, scrum methodology, and we packaged up work into sprints using milestones. And because everyone had access to GitLab on the team, we could kind of see how our sprints were running. And I think we also took this view that we wanted to open up our backlog and our repositories to other teams. And we kind of expected the same in return as well. And then finally, I think you've got to capture and centralise customer feedback. And without that, I don't understand what you're building if you're not getting the voice of the customer in there. So thank you so much for coming to my talk. If you want to find out more about the work we're doing at NetCells, please head to our site. We work with some really interesting startups that are well worth checking out. And actually, we write a lot about the kind of British tech scene, which obviously isn't as kind of massive as San Francisco or America, but there's a lot of really cool stuff happening in London, in York, in Manchester, in Leeds. And there's really cool companies to be aware of and some quite innovative stuff. If you want to find out more about me, I'm mostly on Twitter. I've kind of got my own blog and stuff, and I write about kind of agile marketing and building diverse teams as well. So I would love to connect with you. And if you have any questions, I'm obviously going to be at the speakers drinks later because, you know, British person... I'll have a couple moments. Would you have a couple moments? Yeah, yeah, yeah, actually, that would be great if anyone has any questions now. Oh, I'm going to have to... Sorry, bear with me. Yeah. So for like a copywriter workflow, does a copywriter primarily compose on the GitLab web UI? Yes, yeah, that's how we did it, yeah. But do they go from another word processor and like copy and paste or...? Yeah, I mean, I can only speak for myself because I imagine kind of my team were doing their own thing, but we were all kind of feeding into the same final process. But what I would do is I'd use like AI writer or some kind of really like clean, nice text editor, get everything set in there and then import that obviously into the web interface for GitLab, but really the power was that people could kind of change each other's copy and kind of do those little kind of changes and then merge them back in. And it was that approval process that was really powerful. There you go, thanks. Thank you. One last question. Okay, maybe two, just quick. So I had a question about the onboarding process because obviously going from like the waterfall to like marketing people doing commits and merges, that's probably not as smooth as this presentation, probably made it out to seem. Oh, you caught me out there. Yeah, so how long did it take for everyone to get on board and like what was the process like to kind of switch? Yeah, well we did the whole kind of storming, norming and performing thing, so it probably did take a couple of months. It was quite interesting for me, so the makeup of my team was that I had some very junior people and then some kind of quite more, they had a lot more experience and actually the juniors kind of picked it up a lot quicker because they'd never known anything else. You know, they were directly kind of graduates into, and that worked really well. And we had a big session where we kind of sat down with our development team and they walked us through version control and get essentially and that was a great place to start. But you've got to give your teams time to change and like you've really pointed out there, this wasn't like suddenly like, oh, we've done it and everyone's working like this. It was that slow change and I think I really had to kind of step up as a manager and be on hand to help people out, even with like really small issues of what do I press here and like how does this work and then just make sure I was available for that. Thanks for your talk. I mentioned, I noticed when you showed your burn down chart, you mentioned about tracking it in time and a lot of other agile teams they tracked by story points. Just wondering what was this thinking on that. So I think for us, because I'd already imposed on the team a lot of change to then say like, oh, you need to understand this thing called story points, which doesn't really translate. They didn't get how it translated into their work and time for us just made a lot more sense. I think over time we would have, so I left the company before I could fully complete this process but over time we would have moved to story points or t-shirt sizes or something that was kind of a bit more abstract but to get people started because everyone understands time, right? That was just kind of smooth entry way into that. Thanks.