 Welcome everyone to Webinar Minimum Viable Process by Nayan Hazirakwala and Julia. We are glad that both speakers joined us today. So without any further delay, over to you Nayan. Hello everybody, I'm Nayan and this is Julia. Hi, happy to be here. Thanks for coming. Yeah, we're here to talk about minimum viable process. So first we'll kind of set the stage about how we came up with this idea. So Nayan and I were part of a team together and it was a newly formed team. We were coming together for the first time. We were also working together fully remote for the first time. And so we had to like all, like a lot of teams do when they're coming together in the beginning of a project, we had to come up with some working norms. And what we decided as a group was that having a high standard for software building excellence was very important to us. We wanted to achieve this in a way that we thought would be as easy and least formal as possible. So we came up with this idea of the way that we work being called the minimum viable process. Right now folks have probably mostly heard at this point of the minimum viable product, which as Eric Reese in his startup book called described as the version of a new product, which allows a team to collect the maximum amount of validated learning about customers with the least effort. So our minimum viable process idea is similar. This is the version of a process which allows a team to quickly deliver the maximum amount of value with the least formality. Now we know it's really tacky to quote yourself, but we did. So we just thought it was a little bit funny. So this is kind of what we mean by minimum viable process. So we'll take a quick look at some of the agile practices that we used on our team, and just kind of talk through each one, like, you know, the purpose of the practice, the amount of time that's spent on it. Various patterns or anti patterns that we've seen on other teams, and then how our team ended up actually doing that particular practice. So the first one that we'll talk about is the practice of stand up and product demos. So, like Nan said, we're going to go through a few different agile practices. If there's a particular practice that you want to talk about just note it. And, you know, and we can get to it in the Q&A if we don't bring it up ourselves. You'll find that there are some practices that we actually didn't, we didn't do it all as a team, but stand up and demo our two practices that we thought were really important, but we did it in a little bit of a different way. So stand up, we did every day, Monday through Thursday, in the beginning of the day, so we would get together at the very start of the day. And we would time box it to exactly 15 minutes. Our team was about seven people. And the way that we would do it was instead of oftentimes I see stand ups that run in the format where you go kind of around the table and everyone has to make a note about what they did the previous day, what their plan is for that day. The format for ours was a little bit different. So we would log in together at the beginning of the day. We would start off with a quick icebreaker or a quick like two minute game. A couple that we really liked were the New York Times has a mini crossword puzzle that we could pull up on the screen, or sometimes we would do a trivia game around like flags of the world. And so that was like just the two minute vamp to get the team warmed up and get us ready for the day. And then we would pull up this board. And we would just talk strictly about what is in the in dev or in development column. And we would just go card by card and talk about what that what the status of that card is. And if there's any helps needed or any blockers or questions any updates. And then. And then that was pretty much it sometimes depending on the workload and in development we would talk a little bit about the ready for dev column. Like maybe the one or two cards that are next stop ready to be picked up. But really we would just talk about the work that is in progress. And then we saved, you know, remember that we were really diligent in keeping the time box to 15 minutes. So if there was a little bit of time we would also share other updates or other like relevant information that was important for the rest of the group to know. But other than that we would keep it to 15 minutes exactly and we would be able to fit all of that within 15 minutes. Another thing that really worked well for us is that we rotated stand up hosts. So in the beginning of the month we would post a stand up schedule and just rotate who would be who would be hosting. That was a really good way to make sure that we shared context about what what work was involved so. Like when you're having to lead a session you tend to retain information a little bit more as opposed to just like logging in hearing what we're talking about. So everyone had a chance to lead the session and kind of control. You know the conversations that we were having around the work that was in progress. And also everyone had a chance to practice their facilitation skills which was important to us as a group. And then demos we would often include in this 15 minute session. So we wouldn't demo every day, but we would demo as needed specifically when things were deployed to production. So the way that we would handle this is that engineering work when it was considered done would move to deploy to production. So it was before we would market as completely finalized we would validate that card meaning that we would demo it. So, depending on our capacity and when we were finishing work, we would often demo in stand up or sometimes immediately after stand up and that was a way to shorten the feedback cycle. So we had to make sure that we got feedback to the engineering team, like immediately or really within 12 hours or by the next working day. And everyone could hear the feedback around that card. So if something, if something was working exactly as we expected it to we would move it to validated and you know our day was easy. But sometimes what would happen is that things weren't working as we expected it to. So we would move it back to in development, or sometimes a different issue would pop up so that thing was working right but something, but we noticed something else and so we would be able to quickly respond to errors or problems that we saw. And then in that case we would oftentimes create a new card to address that new issue. Another thing that I want to point out is that when we would move cards back create new cards. That was never a point of that was never seen as a misstep for the team or a bad thing to happen. It was really a positive that we could all see something quickly see it together and make sure that we were quickly aligned on what we had to do as a team next. And just the last thing I'll say before name if you want to add any other commentary, I jumped into talking about our team board without really talking about the columns so excuse me we kind of organized our work in a con bond style. And these are the categories that we had so we had backlog, which is work that we wanted to do someday, or work that other people wanted us to do someday. So this is prep for development. So this is work that we were getting ready for engineering in some way so it could be creating mocks, it could be requesting access or maybe even like a little bit of discovery that the product owner product manager had to do before it was before it was ready for engineering. And for dev. We considered this to be work that was ready to be picked up for an engineer, meaning that it was vetted to the best of our ability. The name is going to talk a little bit more about users stories but I will just note that we were intentional in our team about being really collaborative in the way that we talk about user stories. So that doesn't mean that so things could come up, you know, after a card is in ready for dev like new learning to come up as you're starting to implement it but to the best of our ability, like all of the pre work was done. And we thought that we had a plan in place when we put it into the ready for dev column in dev meant that it was being actively worked on. And then deployed to production as I explained me was that all work was done by engineering validated is that it was validated by the product owner product manager, and product team. And then we had another column that I didn't show here, which was released to customer. So, ideally, we would be deploying to production, and then, as soon as it's validated released to customer. Because for bigger features, we couldn't really sit until all the work on that feature was done so we would kind of have it waiting and validated for a little while. The other thing that I didn't know on this board this is an example of the board that we used we also had with limits on on these categories so I think our limit for in development was eight cards for prep for dev and ready for dev we had four. I just wanted to mention that the way that we are able to, you know, people might be wondering about the deployed to production bit. We did a majority of that through feature flags so that we could deploy code to production without it actually being live to the customer. And that kind of went along with our continuous deployment pipeline and so on. The only other thing that I wanted to mention was, you know, sometimes some of the anti patterns that we see and other teams is, you know, you sometimes see like standups that are lasting like 30 minutes or even like even longer, which can be fine if that's something that is valuable but more often than not. A lot of those 30 minutes are spent by, you know, somebody on the team just kind of rambling about something that isn't really of interest to the rest of the team. And it tends to be a little bit scattered, particularly when you're going around and everybody has to say something. You know, somebody may not have something interesting to say or may not have something relevant to say that day. I mean it's not really that helpful to let everybody know that you spent the day in meetings. Okay, well, that's nice. You know, you could have mentioned that in Slack or something. There's not really a lot of value to that kind of discussion. And also, when when teams are doing a lot of pairing or mobbing, you get a lot of things like, oh yeah, I did the same thing as the other guy did. And so, so again, that's not really a value added statement. So by focusing on the actual items on the board, it focused the discussion on what was needed to get work moved into production. To expand on that a little bit, I think one thing that we've noticed is that when you go, you know, the purpose behind going round table and hearing from each team member, I think has good intentions is that you want to include everyone in the discussion. And you want to encourage, you know, you want to kind of give equal voice to everyone. But I think what actually happens in that format often is that people feel pressure to like give a status update about what they did. And we wanted to take that, that kind of feeling away. And I trust with everyone on the team that we're all working together and that we're all doing what we had to do. So just talking about the work that was in development was sufficient for our team. And then we, we were able to still achieve that collaboration and include your brain everyone into participate by rotating stand up posts. Practice is user stories. So we did user stories maybe a little differently. You know, one of the things that we see a lot of times on when people are creating user stories is kind of this tendency to try to create a large document that describes everything possible that is needed that can then just be handed over to an engineer who will then just read it and build it. And that usually comes in the form of, you know, just very detailed notes about everything, you know, tens of acceptance criteria is or 20s of acceptance criteria is and just lots and lots of detail under the assumption that doing that will allow somebody to just pick it up and work on it. That's actually, you know, one of the things that the agile movement was kind of trying to move away from because those, you know, kind of requirements documents as it turns out don't really work that well because a lot of a lot of assumptions go into something when you write when you try to capture everything just in the written word, whoever's writing it is making a lot of assumptions about why, why it's there. So, you know, that this comes up in seeing things like templates. So you'll see like as a system I do this or as a user I do this, I want to do this so that, you know, so that the, you know, so and so and so and so. That format is okay. The reason for it was so that you're sure of who the user is that you're writing a particular feature for. And you are explaining what you want and you're explaining why you want it. That's the so that part. The problem is that when you just are dogmatically stick to that format you end up with just like a lot of extra words. And it sometimes is less clear about what you're actually trying to do because you're so obsessed with trying to get it in the right format. So, that's another thing that we kind of see a lot of happening on teams. And then the third thing I see a lot on teams is just with the acceptance criteria. I'm not exactly sure why this started, but it seems to be quite prolific these days is that people are writing their acceptance criteria, using the given when then format. That in itself isn't necessarily a bad thing, but the that given when then format is it's called the gherkin syntax it was written. It's, it's, it's kind of a templating language and the intent of it is so that tools such as cucumber can read those tests, read the acceptance criteria and be run as automatic acceptance tests. The thing is, if you're not using a tool like cucumber, and your acceptance criteria are strictly stored in your, you know, user story tool of choice. Then there's really no value in having the given when then syntax it really and it makes it actually kind of harder I think to read, read what the acceptance criteria is because you're kind of forcing yourself again into this particular syntax. So, so it's a little strange because you're you're trying to use a language that was meant for automated testing to not write automated tests and, you know, using cucumber is great, but I just see a lot of teams not using cucumber and still using the gherkin syntax. And sometimes I've even heard teams say, oh, sometimes in the future we might use these as automated tests, but it's not really that simple. Those things really need to be done collaboratively with your development team and so on and a lot of times they're not. So, we kind of went back to the back to the roots and talked about user stories as placeholders for conversation, which is what they're supposed to be. And so our user stories were very simple. We had, you know, really try we tried to make a really nice descriptive description of here's what the user story is. I think we I don't guess we don't have an example of one, but it might be something like a user, the user customer needs to be able to update their phone number in their profile or something like that. And that would be it. So there would be, you know, there might be a couple of notes or something like that in the in the story itself, but but for the most part that description is really the gist of the of the story, you know, we might put a little link to a mock up or something like that. And when, you know, as you know, you saw the previous on our user storyboard, when we when the developers picked up a story and started working on it, the very first thing they do is get together with a product owner and say, Hey, let's have a quick chat about this story, regardless of what it is. And just talk through it, you know, five minutes, 10 minutes, however long it takes, just so that everybody understands what we're actually doing, why we're doing it. So getting all of that context around the story. And in general, people already knew, but we always had that conversation just to make sure that we're not making assumptions about about how it how it was done. We also tried to kind of scope these things small enough. So it wasn't, we weren't working on things that take weeks and weeks and weeks. The general guidance to the team was a user story should take a couple days. If you think it's going to take more than a couple days, then split it up into something smaller. And that will also is the extent of the estimation process. So there was no, you know, planning poker or any sort of really long planning session where we had to, you know, deconstruct these stories. Can we get it done in a couple days? Yeah, I think so. And that's all there is to it. The, as far as accepting, accepting stories, you know, the by the product owner, which in this case was Julia, you know, the, what we didn't want to do is have completed work sitting on the shelf and waiting for a long time. So as she described, we would, we would try to get feedback immediately. So even if it was midday or something like that, we don't necessarily wouldn't necessarily wait until the next day's stand up or the next day's demo or something like that. We just reach out immediately and say, Hey, this thing is done. Can you quickly take a look at it? We might then also demo it in the next, in the next stand up, but really want to get that feedback as soon as possible so that if there's anything that doesn't seem like it's quite right. We can immediately just go and fix it. And as Julia said, we tried to get things validated from when it was completed, try to get that validated within within the next 12 hours or so, or by the next day. Anything else Julia on user stories? No, I think that's right. I think you covered it. All right. There we go. Oh, looks like I have some more bullet points here but these are the key points that I was talking about. So wrap it up, get it done. Don't, you know, that was, you know, don't have these stories that are lasting for weeks and weeks and weeks. All right. Yeah, backlog grooming and iteration planning. So this was something that we actually didn't really do in a, in a very formal way on the team. This was probably the activity that had the least formality. So, as I said in the backlog, we would keep a list of things that we had to do one day that we knew we had to do one day but maybe the work wasn't ready. You know, the project wasn't ready for that work yet. A work, it was also a list of things that we wanted to do someday, but we had other priorities that we put forward first. Excuse me. And then we would also keep a track of, you know, work that other people wanted us to do but we didn't have time for it at that moment. So then how would we organize all of that. So we sort of had quarterly goals that we wanted to achieve. And we kind of knew the state of the project like as a team we talked about what made the most logical sense like we had to start, you know, what did we have to start with before we could continue to build upon. So we kind of had quarterly goals, and that would influence the work that we would prepare for development and the work that we would put in the ready for development column. And we would just kind of see how fast we were able to cycle through that. And when it came to a point when we were wrapping up the first goal that we had, then we would kind of huddle together as a team, and talk about like, okay, what makes the most sense for us to do next. And then we would pull one or two cards and that would kind of dictate the way that we know what our next goal was, and what the next cards that we would pull forward would be. But we wouldn't do this on a regular cadence. You know, oftentimes we see teams that have like a bi-weekly iteration planning meeting. So like in two weeks, no matter what, they would plan for, they would get together for an hour or an hour and a half and plan for the next iteration. We just kind of let the pace of the work dictate that, and we would get together as a team, but kind of only when the work dictated that we needed a new goal, or we needed to pull new work forward. Is that right, Nain? Anything that I should add? Yeah, and like you said earlier, we had whip limits on these columns, so really the only time to prep new work for development would be when those columns were starting to run low. And again, not prepping so much work, just prepping the next couple of things. The other thing that that enabled is, you know, as everyone here knows, priorities change, and they change not on a cadence, right? They change at any time. It could be the next day that all of a sudden, oh, you know what, there was a big meeting, the stock market crashed, whatever, anything that happens, you need to respond to the business changes. And you know, not that it's a huge deal, but you know, there's like this momentum when you have like all this stuff that's like ready to go. And so what this enabled us to do is not plan things that we're not going to do. If it was getting planned, it was getting done. And that was it because it was really the next thing up. And you know, even still, if it still got planned and we had to switch something out, it was only like one or two things that would have to switch out, not a big deal. But in general, by the time it made it to that ready for dev column, it was going, it was ready to go. So that enabled a lot of flexibility and responsiveness. And it saved a lot of time because all that time that you spend in these planning sessions, planning work that you're never actually going to work on is time you've just taken away from the work that you could have been working on. So it's kind of like a double whammy when you spend those extra time in those planning sessions. Yeah. And we didn't really have like an extra backlog grooming session, per se, it was kind of that we kind of categorize these together because it was just kind of, it was just kind of one thing, you know. I will say, you know, similar to the comments that I made about the stand up and demo, I think that those team meetings where you come together and talk about the backlog, talk about your, like, doing an IPM and talking about your goals. Those are good activities to align the team to make sure that you're communicating that everyone understands the work. We were able to achieve the, the purpose of all of that, just in a less formal way. So we got together and aligned as a team as needed, not, we didn't just meet for an hour, because it was on the calendar to do so we did it as we needed to as a, as a team. All right. So one of the other practices that we used quite a lot was a pair programming. And this kind of started when we first started working together we, we did a lot of mob programming. And so all the developers sitting together and just kind of working on a particular feature together. That really was helpful in making sure that the, you know, everyone knew what was happening and it got a lot of good design ideas, particularly as the project was starting up, let it let everybody kind of collaborate on what the, what the, you know, general architecture was and design and so on. I'm a big fan of mobbing I really like it. After probably a few months the, the team started feeling like hey, you know, I think we'd like to try to do a little bit less mobbing and a little bit more pairing, which is fine, you know, team does what it wants to do. So we started started doing pairing. And the way that we did it was every week we would switch pairs. And so no matter what you were working on, you would just swap pairs. People seem to like that. The, the one thing that was kind of happening though is that you kind of people kind of got stuck under their stories. And there was kind of this tendency to for work to kind of, you know, people wanted to stay on their, on their thing, because, oh wait, I have one more day to work on this thing. And, you know, there was a lot of hesitancy to switch and get off it. So, you know, we started, you know, living by the adage of something is painful do it more often. So we decided to address that by switching to bi weekly, bi weekly pair so we, every twice a week Mondays and Wednesdays we said, okay, well let's switch our pairs and see how that goes. People seem to like it. Still, and actually what seemed to happen was it actually started our stories, cycle time started going down a little bit. I think part of it was that people knew that they were only going to be working on something for a couple days. So let's try to make sure we can get our work finished within a couple days. So there was kind of that. It wasn't a direct maybe a one to one or super obvious correlation, but it was definitely something that was noticeable. So people like that. So again, sticking with the idea, you know, do it more often if it's a little painful. We started doing daily pair swapping. And this is what ended up sticking and people really liked it. And it was just, you know, after stand up the engineers would just get together for five minutes. We'd run this little tool. We use the tool called parrot par it and let's you just put in a list of your people. And then you just click a button and it just assigns pairs. And the way that we did that, excuse me, was So if two people are always working on a given story, the next day, one of those people would stay on the story and continue working on it if it was still if there was still work to be done. And the other person would switch to something else. And then the following day, whoever the newest person on the story was would stay on the story. And the, you know, the oldest person would go to the next thing. So at most, any story you would only ever be working on for two days. And by swapping that oldest and newest person, we made sure that it was you were never in a situation where, you know, I'm pairing with somebody and the other person is just watching and not actually doing anything, particularly, that's easy to fall into when we're doing this remote pairing and so on. It ensures that everybody's the pair is engaged in the work. Because they the newest person on the pair is going to have to, you know, guide the next person on the pair the following day. So, so it really made sure that everybody really was engaged into what was happening. And that's kind of where we ended up on the pair, pair programming, and that worked out very well. So any other comments, Julia? No. Just that, like the daily, you know, once we moved to daily pair switching, we never went back. So team, the engineering group will still mob if there's like, you know, bigger tech, if there's a story that's like, has more technical unknowns, you know, or maybe sometimes like two pairs will come together depending on what the problem is that they're stuck on. But, but we never reverted back. The team really liked the daily pairing. Yeah. Oh, I guess a couple of things that you know, the, the other thing, a couple of things that's enabled was, you know, really, you know, just killed any sort of knowledge silos. The team, the pair was able to just decide on which, you know, what they pulled in work. So whatever they wanted to work on as a pair, they could pull in based on the highest priority thing. So you were never like, Oh, this guy is the only person that knows how to do X, Y, Z. So, you know, only they can, you know, do any of the, any of the graphic stuff or whatever. It was always, it was always an opportunity to work on something new. And then the other thing on the team, there was a very strong culture of helping. So if, if one of the pairs needed help or something like that, you just post a little message in Slack and say, Hey, can somebody pop over here and take a look at this problem and, you know, within a minute or so somebody would come in and join, join in. So that was really nice. I get sometimes people ask about like how that actually how we facilitated that piece of it and the way that usually work we use Slack huddles, which is kind of a nice little thing. And what we did was we created channels for each pair. And so, you know, there might be a channel for pair A channel, pair B, C, D or whatever. And when you start working, you just start a huddle in one of those channels. And so that made it really easy for somebody else to just join into to your huddle without having to like get an invite and you know all that kind of stuff. So we wanted to keep the friction low, you can just go to the channel, click the join button and away you go. Yeah, okay. The other thing that I'll add is that that culture of like help asking questions, having conversations when you're stuck that we would extend that culture, not just within the engineering pairs, but to the other product roles on the team. So, the product designers product managers product owner. If there was a question that the engine, you know the engineering pair that was working on that could reach out to anyone on the team. And so sometimes that meant like posting a channel or posting a question. And so if someone else was in a meeting, you know they would get to it within an hour, but oftentimes we get to it within like 15 minutes or so. And so sometimes the, you know, PM or the designer would join the huddle and just like talk through whatever the question is that the pair had. But I just want to make it clear that the, it wasn't just up to the pair or the person that was previously working on that card to answer questions the whole team had ownership of helping jumping in and answering questions. We wanted to take a quick question break. And I know that we're going to have one at the end as well but this has been a lot of stuff that we talked about already so I don't know if anybody has any questions I don't see anything in the Q&A right now. But if anybody had a quick question we'll just pause for a couple seconds here to see if anything filters in if not we'll just continue on. We've done this session a couple other times at live venues and usually there's like a lot of questions at this point so we thought we'd open it up. But I know it's near the end of the conference and people are getting tired so we're tired too. It's very early morning here for us. Alright, well let's just continue on. Oh, here's one question just popped up. Can you please shed some light on how the upstream downstream dependencies were handled. So like dependencies I assume this means dependencies on other teams if there was another team that we're like waiting for some sort of if we're waiting for some sort of API from some other team or something like that or needed some sort of system integration or something from another team. So I don't know that we handled this maybe any differently than most teams would handle it. You know if it was something you know a lot of it has to do with how the other team operates so we might have a request out to another team to do something and there were a lot of cases where you know those teams work in a very you know waterfall ish or scrum or fall ish or whatever you want to call it kind of way where you know you have to let them know three months ahead of time if you want something. So in those cases you know we would do that and then you know we kind of knew the cycle time of our team and so we would put a request out to them and then just kind of wait for a while and then start working on it when we needed to. We tried to be as collaborative as possible so a lot of times we would try to go and you know either pair with or other teams and help them out. I think you know we had some success in that but probably more often than not you know the other teams were just you know too busy to you know they were just too busy to do that type of collaboration. So yeah. Um, I can add that I think I was the product I'm the product owner on the team. So this is a lot of the work that I take on, which is like interacting with other teams helping other teams prioritize the work that you really need to do is something that I try and help the group with. My approach to this is, um, sometimes I describe it as like software development as a game of Jenga, if you've ever played that where you're like looking for this for the, for the block to remove that has the least resistance. So, if we have a list of like five features that we want to add, we sort of rank them okay which of them requires no dependencies that will do first, what requires a little bit of dependency. Sometimes it's really easy like if it's requesting access, you know, I'll file that paperwork or whatever, and then we'll wait, and when we get a response will do it. Um, sometimes, you know, we'll have to escalate it if if we're um, uh, or sometimes it's not even just about escalation but like if if we need a team, if we're creating something. But we need another team to add a button before that. Um, like that feature can display to the customer. We need that before we can go live. And so to me it's just about like really clearly communicating the needs with that other team, and also being respectful of their workload and giving them enough to like having that conversation far enough in advance that they're able to plan the work so Um, after, you know, we were, as I mentioned in the beginning, we are a newly formed team in the very beginning don't exactly know how long it's going to take you to finish the work. But I would say after like two or three months we started to get a sense and so I would give teams, you know, so I would, I would kind of be able to estimate with and I would always take the larger estimate, you know, so give them a little bit more time and say we're going to be ready for this and if we were going to be ready for something in a month, I would start the conversation with that other team, two months in advance, or maybe like a month and two weeks so that they had a little bit of question time and let them know that we need this. And oftentimes they were able to help us out. And what I would mention is that we, you know, if we were either interfacing with another system or getting data from another system or something like that. We would, we would set it up so that we could actually deploy our code out to production that actually would interface with those systems. Either behind a feature flag, or it would just be toggled or it would have some sort of dummy response or dummy request that we would put in there that we could then when when the other system was ready we could just toggle it and and and make it live essentially so we didn't really have to have to say oh they're ready now let's you know now we have to go and deploy something or anything like that was it was just on demand. Another thing about like dealing with teams with dependencies. Sometimes you have to be sometimes you have a dependency and there's nothing you can do about it you know it's just the way that it is and and you're stuck but sometimes when we would find a really painful dependency that would force us to think about solving the problem in a different way. So we as a team were, you know, we were pretty good and not being completely fixed in all of our solutions. And if we had the opportunity to think about things differently and make, you know, make the work easier for everyone involved we would, we would pivot and try and find a way with fewer dependencies and a path of less resistance. All right, so we've got about I think five or so minutes for the next little section here there's only a couple, a couple slides so we'll try to get through these. We have two more minutes. Two minutes. All right, so one minute first slide so here we go. Things we prioritize over process. All right, so we, you know, this is part of the agile manifesto individuals and interactions over processes and tools. And I feel like where the agile community has gotten these days is really emphasizing processes and tools and tried to get away from that. So the first thing that we prioritize is establishing routines. We talked a lot about not having processes not being formal, but we recognize that it is important for the team to find a rhythm. And also to come to work every day and know what to expect. No one wants to be thrown into surprise or chaos and you know not know what's coming at them every day. So we found a rhythm as a team and we found a way to establish, you know, like habits as a group, so that we got used to doing the same thing every day. We valued direct challenges so you know is this the right thing to be doing, you know, and saying it saying you know what this isn't working the way we're doing this. And you know did you think about this you know, and and not holding back and just kind of just doing what somebody said we have to do them. We really came out and said hey, you know, this doesn't seem right. Are we sure this is what we want to do. So that was a that was a value. We talked about this a lot we prioritized communication so we wanted everyone in the product process engineers designers POPMs to be communicating and having conversations. So as often as we could to make sure that we're aligned. Everyone has access to the same information and everyone was on the same page about what we were doing as a group. Okay, not getting too far ahead of ourselves so this is again some of the stuff we've already talked about we tried not to, you know, plan work out so far in advance that you know we ended up planning work that we're not actually going to do. So we're really just, you know, doing a lot, you're really taking the, you know, kind of pull system and you know just in time type of philosophies to art. And then we also value everyone in the product decision process. So, engineers, product designers POPMs we all had equal say in the way that we were thinking about moving the work forward. So that's easy on ourselves and our teammates, you know, there's, you know, how many times you've been on a team where it's like, oh yeah, this is this annoying thing we have to do every time we want to start the server we have to do this blah, blah, blah, blah. And there's all this annoying process and you know, whatever it was, anytime there was a lingering irritant we would just tackle it and say hey let's just get rid of this let's write a script make it easier. Let's get rid of this meeting whatever it was, we wanted to make things easy on ourselves so that was a big value that we had. And just some of the outcomes that happened as a result of this whole process that we had. There's only like three things or four things out here so we're going to go over our little time for a second so go ahead. Yeah, so one of the things this way of working enabled us to do is to move forward as a team and unknown territory so we were a newly formed group. We were working on new product and not being so bogged down with the way that we're able to do things, allowed us to just kind of find a path forward and analogy. Yeah. And then it also allowed us to be happier as a team like we really liked working in this way together. It allowed us to even virtually bond together. And we were really happy with this type of work, even just last week. I jumped into an engineering huddle and the engineers were like, actually they messaged me they had a question and they said, will you please join our happy huddle. So, like, I think we have a lot of fun together and we like this way of working. Happiness is an important method. Yeah, it enabled us to do continuous deployment and continuous delivery so work would just come in, we would get it out to the customer and just continuously deliver that functionality we're always ready ready to release to our customer whenever the customer when we're ready to release to the customer whenever our product owner was ready. And also lower cycle times, we just were able to just get work through a lot faster, not having all the extra meetings and so on. That's it. Thank you very much for coming. Thank you, Nayan and Julia. It was a wonderful session.