 good morning kit lab, good afternoon and good evening for all the folks who are in different time zones. This is the 12 one retrospective. We are going to quickly cover the first three sections and then leave as much time as we can for the fourth section. Or we talk about improvements for those who are new to this process you'll hear me talk very quickly for through the first parts and then we will have a discussion for the last fourth section. The biggest retrospective improvement tasks just at a high level. Those are basically around two things from the last retrospective that we wanted to focus on. The first one was improving our access requests essentially were stalled and getting a both Devin staging for new developers in place. We talked with the IT ops team they determined that they were short on staff and as such asked the security team basically to come back in and help with those access requests so that we can get them resolved more quickly. That issue is effectively closed. The second one is the DB reviewers and maintainers on that one progress has been made in regards to the fact that we have some now DB specific metrics around this. We'll have to look into whether we actually start tracking those at the dashboard level, which I think would probably be a good idea from that aspect of it. Today I assigned it to Craig Gomes, essentially one of our engineering managers here in the development team to look into actually getting some folks signed up so that we can have some additional DB maintainers and reviewers in place moving forward. That's the update on action items moving to where things have gone well this month really seeing some really good collaboration across several teams showing the aspect that we're expanding out but we seem to be still working effectively around various teams, especially across functionally as well, which is recognized by our quality team. We've had good success with our Rails upgrade. Really excited about that to see us getting to the latest version of Rails. And obviously 6.0 will be out soon so getting us on a regular cadence associated with that is super important as well. Also on communication, lots of blog posts from the UX department. Thank you for all those. And the Secures team is actually starting to do development logs which is kind of a neat feature in regards to the fact of being able to get the most up-to-date status on what's going on on a given issue. In the area of forming, a memory team just formed in the last month and a half and it's good to see them making good progress. This was their first full milestone so you see some good feedback about learning based on that. And then also setting high standards within that team itself. And then last but not least, we've had an influx of lots of new talent. It's exciting and invigorating. We're seeing the new members actually contribute and a couple teams have kind of pointed that out how they've been able to get them up to speed and moving to contribute. What went wrong this month? Good call out around technical debt. Basically, we have a number of issues around technical debt where it seems like we've got some crusty parts of the code that we need to go basically address. Trying to determine how best to address this from an issue perspective. So if anybody has any suggestions around this, I think it's good to kind of go back here and kind of look at those aspects associated with it. There is a theme that appears with customer assistance. I think this one and then also I think it was later said I believe in the planning where we're seeing a little bit of changing in priority. Obviously, customers are super important to us and we need to keep moving forward with customers. So it's a part of the job. But you know, definitely means that we're having to shift priorities kind of at the last minute and that was causing some frustration with it. Started a conversation with the TAM on that specific one, which is exciting to basically work through that and see how we can best address that. We've seen some flaky issues with our review apps testing. We are definitely working on fixing those. Similarly, auto deploy had some similar issues where it broke QA images and we had to scramb to fix those issues associated with it. And then lots of observations around planning and how we can potentially make sure that we are planning effectively and also building in some capacity for urgent requests as they come in after we planned seems to be a theme that is kind of running through there from that aspect of it. And last but not least, in this section of how we improve equipment delays, basically two members of the memory team, obviously have mostly new members had some challenges with getting their laptops on time. I know that the onboarding team is working on addressing this. But it appears that we still have a few folks that are still still being delayed and getting their laptops by their starting from there. And I impressed myself only five minutes ago, but I thought was going to take 10 so I'm talking super fast. We've gone to the areas where we have how we can improve and we move into the area where actually you're from other folks in the organization so Sean if you're on the call I'd love for you to talk about planning. Yeah, thanks Christopher so the issue we had here was just that we tend to have things in progress so this this sort of feeds into a couple of things that feeds in cycle time but also we emphasize velocity of predictability so like you know some issues might take longer because of that because of like getting bumped down a priority list or because like you know they take a long time in review or whatever with the database reviews that we mentioned earlier. But what this means is because the plan team at the moment is just one team and it's 10 people. There is like a huge amount of work that is in flight at any one time which makes it quite hard to figure out like where we are in terms of like once we get to a boundary of a milestone. So I had and this applies not just to me but also I think to Donald so Donald speak up if you want to add anything here on the front end side. I think at the moment. First of all we're going to split the team in a couple of weeks when we get a new manager so that's going to help with that part as well. The main thing we are thinking about is just like how we how we categorize this and how we manage this like it's often not with issues where the scope is particularly big it's just often with the cycle time and with having a cutoff. Ideally for me personally like the more we can get towards a Kanban style like you know list of work we pick things off the top. The less these boundaries matter as well and the less we have to care about those and the more we can care about sort of overall cycle time without having to look at things with a snapshot necessarily. But yeah, it was it was it was challenging trying to figure out like how much of this work that is in flight is going to how much work does this represent in the next milestone so how much does that impact the new work that we take on in the milestone essentially was the problem there. Sorry, I took quite a long time there because you went through the first part so quickly, but yeah, that's basically it. Cool, do you think there's something we should track here that was kind of the one question I had in my mind grand the team splits going to change the dynamic as well from that perspective so. Or is it just to kind of an observation at this point and check back in. So yeah, the other thing is that we haven't had a full time product manager on plan and we do now and hopefully we'll have more than one soon as well I think so. That's going to help a lot as well because you know that we can sort of distribute that work better and we can do. We can keep track of things better as they happen rather than sort of like you know suddenly find them at the time so. From the comments like you know I see Elliot also mentioned this for verify for context switching but yeah for plan I'm mostly treating it as a thing that we are going to like work on actively improving like as a. Group at first and then if other people have similar issues like I've already taught some people in the dev section about this we can see if there's some commonalities but I'm not at the stage yet where I've got any idea what. What a specific solution would be for us right now. Cool thanks for sharing that Sean. Felipe. A flea paying to sorry I was taking. Taking those controls. I was just taking off. I think I think you covered everybody is there anything else on that topic. Anybody wants to share. Donald or Elliot. It's not present so that makes that easy. Cool then we'll move on development documentation is as well on the call. Yeah we know it's a small problem while working on an issue related to uploads and we know it said that we didn't really test really well on object storage and that's something that we we support on get lab. So we quickly fix at that. And then afterwards it we saw like an error in every of improvements that we could send a virtual quest to documentation so that we can document things to think about when making a change to get led so it's very common to send a change and sometimes we just forget about some integration or. Some related feature and sometimes you actually don't know and the reviewer just forgets about it and they maintain it as well. So that's kind of a problem. And it would be interesting to have like a separate guide for developers to read through and understand a little bit better integrations that they might be affecting so we have a section on that today. Thank you. That's great to hear that we made that adjustment for that piece of it. James do you want to talk about the customer portal app setup. Yeah, so basically we have some documentation on how to set up the customer portal. And the, well, especially the new engineers have been improving that with with time but it's still not great, especially for maybe not non techy people and the world in special needs updating and in the future as well. You may need to set up something similar to the decay or something like that makes it easier to actually set up the whole up because there's quite a few steps basically involved in the in the process. So yeah, we have that issue to track and then we have another one link there to further make improvements and have something like the decay. Excellent. Christy, you want to talk about. Changes in planning and position. Yeah, so just in general. I think that several of my teams experienced last minute priority shifts the things that they were scheduled to work on that they thought they were going to be working on that they started working on and get shelved as the milestone started and they pivoted to other things, which is is a struggle for them it leaves them just not doing their best work on those issues, but I think that we're we're smoothing that out and you'll see in the improvements that UX and PM are talking a lot about how we can make this process for everyone. Thanks Christy. Craig, you want to talk talk about documentation. Finding me. Well yes, develop and documenting the planning. Oh, yeah, sorry. Yeah, so I mean, the memory team is a bit of a unicorn right I mean we're a newly formed team. We didn't have we don't have a dedicated product manager at the moment we didn't really have a roadmap to pick up the release schedule change while we were forming as a team so we're, you know, there's a lot going on and we're trying to, I guess codify our own process and we have documentation from a bunch of other teams distribution create plan so appreciate all the existing documentation out there. And we are coming together as a team and just continuing to iterate and improve on our planning process I mean 12 to was better than 12123 will be even better. And I'm really keen to hear about how some of the con bon experiments are going on with other teams internally. So, that's our goal. And Jean, do you have an item to talk about in the planning area. Yeah, just quickly similar to some other teams we're in the configure stage we experimenting with using workflow based boards to have better visibility and prioritization of our issues. We are actually also considering adding in the planning phase to the board as well to conform to the product development workflow. We're busy discussing it we've had about one or two team discussions about it and most people on board of it so we're likely going to try it out for 12.2 and refine as we go. Excellent it looks like monitors doing the same thing because it's great to see teams dog footing the product by using this because it's a great way to track work and kind of understand the state of affairs in a given given area of the product so really appreciate you all spend time looking at those types of improvements. Excellent. And then test gaps. Sure. Thank you so we have in this is in line with prioritization and visibility as well. The history of good lab we used to have a lot of issues in every projects in regards to end to end test gaps. This has been hard for us to visualize the whole picture and then prioritize. Everything over to one single repo and dock with our product as a test case management system as we go forward and going forward we will be picking from this and hammering this down into the next quarter planning to go with the test gaps and then it's busy for everyone. What is left for us to do. Thanks. I'll go ahead and read the next one. Darva is not present but it looks like great is looking at improving by using a shared calendar or schedule around their sprint sprint planning so they can better coordinate associate with the teams and I'll follow up with Darva afterwards to see how we best track that or if that's fast enough that we don't even need to add a tracking associate with that. And then, Adriel, do you want to update us for workflow. Yeah, so we've had a desire to kind of iterate on our UX artifacts. The biggest desire that came out of our retro was to see more visibility into the UX design process as a whole. At first we kind of discussed kind of promoting velocity through low fi designs but through conversations with the UX team it turns out that has really less of an impact on velocity and the fidelity of mockups doesn't really impact that as much as fidelity is more a tool to use when things are unclear and uncertain. So we discussed instead just posting mockups to issues more frequently throughout the design process so that we can have more feedback and collaboration throughout even if the design is not yet fully complete. We've also had some conversations around marking issues ready for development when we have about 70% confidence or so that we're where we want to be design wise. So we're iterating on that process and they'll be I'm sure more to come as we as we test it out. And just real quickly I'll jump in to say everything that you're requesting is absolutely reasonable and what we expect on every single team so awesome. Thank you. Let me know how it's going. Thank you. Love the team across team collaborations that's exciting to hear. Thomas you have the next one on communication and team breakout. Certainly and happy Friday to everyone. So one of the things that came up during our retrospective is that as since we split the back end teams into two in the secure section. We also went ahead and split everything including our weekly team meetings and what that has led to unfortunately is team members feeling like they had to not attend one weekly meeting each week. But to in order to be filled to feel like they were informed as to what is going on and what is important within the section as a whole. What that is that feedback has been heard one of the things we started experimenting with this week is a section wide weekly call in order to do announcements that are of importance for everyone as opposed to just on one individual team. And then treating our weekly team calls as breakout sessions from that where we can get specific to what is to the subject areas of that individual teams themselves. This has been the first a chance the first iteration of this has been good in that it's led to people feeling like they're having to spend less time in meetings. And it's allowed us to really focus our conversation according to the people that are most impacted by these by the subjects at hand. So it's a it was a good first iteration on it and it was it was good feedback to get so that we can make the we can spend less time in meetings and more time working on the issues that were in engineering itself. So stay tuned for updates on this as we as we will find the process. Thomas I'm excited to hear what's working well and what's not working well. Well there so we're going through the same thing next month basically in plan. The intent that we had was to not split the meetings initially but split them if we felt like so like start from the opposite end like start with just keeping the meeting across plan and then split when we feel like we should we should split and see how that goes. Do you think that would have you know based on your experience do you think that's reasonable or do you think we should we should change and look to split at first and still have a stage wide one as well. I think a stage wide call is important because there undoubtedly there's going to need to be the same information given to all everybody within the same job family everybody's going to need the same information. However, there undoubtedly are you're going to my opinion and what I'm seeing is that each team needs the autonomy in order to discuss things that are only important to the to what the group has having to deal with. So that gives us the ability to experiment with different processes in each individual team and then come back and get more unified. It allows us to get specific and the subject areas that we're having to cover for us like static analysis we can get into that and that's not as a board of the software in the software composition analysis team. And they can get specific in their subject areas as well and have broader conversations about the issues they're trying to tackle. So, honestly, I think the split is important but as a breakout from the section wide call. So that's, I think that I think we've, I think we found the right cadence with this. Cool. Yeah, we'll check that out. I'll speak to the new manager once they start as well just out of curiosity real quick. What's the expected attendance like on those calls for security? Do you expect that most of the back end engineers can make a call for the each week? We have not changed the expectation in that for those that can attend synchronously. Great. You're welcome to do so. If not, please add to the agenda. It will be recorded. We'll be uploaded to YouTube when we're publishing that when everything gets uploaded accordingly. Sounds like we're on the same page then. Thanks very much. Happy to. Thanks, Sean. If you find that using that strategy is effective, we should probably update our documentation around best practice and team splits to reflect that. We'll have to review the documentation there as well in the process. Cool. Next one I have in the list is Luke. He worked on a number of issues that represent both front and back end work. These issues are really important in order to capture all the areas of discussion and it means I can independently track the back end progress on the issue board. So he's recognizing that there's some challenges there associated with that aspect and I'll have to follow up with the CRE team to see if there's any way we can better track that associated bit of feedback. And then Elliot also is not present. He was talking about the fact that the current workflow for taking over community contribution is actually pretty cumbersome. He's suggested an issue basically to capture that and to effectively improve it, which I've added to the retro to track associated with it because that seems pretty common theme across all teams where we would want to keep that as as un-cumbersome as possible. And Mac, you have tooling. Thank you, sir. So we need to migrate the teams to the new labels ASAP because this will be blocking charge workloads and it will affect our metrics flowing up to the dashboards. So the progress is going right now and everybody should be notified via email and we can review in Slack as well. So going towards the next one, we have it in five key items regarding reducing the CI pipeline jobs and review apps. So we will be focusing on this as part of our Q3 Yokoyas as well. And that's the recurring theme that I'm seeing. Thanks, Mac. So we have key improvements for the next release or subsequent to the next release. I'll say these are the ones that I felt like from reviewing the retrospective notes kind of jumped out at me. The first one was around just improving our installation of the customer portal. The second one was adopting the community contribution, making it less cumbersome. So that's basically the community contribution. The title is adoptive merge request from a fork from that perspective. And then improving our review apps success rate and then roll out of the new plan of labeling so that we can appropriately keep our metrics measured and responsive. The last one is just a follow up from last last month to basically revisit whether we're increasing our PB maintainers and signed Craig so that we can try that effectively and thank you Craig for taking that on. Are there any other issues that we should track at a high level from a retrospective. Are there any other questions. All right, we'll call it at 23 minutes and 50 seconds. Thanks everybody.