 Felly, hi, aethau, wrth gwrs, wedi bod wedi bod yn gwneud y golygu. Yr hyn yn ddysgu'r gwaith ymlaen, ond byddwn ni'n go, mae'n gwneud Jason Norton ar Unedigol Cllwladau. Rwy'n golygu'r ymddi, ymddi'r ymddi'r ymddi, ymddi'r ymddi'r ymddi'r ymddi'r ymddi'r ymddi, i wneud ddangos gyngor ar ymddi anodd a bod jagi anodd. sensor iddyn nhw ydy i ddim yn yw amswnod agil. Rwy'n i amser gwneud gan y dyfodol a'r ddweud, i press i swyddwg, sut agil a'r cyfan blaenydd wedi bod ni'n gweithio'r mewn gwirionedd, a dyna eraill yn ei ddweud seithi, felly cael eu gwirionedd ar ymddi a'r ymddi yw Llyfr Wyrdd, But this year, at the end of July, we felt as a team, as an institution, that this was our best upgrade ever. And we pretty much owe that to the introduction of agile practice at UCL. So a quick overview of what I'm going to run through, I'm going to talk about what agile is and what it means to us at UCL. Sort of what we did and how we introduced that practice at UCL. A few issue benefits and challenges, a couple outcomes, and then this is just to show you where we went with our sites. Hopefully wrapping up with a quick question at the end. So get excited! What does agile mean? Can I just see a show of hands? Does it institutionally wise not vendors or partners, but what institutions here actually use agile methodology in their teaching and learning teams? Very small amount. In the U.K. it's the same thing. U.C.A is one of the first sort of path finders in actually transforming their information mewn cygownaeth diolch ar gyfer ac maerbych, yn ymdwybod i'r tyfu. Felly rydych chi'n ei gweinio i'r Unedol CIO arian ni gofod a'r commander ddin, byddai'n meddwl ychydig ar gyfer cy destac y bwysigiaeth plaith saffol. Mae'n meddwl gyfan ei bod yn cystalio'r proses y newydd yma, ac mae'n meddwl ir iawn. Mae'n meddwl i'n meddwl yma'r proses y dyfodol, ond mae'n dweud yn gwyfoddiadol o'r unrhyw o'r ogylcheddau, a mae'r modd gynnwys gweithio yng Nghymru. Yn ymddiwch yn cael fynd i ddau'r ysgol yma yw ymddai'r cyd-dyn nhw ymddai'r ysgol yma, ymddiwch ar y peth o'r ysgol o'r ffasag yw ddechrau ond ar y ddau'r ymddai'r cyd-dyn nhw ymddai'r ymddai'r ymddai'r ymddai'r ymddai'r ymddai'r ymddai. Felly, we have teams that follow a cycle of planning, executing those plans, evaluating the outcomes and then re-planning and carrying on. I've put sort of four items to draw out. One is Agile emphasises flexibility, customer collaboration and continuous improvement. It promotes adaptive planning, short development cycles and regular customer feedback feeding into those development cycles. The flexibility, which is a core nature of Agile being the name, makes it really suitable for learning technologies where we are constantly faced with a constant set of requirements, constant changes due to our academics requirements, due to teaching services requirements, due to administration changes. When you're working on a very large organisation like UCL, there is always change happening and previous methodologies would be very slow. Those long-term projects, you go, in two years we will be upgrading. Now we go, oh, maybe a couple of weeks we can upgrade. So, Agile as a whole is dictated by something called the Agile manifesto. I'm not going to go into the details of that, but I will go into, there are four key values in Agile. I want to sort of give an ed tech spin on each of them. So first of all, individuals and interactions over processes and tools, what that means for us. So this is sort of a team statement. We value the expertise and collaboration of our team members over rigid process and tools. We prioritise open communication on the team, active listening and effective teamwork to create an innovative learning approach. And what this means is that we are constantly talking to each other, we are constantly engaging each other, we are challenging each other, we are questioning what we did and we are in charge of what we do. Customer collaboration of a contract negotiation. We believe in actively talking to our end users. So many projects at my institution previously failed because they would just talk to those end users at the very beginning, get this massive grand plan and say, yeah, we're going to roll out that system for you. And then when you get to the role out of that system, it's absolutely nothing like what was originally specified. There's been scope creep and the users go, well, this isn't exactly what I want anymore. A third, responding to change over following a plan. So we embrace change as an opportunity to improve and enhance our learning technology solutions. The team remains flexible and responsive to evolving education requirements and adjust the plans accordingly. What this means in day-to-day terms is that when things change, the team can literally spin on a 5p, spin on a penny. If you know the term, we can very quickly adapt our styles, our teams, we can restructure very quickly, we can allocate resources without having to do long term planning. And fourthly, we've got this working software over comprehensive documentation. Now I'll change this slightly to working educational solutions over comprehensive documentation. So this means that we prioritise the development and delivery of the solution over doing documentation. Too often in previous project methodologies, we would walk over these massive manuals. We've had to spend so much time on creating documentation and all of that would be done up front. And by the time it gets to the end, most of it was already useless. So we have to prioritise on all those interactions now with those end users to create and deliver value rather than worrying too much about that massive documentation. We have a bit of a, it's good enough. So at UCL, as I said, we had this restructure about two years ago. So we are, across our information services group, we are broken up into portfolios. And I am part of the education portfolio. And my project, my product team is digital to learning environments. And within the basically the biggest piece of that digital learning environments is Moodle. As you see, we have assessment and feedback, curriculum management, meeting environments, and each of these are separate product teams. The product team varies in size. So my product team is about 10 members. But we do flex, as I'll show you in the next diagram. So this is the structure of my product team. We have a permanent team, which is our site reliability and ops team, so operations. They deal with the sort of the day-to-day mechanics of making sure our environments work. They deal with the issues, the problems, the standard upgrade cycles. And we have the transient teams. And this is where agile becomes really important. Because our transient teams exist to fulfill a purpose, or exist to fill a feature requirement as we talk about at UCL. So we have features, and these features could be UI and UX. So one of the things that we did as part of our upgrade was we actually went with a whole new theme. So we went, right, we don't have the specialisation here. We'll spin up a new team to deliver that aspect. The people involved in the upgrade were actually the SRE team, the training communications team, and the UIX team. The course lifecycle team is currently another feature team in my product that is running on integration. So I'm not going to talk about them because we're focusing on the upgrade. Now, as I said, we've only got about 10 people running across these teams. And some of these teams are only two or three people. But we also have this flexible cross-skill team members. So it's one thing agile promotes is that people cross-skill within the team. So our learning technologists aren't traditional learning technologists. I don't know if you see it. Elliot is currently doing a data apprenticeship. He's a senior learning technologist. He's working on a team doing a data apprenticeship. We're looking at analytics and components and getting more involved technically in what is probably a reasonably technical team. But we bring aspects of learning technologists, that engagement with our academics and with our administrators into teams. So we get those feedback cycles and having those cross-skill team members working across a sort of what might be considered a standard technical product. Brings a really live discussion and enables ideas. At the bottom, I've got a couple of vendors mentioned. This is specifically around our upgrade. And the reason I put them here is that what we've done with agile is that we've extended the boundaries of our agile team, our agile product team to include our vendors. So during our upgrade process, we've had developers from our vendors embedded into our product teams. So they would come to our meetings and our stand-ups and our discussions and they would be there as a member of the team. And that elisted much faster communication. We were able to spin things around a lot quicker. And the other way around, we're working with Titus on our new theme for Moodle, our UI UX team. We're able to interact directly with our end-user, do lots of user cycles. They're going to be talking about this at four o'clock, by the way. But then it would be a spinner and engage with Titus who are also running as you will find that most vendors and developers are actually running agile teams already. So having one agile team interfacing with another agile team works really well because the cycle, the cadence of that delivery becomes intertwined with each other and they feed off each other. And again, enabling us to move faster and develop new components and also adapt to changes that we get from our end-users much more quickly. So what is agile about in actual day-to-day operations and how we do it? So this is key. So we have something called agile ceremonies, which basically are meetings. Let's call them like they are meetings. And when we started agile two years ago, one of the biggest complaints from our team was, God, we have so many meetings. These meetings are going to get in the way of what we do. Two years down the line, we now realise how essential these ceremonies and meetings are. So the way it works at UCL, our entire information services group, all the portfolios meet every 12 weeks for a massive planning session. All work stops and we all come together and work in our product teams on what we're going to be doing for the next 12 weeks. At that point, myself as product manager, I'll be saying, like, this is what I want to happen. And the team will go, OK, how do you want it to happen? I'll say like this and they go, OK, we're going to go and work out how we're going to do that. And they will write user stories, feature stories about delivering the things that I want. But at the same time, they're in the same room building with all the other people that they may need to interact with to look at dependencies. And those teams are looking at cross dependencies. And it brings together a much, an amazing atmosphere of cooperation amongst a whole of information services. So you've got your database teams, you've got your networking teams, everyone's talking to each other, security's there, overseeing things. And you have this massive collaboration. And it really has enabled UCL to speed up its development cycles, its process cycles, and its interactions within the organisation. Once that is over, we come away with basically a 12-week plan of what we're going to be doing. We then drop into a two-weekly sprint cycle. So the following Monday we start the sprint and it runs for two weeks. We have a two-week cadence and that's what our work will be defined by. At the start of that two weeks, we have a sprint planning session at the last of two hours where the team decides what they are working on and what they will deliver within that week. Sorry, within those two weeks. I don't decide it, I listen in, they ask me questions. They go, what do you want us to get done this for? Which is your priority? And I tell them and they sort it out. They build their work structures. They make their decisions, which is incredibly empowering for the team. We then move into daily stand-ups. Every day, the feature teams have a 15-minute stand-up where they're just checking with each other. Cos obviously, since COVID, most of us are remote now. So we have team meetings. We come together and go, all right, this is what I'm doing today. And I've got a problem here. I've got a little bit of a blocker. Can someone help me with this? Or everything's fine. Sometimes those meetings last for the four-fifteen minutes. Sometimes it's like three, four minutes and everyone's, yeah, I'm great. We'll just carry on. And everybody's underpinned by JIRA, which is our JIRA technology, where all our stories, our features and everything is logged and people maintain of where they are in sequence. So we always pull up the JIRA board and see where we are, what's being completed, what's not being done and have a quick discussion. And then at the end of that two-week cycle, the whole product, all the feature teams come together and perform a retrospective. They go, how did we do? What could be better in the way we interacted? And they reflect, just like learners reflect on what they were doing. And now that comes so many benefits. And that's one of the areas that we did not get when we started. We couldn't understand why we needed this retrospective. And it wasn't until we started, we got some coaching on this that it really became so powerful an item. And then at the end of the week, we have this spin review demo. And this is where we actually get our end users that people were working to deliver these pieces of technology for to come in and look at what we're doing. What have we done this week, in these two weeks? In this sprint, we've done this. What do you think of that? Do you want to give us some feedback? Or don't like that colour? Actually, that interface is a little bit wonky. That's not what I meant when I told you about it. And that iterative approach means that next week, the guys have already rewritten the stories or redesigned what they're doing. And we haven't lost any time. So we've got a pin to all by Jira. So how does this affect our Moodle deployment this year? So we moved from Moodle 3.11 to Moodle 4.2. And this is just a sort of a short window on a slightly wider project. This is from March to July. We delivered, I think it was the 27th of July, we went live with our deployment. We actually planned to deploy the last week of July six months prior to this. That's what our planning enables us. We said six months of time in that week, we're going to deploy. And everything was aligned to that. And our vendors were aware of that. They went, oh, you're tender six months in advance that you're going to deploy. You sure? Yeah, we're sure. And that enables us to plan so much better than we previously did before. So this was just sort of a little bit of fluff around here showing what we did. Talking about demo sites and things that we engage with users. What I really want to talk about is the sort of structure that underpins this. This is what Agile enables us to do. And for me, as a product manager at UCL or one of the senior stakeholders, I can see all the work streams that my teams have planned out. I can see all the interdependencies. I know what's happening. Literally on a sprint basis. We can see when things may be going askew, may be going awry or what's going right, where the interdependencies are. When a team says, actually, we're going to need another Moodle spun up in sprint three. The ops team go, yeah, I've got that on my board. I know we need to get that ready for you. It will be ready for you. Incredibly powerful. Now specifically talk about the teams that I had. I'm going to speed up a little bit here. The training and communications team. This was one of our transient teams that only lasted for three months. It came in at the end of March and their work completed when we went live with the deployment. Their sole purpose was to ensure that the institution was aware and engaged, that documentation existed for both our staffs and students, and to provide training. One thing that we found that we learned from conversations here last year and with conversations with other UKHEs is that the message about the Moodle upgrade is the most important thing. This, in a way, forget the technology. This was pretty much the most important team doing the work. I'll show you why in a moment, but this team literally bled to inform and engage with the users, to create that feedback cycle, to make sure that they were aware, we understood what their fears were, and to basically to remove those fears. The UX team. Again, another transient team. They're still operating. They're lifespan with timetable for 18 months. They're originally formed about last October. We had an idea of how we were going to change our theme, and it went disastrously wrong. We suddenly realised, I realised in October, this is not going to deliver. Not my original plans of how we're going to do a new theme. We're going to do it internally, in-house, with our current resources and knowledge. This isn't going to work. In the space of a sprint, turn that failure around, I wouldn't even call it a failure, but turn that issue around into a positive say, we're going to go like this, and we'll instantly engage with the vendor. We're going to get a UI UX specialist in. In the space of two complete sprints, we had that team up running and already engaging with our users, getting feedback on a new theme and creating that cycle between UCL and our vendor titers and with our end users. That's our new theme with the brand new upgrade on top of everything else. Underpinning all of this is our code base and ops team, so RSRE ops team. All the time, they have to maintain the current environment, they have to make sure everything works, they have to keep it running, but they're also reviewing the code base with each Moodle release, when 4 came out, every single one they're reviewing. They're building automated tests to run on everything. And this as well, again I'll come on to this as well, we developed pipelines for deployment. We automated tests with B-hacked, etc. To make sure that when, because obviously we have a small team, we don't have a huge amount of time. So we have to be lean, we have to reduce waste in the system and the way you reduce waste is you automate. So very quickly getting towards the end, benefits for Azure practice on the upgrade that we experience at UCL, tight feedback loops with stakeholders. With an iterative development process there are no surprises. Every day we were speaking to users, they were telling us, this isn't right, we had instances of 4, 4.1, 4.2, up, prior to we were near deployment. Each of those instances had iterative versions of the new theme, as we built it, it was there for our users, they could engage with it, they could feedback directly to the teams. We built a better theme and a better product all the way through. We found out things that were missing from our dashboard, so we built some new plugins to put into that dashboard. That tight feedback, as I said, enables you to pivot so quickly. Lean teams were focused on knowledge. Lean is a word about automation, really. It enables faster delivery and deployment and it makes the team empowered to make decisions. Cross-functional team members and flexibility, and also empowering your team members and making them cross-functional, you're not only empowering them in the work that they do, you're empowering their personal development. Our team gets stronger because they have the ability to decide where they are going, what they're doing, what technologies they are using. We still have governance, but the team works how the team wants to work. That is critically important for our agile implementation. If you think you can go in and say I'm going to have a team running agile, but we're going to tell them what to do, it will fail. This, my favourite slide, this was our institutional reaction to our Moodle upgrade. The best ever reaction that we have got, it was nothing. Our old service went down at 1am in the morning, they came up at 6am and there wasn't a whisper. We knew what was going on. Everyone knew what the new platform would look like. Everyone knew the new functionality on that platform. The academics and our administrators just engaged with it. Sure, there's normal problems that you get on a day to day with running any large system, but compared to where we used to be after an upgrade, and those problems that last for, oh my god, we've got to get this fixed, and that's gone wrong, because they didn't tell us they were going to be running a summer school, and the calmness in the team, the fact that we were like, we're upgrading, it's great. I've seen the management, what do you mean? My favourite slide, and that's our reaction at UCL. I'm nearly out of time. This was our Moodle, this goes flash up a couple of images, but if you want to see a lot more about it, as I said, our UI UX team are presenting this afternoon at 4pm and talking about their specific journey that they developed. So that was our old Moodle, our new Moodle. That was our old Moodle dashboard, our new Moodle dashboard, we've had lots of functionality. Our old courses, our new courses, bit better. And the thing is that all of this was built through user engagement, and the great thing is, it's not finished. When we delivered our Moodle at the end of July, we went, yeah, here it is, but it's not done yet, because that's not how agile it works. Now we've delivered to you, we can get more feedback, more additive development, and that's where we are now, and that's why our feature teams for UI UX are still running, at the moment they're wrapping up on the design around the actual theme and starting on course formats. So, takeaways. Agile is a mindset, first and foremost. Yes, it's a lovely tool, it can be called lots of things, but it has to be a mindset, it has to be embedded in the people who use it. They have to be empowered, they have to know about this, and the agile mindset, the most important people to know that and support it is the leaders of your organisation. If you do not have a leadership that are committing to agile delivery and an agile mindset, your agile teams will not be supported and they will fail. They'll distrust the system, the loops will stop working, they won't engage with users. So, for me, mindset over everything. Also we always aim to bring value to our stakeholders now. We aim to bring value to what we're doing. The team we're empowered, I've mentioned several times. Reducing race and system, so, automate where possible. Now, this time is in with DevOps. That's a talk for another time. Qualified by Tech League as Spark. We're doing a lot more in creating a DevOps atmosphere. So, automated pipelines, automated delivery, automated testing, automated push, and at some point I know that Alice is hoping to release some of those pipelines to the community. Dev, I'm the pinning everything. I love this one. If something does not deliver or enable the value to your stakeholders, that could be your students, that could be your staff, you have to ask yourselves, why are you doing it? Because all you're doing is you're wasting time and resources and money and not getting anything out of it. When we started on a show, we had so much waste and this activity of moving to agile has created a much better atmosphere for everybody. Thank you very much. That's pretty much my presentation done. Just wanted to share. On my slide, you can look. There's a couple of resources that you can go and look at. The digital education team blog where it basically documents the journey that we went through all our communication with end users. Also, the UCL has a confluence Wiki where we open, publish all our resource guides. It may be UCL focused but I'm sure there's some documentation that some people might find useful. It's all creative commons licensed. My UX team are talking this afternoon. Quick advertisement of them. I want to questions. Thank you very much. Can you create? Yes. Hi. I haven't heard anything about Scrum. Are you Scrumming or are you Agileing? For us, the two blend together. We use a framework at UCL called Thank You Safe which is an agile framework. It is Scrum but for the institution they change some of the terminology. We don't have Scrummasters. We have agile delivery managers. The safe framework is a framework based around Scrum based on an enterprise level implementation of agile using agile release train. It's all about agile release train so I didn't want to go down that route because I know it's confusing for a lot of people. We use a mini release train within our product to do our deployments on our work. It's not a traditional Scrum because while the framework is a safe framework we are empowered to run our product teams in whichever methodology we want and fix the situation. For example Scrum wouldn't work for a support team. We have a connected educational support team who are running more Kanban. They're not running too weakly sprints because that doesn't work for their support types. They would run a Kanban and they would pull issues to themselves. Is that okay? Might have time for one quick one. Down the back there. How many people wear you in this process? How many people in our information services? Just under 500. Within my product team there's 10.