 Right good afternoon everyone. Thanks for coming to our talk very privileged to be part of this Incredible lineup this year. It's really good. So thanks for coming, right this afternoon We're going to be discussing the 2022 Bond on edu.au Drupal rebuild project that we went through together and Really how we stayed sane for 14 months. So let's crack on with it first off who we I'm Griffin I'm an agile delivery manager at previous next. I'm a chicken crimpies kind of guy Like sweet chili red rock deli chips and marvelous creations. I really like lollies. I mean only like chocolate. That's pretty much lollies So Nathan he's the head of enterprise application services at Bond University. He's more of a barbecue shapes kind of guy He prefers salt and vinegar chips and he likes dark chocolate. So that's probably everything you need to know about us Great this afternoon. We're going to be covering a few things We're going to be going through the original project goals of the Bond University rebuild project So why did bond do this in the first place and also was it successful? Then in the meat and potatoes of the talk, we're going to be talking about the key challenges of the project And what we did to survive those and then finally we're going to come back with some strategies and tools that we used to Stay sane for that period of time. As you can see here, we've got a takeaway on the side This one is what's your favorite flavor of shapes? So if you drift off during the talk or you lose concentration or you want to come back to a thought Those will be there. So there is a correct answer for this and it's chicken crimpies. So And then finally if we've got any time left at the end, but we do gather on a little bit There'll be time for questions. So Nathan what were the original project goals of the project? Thanks griff. Hi everyone. So first I want to talk about when Bond started its triple journey. So in 2014 we built a small internal team and we started work in a project phase on our main Bond website Then early in 2015 we went live with that in the following years We built some smaller subsides and some smaller web apps on there and we continue to support that during that experience of Managing the site. I've got some understanding of Drupal core How modules work within Drupal and a good understanding of UX concepts and web development technologies And this really helped me get a good understanding and prepare me for this project that we're going to talk about today and then in 2021 with the imminent end of life of Drupal 7 we started planning our new website Now this was not just going to be a simple upgrade and move from Drupal 7 We were going to start completely from scratch So what were the main drivers for this project? So for us we've been running Drupal 7 on-prem for about seven years We'd be running it on our onsite Campus data center and we were looking to move move to the cloud. So this was a big change for us We had no UX updates in that seven years and as you know seven years is a long time in the UX industry So the industry had progressed a lot since then and our site was looking a bit rough around the edges We have program pages, which is our main Our main focus when we were trying to promote content and we didn't have some structured content content on there We were moving content from some External sources on there to display that but mostly it was really an incohesive experience There were contributors from different business units, and they were contributing content on the different Program pages, but we were looking for an overhaul of those and provide a good experience for our prospective students And lastly we were starting to dabble into reusable content We had a few simple blocks and tokens But we were wanting to expand on that and build on this with our new website. It was a very basic architecture So what do we end up with? So we are now running on drippled 10. We're running on a scalable cloud and We are running on resilient infrastructure and there's less reliance for our bond infrastructure team to manage the site as a whole We went through a complete design and brand refresh so you can see some images here We've got a bold new design that has been released We now have a very much improved mobile experience while still maintaining a very unique desktop look We have a lot more structured content for our program pages So we are pulling content from three different systems now and displaying it on the website And this has a very Cohesive experience as students move between program pages. They can see the specific data points in the same areas And we have really improved the way that we use reusable content So we are using a create once publish everywhere approach and you can see here some of the content types that we're using so we've got some card types here that we're using reusing across pages. We have Forms here and we have different call to actions and so we update those in one place and they're reused across the website Overall, we're very happy with what we have now and it's been a big step up from what we had previously Implementation wasn't a walk in the park though. We did encounter some challenges and We're gonna talk about those now. Grypps gonna start first Fabulous great the hard stuff. So what was difficult about this project? Well, the very first thing from my perspective was the a word agile so everyone's had a nightmare implementation of this before everyone does it a little bit differently and this was a very Loaded word for Bond University in late 2021 Bond is a traditional large-scale traditional organization and similar to a lot of higher education and Government clients they use waterfall. They love it. They live it but Going into this project from management to the team down They knew that they if they wanted to build something that was ready and for students and fit for purpose State of the art was the phrasing. They had to try something a bit different. So They had this mandate and this drive to do something different and to use agile But they were entrenched in waterfall. So that was a key challenge of the project So the first piece of advice I got from my team when trying to solve this problem was don't be a zealot Bond was keen to learn but this wasn't this change wasn't going to happen overnight previous next We've used agile primarily scrum for the better part of 10 years. So we're comfortable Working and adapting it to clients, but you know, we just had to be wait patiently for that So the first piece of advice I really remember and talking to Nathan before we went into an executive team meeting was Don't mention story points. And he's probably right I think the main piece of advice we had to go into this was that we had to remain rooted in reality We can't you know be a bit airy-fairy. They were executive teams. There was a long-term engagements They weren't gonna come on board with that process. So and what I really mean with that is there There were things that weren't going to change at Bond. They had steering committees that were happening quarterly There were project working groups that were happening monthly. So our main process and thinking around this was to agile around it So what do we do? So we work within Bond structure. So we started small We started with daily stand-ups everyone's done them before but as a team that got us in comfortable working together and It sort of broke down barriers and ways of working So it made everyone a bit more comfortable making decisions together and also it ease that reliance on all we've got to wait for The next project working group coming up in a month and that would just take too long So starts more get the team comfortable working together. There's a great idea Then we introduced a few more agile ceremonies each sprint. So we introduced sprint demos. So stakeholders from those those other meetings could come to the catch-ups on Fridays and See what we'd been working on but it would also give bonds team Updates that they could take to those larger sessions So this would be Friday morning and then on Mondays we'd have our sprint planning sessions so that everyone know Bond what's coming up what things we needed from them to work on so nothing too revolutionary so far But really for this project the main thing that made it tick were retrospectives And that was a really big turning point for everyone to get it I do want to Fess up at this point that I personally haven't valued retrospectives too highly in the past I've always found them quite confrontational and From a project management perspective They're just another meeting that you need a book in to everyone's schedules but it really did prove invaluable and Improved the project week-on-week or fortnight on fortnight, sorry And gave everyone to chat of a chance to talk openly after quite a hectic sprint demo on Friday morning so as I said the intention of these sessions was to be honest and transparent and Catch up about what was effective for the last fortnight and what was proving difficult and sort of identify those things So we used a fairly standard of template of what went well What didn't go well and we also added a shout-outs column that said gave props to someone who went above and beyond that sprint so Nathan from a technical business requirements or a tester that had got through 45 previous next tickets in one week. That was great Some developers that did a great job. So From a tooling perspective, we used a thing called retrium for this ret R-I-U-M But there's a dime a dozen tools for this and the main reason we use an external tool was to keep me Get me as a project manager involved and didn't spend too much time just Coordinating the whole thing and starting timers and all that sort of stuff I think the big benefit of retro's is the blind voting as well. So you can see the black Dots at the top there. They're anonymous So if someone isn't as comfortable speaking up or voicing their opinion These voting these voting dots make sure that we surface and then we discuss things that everyone wants to discuss So as you can probably tell I don't shut up But a lot of people in the project didn't talk to as much so this made sure that everyone had a voice So that was really important. So really with retro's we we said that sort of fortnightly regular catch up And it really made sure that we were improving each sprint. So as you can see there The main way we dealt with bonds in experience with agile or long-term entrenchment with waterfall was time This didn't really happen overnight and each fortnight we improved You know as a team and getting working together I think another thing to really call out is that bond was engaged It wasn't a thing that we were dragging them through and saying guys you have to do agile sprints agile ceremonies They wanted to do this from the beginning. So that was one of the key challenges of the project. What about you, Nate? Okay, so from the bond side one of the first things that we realized early on is that we didn't have We hadn't put enough enough effort into Understanding the technical planning that was required So when we built this project when we started this project We'd really underestimated all the effort around planning and decision-making during the sprints When we first started the when we started the project there was really two clear phases We had a design phase and then we went into an implementation phase For the design phase we bought on a creative agency They came on board and gave us an overview of the education market and really led in that design and Imagination area and then they also spent some time Understanding our core products, which is our study programs From there they went into detailed designs and then they built Components and then the associate Associated annotations from that and then at the end they handed over a gel from there we went into the vendor selection mode and we went through that process chose a vendor and Then really we just went straight straight into sprints And what we realized earlier on is that during the design phase We'd spent spent a lot of time Visualizing the content and looking at how it would appear on our new website, but we hadn't spent enough time Understanding and investigating the technical feasibility for this and a big part of our new website was going to be improving our program pages and As part of that we were going to bring more structured content from external systems onto the website And we have our own integration development team here at Bond and they were working on API feeds to do that so to do this we needed to Make configuration changes and actually build out new applications to hold this source data And while we were doing that and building Starting the building process for the website. We were still configuring and building these applications It was like trying to build a plane and take off at the same time We realized we had a lot of technical planning to do to catch up with from our original plan So we'd originally planned to do all the program page development early on in the piece But bond we just weren't ready. So we had to readjust and look at how we could make this work So how do we do that? Well, we spent some time just together as a group And we made some decisions around how we would make this work and together We realized that making this work in an agile way was would be the mess the best solution for this So as we started doing configurations and designing the applications to host the data the integration team We're working with stakeholders to understand how we were going to format their APIs And then we were also working with previous necks to look at how that structure would link into the Sections of the program pages and the components in Drupal. So we really were working in an agile manner to deliver this The next biggest challenge for about bond was resource resourcing So to say resourcing was a challenge for us would be an understatement After we moved out of the design phase We lost three of our key team members in the web team They went on extended leave and a few sprints into the project We lost our project manager on the bond side as part of this during the implementation We also had to talk with our various subject matter experts out in faculties and other business units And they are all very busy. They have their own jobs that they do day to day So we had to arrange time to meet with them We had to foster collaboration and we had to help push them along in the decision-making process In the first few sprints we realized that we had a lot of all these gaps So we had to stop for a minute and look at how we were going to facilitate this to get to the end of the project And what we did is we regrouped we looked at all the responsibilities that were required for this project and We looked at the capabilities that we had inside the team here at Bond So what we decided to do is that we We formed three product owners and we decided to work as one product group and together we collaborated and communicated and made decisions as one to help us get through this project So those were some of the challenges that we encountered. The big question is did we stay sane? Well, just how do we stay sane? Let's go through that now. Griff's gonna go first So, yeah, those are some of the things that drove us insane. So how do we stay sane? So The biggest thing from my perspective was that we made sure that we were using or for your projects Make sure you're using good communication tools and processes So these are some very specific things that helped me stay sane. So We use Slack all on the project. We use it every day. We use it during the development. We use it now in BAU We use it from nearly every client. I know some of you will be mandated or love teams and So all of these tips will work for you, but this will help you through with your projects. So Number one tip I have is please please please use threads in your projects So you can see here Anna's asked a question. We've got six replies If I need to look back and see oh what happened there six months ago I can see immediately and search and find that Especially when we're in project mode and we had, you know, 13 people talking in a Slack channel a day And it was all going crazy. You needed to be able to digest and reference that and see who was replying to each other So If there's anything from this talk, please use threads in your chats Another recommendation I had and it came out of our retro process was that when team members came out of deep work Or they came out of an afternoon meetings They didn't know who'd been responded to or if the sky was falling or if these were just questions that could be done later So what we did is we implemented an emoji key for our channels So you can see there Anna's asked a question. It's a question mark But for the team a question means that this isn't world-ending. You can come back to this today the day after Just let me know that sort of response. Nathan a bit more dramatic. We've got an exclamation mark there It's blocking things when it is sorted out immediately And then Daniel's got an eye. It's more of an FYI there He's doing a deployment more that this is happening let you know Continuous stay out all that sort of stuff rocket ship means it's gone successfully Things like that are really handy to be able to just pass a channel and lots of information really quickly We've got green ticks that just means that it's been action You don't need to come back to that thread and then we've got a few down the bottom It's a fire an ambulance an alert and you can probably guess what those are related to Which we definitely use I just didn't want to use an example So oh actually one more thing on these if you use threads as well You can connect slack and JIRA and it's really handy for saying the immediate is there a ticket related for this You can create a ticket based on the thread. So do that. That's a good idea So speaking of JIRA and really any project management tool they'll sort of overlap I've got a few tips for you to stay sane So the very first thing from this perspective is have a conversation about how you use your project management tool first Everyone's used one. Everyone sets them up a little bit differently. Everyone's swim lanes being different things So just have that conversation Up front it'll save you competition pay dividends So here's how we set up for the project and we added a few extra columns to make it a bit more specific But the projects where you've got ten plus swim lanes are a bit of a nightmare. Is that in QA round two? Oh, that's a pain. Don't do that. So here's what we do Ready and in progress pretty standard, you know what they mean Needs review meant that it was in code review at previous next end needs QA meant it was testing on the bond university end Needs work meant that it was had either side had feedback and you needed to address that and client approve meant that it had passed Testing, but it hadn't yet been deployed So that's kind of how we we had a session. We just talked about the columns We needed to have them what the definitions were we got through 14 months with only those seven So you should probably be fine with that many Also a good fit of feedback that we got from one of our retros was Previous next is doing too many tickets and then throwing them over for testing And it's just making an avalanche of stuff that would come over in the middle of each week So what would happen is we would have ten plus tickets in that needs review column We'd then pass them all over for QA in one deployment and then the poor business analyst or whoever's assigned for QA Testing those and just be hit by about 45 emails. So That was difficult to deal with during the process. So what we do is we implemented limits So you could see red on that column We've also got it on the in-progress column and it essentially just says to the previous next team or developers Don't start any more work either do stuff. That's in progress do something else because it just like Once bond tests everything a week later it comes back and then we've got in progress and all the last week's tickets. So tips there We I strongly recommend this is to use a ticket template the next question after is this Is there a ticket for this is there I can't see what you're seeing question So using this make sure and setting this is sort of a ground rule on all projects Make sure that you get information that you need to set things up. So we use a title Description and expected result just means what I'm seeing and what I expect to be seeing and you can usually figure out the issue But pretty quickly steps to reproduce is very important. Sorry. I'm gonna go very fast. I just want to have more time Steps to reproduce and also we've got images Sorry screenshots and video attachments at the bottom. So with all that information, especially post project in BAU and you're doing, you know Managed services type stuff. This self helps you diagnose things really quickly prioritise Estimate all that sort of stuff. So I really recommend that The last thing I would recommend is to do a one-page sprint report So Bond as a traditional organization that a lot of reporting mandates They had to come back each sprint up the channel and say what we'd been working on So every Friday morning as I mentioned, we would have our sprint demos Then after that we would have our sprint retrospectives and then Friday afternoon Everything's dusted settled a bit of a little bit. I'd work on a sprint report So all this really says as a team what we'd worked on and what's coming up And if you if you're too busy you can't be bothered to even read the words We use traffic lights to just say if there's any dramas in any of the categories So if there was ever an at-risk or a critical item that came up on one of those sections We could just jump on it the next sprint. So I can give you this template, but it's very simple I recommend something like that. It's also really handy when you're doing a talk a year later You can see what you got up to each sprint and you're like, hey That was a nightmare. Oh So I really recommend just a one-page report for your projects. That's a really good tool So those are some of the ways that I stayed sane But Nate, what about you? Thanks, Griff. So I'm going to take a bit of a different angle This part of it this part of the talk I wanted to talk about how you can master character traits or Emotional values to help you get through difficult conversations and projects So character traits and you know emotional values aren't something that we talk a lot about in the development industry And I know it's starting to grow a little bit more But I think it's really undervalued and I think we all have an opportunity to learn and grow from it So what I'm going to do I'm just going to talk about some of the character traits that I Realize that I needed to work on to make this project a success so the first one is adaptability and in this project both the agency and the client really had to work on adapting How we worked to get to the end goal. So from the bond side of things we are as I said mentioned earlier We were struggled in some resourcing areas so we had to regroup and we had to look at how we would step into different roles and this was Challenging for some people as they'd never really worked in this way before and they had to step up And understand their area a lot more and become decision-makers in that area On the previous next side. They had to learn how to accommodate multiple Product owners so when we started the project they told us that they're used to working with one and then early on early on we put it to put it to them that That we had to work as three and they were able to adapt to that and we made it work The other thing that they had to do is our understanding war of agile was very immature So they had to guide us and help us adapt to how we work in this way and really support our capabilities So how do we do this? Well, we had to put aside our previous thoughts around how roles would work And how we would work together to get On no, no, it's back how we would get towards the the end of the project, but we had to still do it within Setting healthy boundaries. We didn't just do whatever we could to make it work And the best way to do that kind of leads into my next point, which is humility So I know this is not an issue for developers in this Talk look, I would just I'm sure you're all mastered it here So just take some notes and take it back to your teams at home and you know, you can just share it there but seriously I've really learned to value humility as a as a character trait as I've learned and grown in my career and built more experience in leadership and management and I think That human being humble you're learning humility learning to be teachable builds character And it grew leads to greater respect which leads on to greater greater influence now How you use that influence is a completely different talk But I can still see that progression that I've experienced in my career And when I when I really think about how we use this within this project I think about how we worked as a team and what we really had to do was Set aside our own personal ambitions or what we thought as what we'd achieve as goals for this project and just focus on Supporting other and complimenting each other's skills to get to get to the end of the project When when you think about your career, especially in you know development. There's always new New languages or new frameworks new versions of things and you kind of plot your career along those kind of things And you don't really think of you know Oh, actually I need to learn how to practice more humility as part of something that I want to develop my career in But I think that's really important night and I've learned to value it over time A lot of people kind of think humility is a weakness, but for me, it's the ultimate superpower And my last point is really around challenging ideas now people can find this Really confrontational, but I found it's can be really effective. You can see In different situations how there's some people who don't really want to challenge ideas And then there's people who just love doing it and will do it just for the sake of doing it So learning how to balance that is is really key in my Come into this project. I had some Drupal experience and I thought that things would go a certain way But previous next had to challenge some of my ideas and when we were designing solutions I had a chance to challenge them back So it was a bit of back-and-forth, but we got there in the end and we built strong relationships out of that So yeah, that's really the main ideas around You know some of the emotional and character traits that I've learned out of this project Actually, there's one more The main thing about staying sane in a Drupal project is managing your expectations on Drupal 7 and of life dates So I a few times I went to steering committees with my Tail between my legs having to tell them that and a life dates had moved again Okay, so let's wrap up So you can see here that there's a practical side That Chris spoken about two projects and how you can stay sane and then there's the human side which I've shared and I've Really realized that both have equal value and it's really important to consider both as you go through the project Overall the project was a success Bonds learned to work in an agile way more effectively. We now have CMS running on Drupal 10 We have a beautiful modern design. It's more mobile friendly and it's cloud hosted We have more stronger data integrations into our website that provides a comprehensive experience To our prospective students We have a functional backlog and we work closely together together on it day to day We've learned a lot from this but and become streamlined in how we work So honestly, this is not some sort of TED talk for us But we wouldn't be sharing it if we weren't living it day to day and we know that it's helped us get to where we need to get to Today, so we hope that this has helped you learned Learned become more proficient in how you work in projects and how you work in your teams And we thank you for your attention during this time. Thank you Great work guys. So my question is you mentioned something which is quite common, I think and that In the design phase when you started going into that implementation phase That you hadn't really thought of some of the technical limitations or So on and so forth about the design. What do you think? I could ask some good ways or good learnings to avoid that in the future because I think that is a really common Yeah so I think the main thing we'd learned is that you need to bring your developers on early and From what I've learned Creative people and creative teams like to work in a certain way. I wouldn't say it's Perfectly waterfall, but they like to go through an iterative process in their own and What I've realized now is that you could adopt that to a sprint type model where you do certain elements of design Then build that into interfaces that you can test against and actually have practical content against So that's one of the things that I would Recommend to people be able to have your dev team on the onboard early and be able to iterate not just in design But also in in development My Block things that's oh there was plenty of them. Um, I mean the easy answer is they carried over sprint to sprint Like we've kept coming back quite a few times But the program pages were really large deal and a really big it was difficult on this project You know, we needed to go to each faculty to sort out their different snowflake version of the program pages I think really all that really means is They carried over There was a time when we had to stop work on that and shift it till later and just give it the consideration it needed to So it says a question they carried over and we sort of ended up with the project saying to bond look You guys need to figure that out We'll go work on something else for a little bit and that's how we did it. How do we flag everyone new? They would they would just roll over to the new to the next sprint. Yeah, we just move them out of the spring into the next one We were challenging Yeah, I think the big thing for us is there wasn't really the whole one team on dream thing But there wasn't really two teams working on it separately like we weren't we were Catching up as a team together being silly and stand-ups and that sort of made it a bit easier to understand when you know They were working on something or as challenging or pushing back everyone got a bit more comfortable saying, you know We wouldn't build it like that. Don't do it like that We're trying to use it more and more we have a very What would I say we're used to working in a certain way and I'm trying to push that a bit more but And I think this project has been good because it's demonstrated how we can work, but we're still learning internally How we can do that? So we're gradually picking it up and yeah, we'd like to use So Okay You go in and everybody just Yeah, so everybody just gets rid of it and then you have a solid discussion and Also, you all agree That people can be angry and that's When you do this in New Zealand, nobody says anything Oh No, I don't think so so early on the first few retros even for myself like I it's hard to engage and You know be quite honest and transparent, but I think you had you had to warm up to the process What I would recommend is if we did have a difficult period during the sprint or something bubbled up during a stand-up For example would say look, this is a really good point for the retro So like so try and put pins in things throughout the sprint say bring this up on Friday Bring this up during the next catch up rather than have Everyone terrified for this meeting that's going to happen or trying to save their bullets for that session Rather just make it sort of a thing that's part of the process But it definitely kind of like the whole thing. It didn't really happen overnight We did get a lot better at it and a lot more comfortable during the process. So that's one way of getting better maybe