 Great. So, oh no. Great. So a little bit about me. They're going to start it here. This session is the traffic policy. So a little bit about me. On the one hand, I kind of have this dual role, which is pretty exciting. I help organizations figure out what problem we're trying to solve, who we're trying to solve it for, and most importantly, why we're trying to solve it. But on the other hand, I have this great little thing that I do sometimes where I help teams kind of explore and experiment with different ways of working together. I help focus on bringing agile and lean values and principles into action on those teams to help reduce some of the friction that can be found in software development. A little bit about the organization that I work for, Last Call Media. We enjoy doing work with Purpose and helping build engaging tools that support the communities that these organizations support. So I had an interesting thing happen to me. I was sitting in traffic, this rare event, and this was a little while ago, and I thought to myself, wow, why is this still a thing in 2018 in certain cities? It just keeps getting worse. It never seems like it's getting better. So I googled it while I was stuck in traffic in an Uber. What is the worst traffic in the world? And it came across this pretty interesting story. In 2004, Houston, Texas, and many cities, had a major traffic problem. It was essentially taking too long to go for these vehicles to go from A to B. And it was a city experiencing massive population growth, and its roads hadn't really caught up with the increase in population. So this meant traffic just kept getting worse. So the Katie Freeway here, anyone here from Texas? Anyone here from Houston? Cool. There's this interstate 10. I've never driven on interstate 10, but I'm imagining if I did, I'd get stuck in a lot of traffic based on what I read. So it takes you from downtown Houston to the west, 30 miles, and it takes about an average of 41 minutes to go those 28 miles from downtown Houston to Katie Land. So recognizing that that was a totally undesirable state of affairs, the American Highway User Alliance, which is a group that I learned about, published their findings after they explored the reasons behind the traffic issue here, and they determined that this freeway was the second most congested road in America. So they calculated this in hours that about 25 million hours are wasted by people sitting in cars on this freeway. And when you're sitting in traffic behind the wheel, you're not working, you're not taking care of your kids, you're not adding essentially any value to your life. You're not helping move any of your goals forward. So just out of curiosity, if you divide that by the average hours in a lifetime, that's 40 lifetimes a year. So with vehicles per day increasing with population growth, this delay would more than double. So this study was conducted, they determined that this was only going to get worse. And then when you put a dollar amount on this massive delay, some simple math, let's just assume here simply that every rider has the opportunity on average to earn $20 an hour doing pretty much anything else besides sitting in traffic. So when you multiply that by those number of hours, you get about half a billion dollars a year and lost opportunity. And then you have to add in all sorts of other indirect costs, increase fuel charges, babysitting costs, shipping costs, etc. The number just goes up and up and up and up. So they recognized that this was just not desirable and they worked to solve this problem. So the Highway Alliance conducted further surveys and they concluded that bottlenecks caused by too many cars on too little road are to blame for about half of all traffic jams, right? Traffic accidents, work zones, bad weather and poor signal timing account for the rest. Okay, cool. We can fix that, right? Bottle next. The other half appear to be random, can't do much about those, unavoidable and unpredictable. Conclusion, too many cars, not enough freeway, sounds pretty logical. Extra capacity, I'm imagining this room with a bunch of really smart engineers, extra capacity would surely solve this problem, right? A reasonable person in that room. More lanes would mean more room for more cars which would mean shorter travel times. So therefore, let's get our shovels and let's build more freeway. So the state of Texas spent 2.8 billion dollars to widen the KD freeway to 26 lanes. That has a tremendous amount of capacity. 26 lanes, obviously in certain parts, not the whole thing, but still that's an astronomical sum. But there's just one little problem, right? Congesting on the KD has actually become worse since that expansion, right? Travel times have increased 55%. It's gone up to 64 minutes to go to those 28 miles between downtown Houston and KD land, from 41 minutes in 2011, right? So it wasn't interestingly enough the same amount of cars, right? As the road increased, the number of cars also increased. People saw the increase in capacity and thought, now I'm going to use this highway that was previously too congested, right? How could this be? This kind of flies in the face of common sense. So they went back to the data, they ran more models and they thought okay, wow, it wasn't the same amount of cars. So we're still stuck with that tremendous amount of traffic. Now I know, I just talked quite a bit about Houston, but I'm sure we all know this is a problem all over the world, right? Here's a 50 lane highway in Hong Kong that brings between Hong Kong and Macau, right? This is just one summer day. That just looks like a mess. But you know, this isn't intentional, right? For all we know, highway engineers have been saying this for years. The problem is not to add more lanes, right? But you know, politics, elections, big infrastructure projects really help. So you add more lanes, right? But the real challenge I learned during this exploration for city streets is to move people, not cars efficiently, right? It takes a little bit of a mind shift because you think people are in cars, right? But people can go from A to B in a wide variety of ways. There's public transit, there's the car itself, there's a bicycle, et cetera. So in thinking about this, you know, in the context of Agile and Lean principles, despite capacity increases, there are just too many, perhaps, vehicles in progress, which means continued high road utilization with leading to high throughput times and idling vehicles, right? Some people may be familiar with like Kanban thinking and limiting work in progress right now and some of this stuff tied to traffic. So when the freeway is full, there's no slack, right? There's no space on the road to allow for the inevitable variations in vehicles, right? Vehicles are different sizes, we all drive different speeds, we all have different driver confidence, different skill levels. Some people unfortunately still text and drive, lane merge aggressively, et cetera. And then you have to factor in accidents, hazards, et cetera. So perhaps instead of increasing the amount of road and spending close to $3 billion, right? Since we can't control the variation in vehicles, right? Maybe if we limited the number of vehicles on the road at any given time, we could create slack or space. So I think congested freeways need a vehicle in progress limit. And cities, coincidentally know this too. Cities like New York, notorious for its traffic, focused a lot over the past year or so on reducing the number of vehicles on the road, right? Through congestion pricing. And yet, timely, as of last week, you can't see the date, I guess, but on March 31st, the state legislature dismissed congestion pricing and said, we'll figure this out another way. No go. Stockholm just quickly here had a unique challenge. Rapid population growth, but as an island, much like Manhattan, linked by tunnels and bridges, was geographically unable to add more roads, but had rising congestion. So they set up a sandboxed six-month experiment and set a $1 toll to enter the main city, hoping to reduce congestion. And people hated it. It was fiercely political. People just were outraged. But when people saw what became some interesting data, it quickly became permanent. It became faster to get to where you needed to go, right? People from A to B. And when you got there, the air was cleaner. So the number of people in Stockholm and transit didn't decrease, just the number of vehicles. So all that. What about our freeways, right? We have our own politics, but fortunately for most of us, we don't have to deal with the state legislature to navigate and try new things, right? But how many of us have looked at their backlog and thought things are taking forever and nothing is getting done, right? Perhaps, you know, speaking from a little bit of experience here, take a look at a long list of things and it just seems like people are working really hard, doing their best that they can, but things are just kind of taking forever as a feeling that we have. And then on, you know, who thought? Very much like me. Well, maybe we need to add more people, right? Bring more people into this. More things will get done quicker, right? But then who also perhaps had a team member or many team members with greater than one thing assigned to them at any given time, marked as in progress, right? So this was speaking a little bit from our experience and our journey here. This is what we were struggling with, right? We found that everyone was incredibly busy and working really hard, yet value, the things that people were paying us to do to get things into production for their customers was taking too long to get there, right? People had just way too much on their plate and others perhaps with not enough looking for more things to do. Tasks were sitting around in unknown states, waiting for people to become free and finally work on them. And it was stressing people out as well, right? Seeing things assigned to them, the number of things assigned to them always increasing and the number of things that they're getting to done just seems so far away. So we learned, right, much like this freeway, that differences in task variation, right, not all tasks are the same, not all people are the same, makes it difficult as an organization to provide scheduling predictions as to when something will get done. So to maintain a positive customer experience for the organizations that we work with, secondary needs were created as tasks waited, right? So from the business perspective, we had to have people pretty skilled at navigating difficult conversations to help explain things like why things were taking a little bit longer, when things would be done. So when they're having those conversations, they're not really delivering any value. There was a way that we could perhaps consider avoiding those conversations. So, right, the difference between adding a blog feature is a lot different than say running security updates, right? And what this ends up being is superfluous work, non-value adding work created to satisfy customer needs. So we were coming from a very command and control management technique, right? You're looking a little light today. Let me give you a few more tickets, right, as a project manager. I'll just make sure that you have a lot of tickets signed to you. That's what I'm doing, right? You sure that's enough? Let me give you a little bit more, right? You can always just select the name and the drop down and click save and just add it to their list. So I think a lot of that comes from traditional management literature, right, that says people need to be 100% utilized in order to get more things done. So the goal of project management was to make sure, based on the literature, that everyone always had a full plate of work. But then we kept asking ourselves, is being busy and delivering value with predictability are those things mutually exclusive, right? Can you be super busy and also have some things done with predictability, right? But, you know, we don't have billions of dollars, like to say to Texas, so we can't build more lanes just like that. So how can we work with what we have, with the tools that we have, with the team that we have, the people that we have, the skills that we have, and try new things? So we experimented with what would it look like instead of focusing on keeping people busy. We focused instead on delivering work to the customer as quickly as possible. And, you know, another way, perhaps more fun, of saying this was how do we put our good ideas into action quickly, right? An idea is essentially just an idea until you can test it in production, test the business idea of it, right? Not the code in production. Because that's our goal here, right? The whole point of all this is to work at a sustainable pace to get our ideas into production quickly. So we experimented again with three things. Very much out of the Kanban literature. We worked to visualize our process in a common place, move outside of electronic tool. At the time, we were fortunate to all be in the same office. We had great walls, so we could think about, you know, using those white boards and limiting our work in progress and working together as a team to improve the way that we work. So none of these experiments involved making people work faster, making them work longer, or making them work on the weekends. So the first step, visualizing our process was pretty easy. We moved from, at the time we've been using a combination of electronic tools to a physical board with columns that represented the different work states, right? This created a really great opportunity for the team to have that high level visibility to see what's in progress, who's working on what, right? But also who is too much, who's too little, where are there opportunities for knowledge sharing and learning, right? Working people essentially help each other when you're all having that conversation in the morning, right? Are there any bottlenecks? Is just a lot of work kind of piling up in one column, or is a lot of work piling up on one person, right? With too much, you know, with the bottlenecks you can discuss it, can we do anything about it? And then it also kind of exposes this hidden work, right? Where something's in progress, because your project management tool says, you know, ready, in progress, and done, right, a very simple version of that, and it's in progress, but really in progress can mean like eight different things based on where it is and who's working on it. So you can sort of find those things and represent those as a column on the board, if that makes sense. So the second thing is always a challenge we've found, right? How do we limit our work in progress? Because I think as a team, people really want to do their best work, and they come to that daily stand up ready to do whatever it takes, right? But we have to ask ourselves, and ask myself this every day, how many things can I really work on at one time, right? It's really stressful to try and actively work on many things at once. It's easier to get distracted, it's easy to lose focus, and decide perhaps ah, maybe I'll work on this tomorrow, just speaking about myself. Again, when you limit your work in progress, these bottlenecks become clear, and the team what's been really cool is that the team kind of talks amongst themselves, they self-organize, and they figure out what's in progress and who's working on what, one thing at a time. So how do we come up with these work in progress limits, these whip limits, from observing the board, right? I think to take this idea back, you could throw out a number to the team, talk about it as a team, but just throw these numbers in the column and then make sure that you have those opportunities to monitor so as a team, how these whip limits are working, are things getting stuck, are too many people idle, observe the flow of work, and then talk about it. So we have these things called a flow unit, which is essentially just a card, right? And these are the things these represent the actual task itself as it moves through the queue and you can represent this flow unit in a number of ways. For us, we use JIRA pretty heavily, so we have a JIRA ID that ties back to an electronic system. The due date, just so quickly, you don't want to be able to look at this task and know everything about it, but people should be able to look at this card and know what it is and where to go for more information. Getting started, pretty simple, right? We take a list of our work, we prioritize it based on its business value, that's a backlog, right? In a very simple sense, and the team works from the top of the list to the bottom of the list, and they self-organize and figure out how to pull the work from one column to the next column and through that queue. So simple stuff, I'm sure folks here are doing this. And, you know, as an example, here's our board of cards, right? In my life, it's simple, right? It matches some workflow, that's just me working on stuff. I don't need much of a traditional process. It's going to be a board in JIRA, it's going to be Trello or whatever. But before we were distributed, we had boards a little bit more complex than this, obviously, for a team because this is just me with my one thing in progress. So in this example, I'm visualizing how my work is done. I hold a daily stand-up with myself, and I pull tasks from to-do to doing, and then from doing to done, kind of one direction, right? And then I repeat the next day, right? And since I have a whip limit of one, I move one 34 to done, and then I grab another, because I promise myself I wouldn't leave work unfinished. That's important to me because I feel that unfinished work is useless. So agreeing that it would only work on one thing at a time, I kept starting things though, and, you know, there's this problem here. I'm really busy. I've got a lot of things that I'm working on, right? But why is that a problem? Nothing is getting to done, right? Nothing's getting to the customer. Nothing's delivering, really, ultimately, on the business value that we are hoping to get into production. But on more complex projects, right, with more people, our boards may look like this. In this example, as a something that the team decided that made sense for them, not all boards need to look like this. There are whip limits, right? So you've got Analyze here with a whip limit of four, but there are three things there. So that's okay. You've got things in testing. There's a whip limit of five there, but there are four. So kind of a pretty healthy board. The team may feel, hey, in that daily stand-up, I think what I want to do today is help get rid of some of these things that are user acceptance testing, right? Let's move those through because I know that we've got quite a bit over here, you know, Insective for Development and Analyze that will be coming through. What we don't want is to be in a situation where we've got a bunch of stuff in progress and we can't move it into testing because we've got that whip limit there. So let's focus. How can we together as a team move things from user acceptance testing into Ready for Deploy, right? So the team can kind of perhaps swarm on that and then if there are things that just keep getting stuck, that's a great conversation to have in a retrospective, right? Or depending on how you're working, you may, the team may feel like they just want to talk about why things keep getting stuck right then and there if that's a productive conversation. So when the entire team has visibility into the work, they have opportunities to help each other figure out who's the best person to do what, right? Because the best person to figure out whether or not a task is appropriate for them is that person rather than someone else deciding and then assigning that person that task. So it's a conversation. And this helped us by doing this improve another issue which is that some folks had too much on their plate and some folks not enough. I think that may just be something that we'll continue experimenting with and looking at but it is still something that we're working on. It's improved. And of course things go from to do to done, right? And that's kind of what the team decided that it makes sense for things to go in one direction. So this thinking, right? And a model here to represent that, we're asking ourselves who's kind of adapting to who, right? And the traditional approach for resource efficiency approach where you want 100% people to be busy 100% of the time the team member is always busy. The flow unit does a lot of waiting, right? It's sitting, one team member has three things assigned to them. You put a camera on the shoulder of the team member of the developer or whoever it is and the camera is always busy, right? They're running around, they're crazy, they're juggling a lot of things, right? But since we agree now that only one flow unit can be in progress at a time, if we flip that, right? And we put a camera on the team member's shoulder again. The team member may have some slack, they may not always be busy, right? But that flow unit that work itself is constantly busy. A camera on the flow unit shoulder would show that that flow unit is just moving straight through as quickly as possible, right? And that's kind of what you want. That's the objective is to get the thing itself the idea from one end of the queue to the other. So flow efficiency, there's this great book called This Is Lean, I highly recommend it if this is of interest. And it argues that flow efficiency is an operational strategy, right? Not a business strategy. It's the sum of all the value-adding activities in relation to throughput time. So okay, cool. What does that mean? So flow efficiency is the value-adding activities or things like development, creative, perhaps project management, testing. Those are value-adding activities, right? They contribute to increasing the fidelity of this idea as to something that goes from perhaps a few words and a user story into something that's sitting on production versus the throughput time, right? Which is how long did it take from when that ticket was created or that sticky was written to when that idea got on production? So as an operational strategy, what we want to work toward as an organization is reducing the non-value-adding activities like flow units waiting, waiting for testing, waiting for a wide variety of things, right? What this doesn't say is make people work faster, make people work harder, make people learn more, make people work on the weekends. So as an example here, as an administrator, right? I want to be able to enable site-wide notifications. Perhaps I'm a school and there's a snow day. So visitors can see important alerts and changes to the schedule in this simple example, right? So the value-adding time, time spent with creative and development, 8 hours, right? Those are perhaps in an agency setting or if you're in sort of a cost-recovery situation, that's the amount of time that you can bill for, right? But the time period, how long was that in your queue? So it took 120 hours, right? Divided by 8 in the number of days. So you can calculate what your flow efficiency is here as a measurement being 6.6%. And then let's take the flip side of that when you're focusing as an organization on flow efficiency as your operational strategy. You're evaluating time, still the same, 8 hours, but because you built Slack into your system and people are pulling tasks to them rather than having things assigned, and you're limiting your work in progress to 1 and you're visualizing your progress as a team, your workflow as a team, it really took 24 hours, right? Less than a week to go from when the idea was initially created or had to when it was live on production. So your flow efficiency there is 33.3%, right? What does that even really mean? I don't know if, and looking into the literature, if there's really such a thing as the target flow efficiency, right? Considering the variation in our work, not sure that it even really matters, but it's, I think more of an exercise in measuring it, right? So you can then in a retrospective discuss as a team, hey, you know, every time we seem to get a task like this, things, you know, is there a way that we could perhaps adjust the way that we work to get this through faster? Like, where does this kind of task continue to find itself getting stuck? And can we do anything about it? Right? Because measurement, when you have those opportunities, is kind of a great way to know if you're improving as a team. All this possible because we, you know, we haven't eliminated traffic jams, right? In our workflow we just now have fewer. So when do you start that timer? When does it end? So when it comes into do, right? It can kind of be sitting there not adding any value. But the timer starts when the thing is real, right? If you're an organization and you need to get approval on certain things, right? So whenever it's approved, whenever it's ready for the team. Whenever the team can take it and go with it. Pluses are your value added time. The X's are when an item is in that state, it's not really adding any time. So you want to get something from those states through as quickly as possible. And the team can look at this and reflect on it on a day to day basis and then again in something like a retrospective. So another thing is we talk about visualizing our workflow and we talk about those little flow units, right? Just like how you think twice about driving down a road like this, your queues should also be road worthy, right? Accidents can happen. Queue hygiene is essential to flow efficiency, right? When you want to put good ideas into action as quickly as possible, the road needs to be clear, right? You can't go, or at least I wouldn't go 60 miles an hour down this road. And then when it constantly looks like something just exploded on the road, you'll waste time as a team navigating around that mess. So true retrospective format on a high level. What stayed the same about how we worked, right? We didn't change everything, right? There are things that were in place that made a lot of sense to continue doing, right? What was great is we didn't really spend an extra dollar. We had everything that we needed already as a team. And on the flip side of that, we did change a few things. We switched from, or continuing to switch from a more resource efficiency approach to more flow efficiency. We, team members are now working with the work rather than being assigned the work. And they pull work to themselves rather than having it be assigned. So retrospectives are, I think, one of my favorite pieces about working on teams in general, right? You're a team, you're trying to do things, figuring out how to work better together, what's working, right? And what should change or what should we consider changing. So there's this great text for folks who are interested in, you know, different retrospective activities if that's more your way of an ice breaker in this type of conversation. But, you know, as a team matures, sometimes you can just get right down to it, which is great. And she provides an outline for a great way to do these retrospectives, especially if the team is new and forming. So what did we learn quickly here to summarize? Start with what we have. People, tools, space, skills. Prioritize our work. Visualize our process. Limit our work in progress. Hold retrospectives, because those are how we improve as a team. And we focus on delivering value to customers faster by creating Slack in our system. Agile and Lean, these values and principles, everything we've been talking about are all about experimentation and learning. There is not a one-size-fits-all model that you can take on one team and perhaps deploy to another team. Just a bunch of concepts and ideas and the open mind and remaining flexible to try new things. And enjoy the trip. And oh, if you're around on Friday, you should join us for some contribution sprints. I never know if this should go after, but regardless. And true spirit of what we've been talking about, feedback would be greatly appreciated. I think there's an opportunity to do that on the session page on evaluation. Things that were helpful, ways to improve this talk in the future would be greatly appreciated. And now, if there are any questions, I'm more than happy to talk about things. So the first thing that we did was we kind of needed to take stock of where we were and how things were working by visualizing it. And then the next thing that became clear is that people had a lot of things assigned to them. So we encouraged folks to try perhaps just moving one thing at a time and having that be the thing that's assigned to them. But you're right, as a team, there may be five people on the team. So is your whip limit five? Is your whip limit four? Or is it six? It's really just about trying one thing. And then if folks don't have anything to do because you came up with this arbitrary number, you can be flexible and change that. So I don't know if that totally spoke to your question. On the back. On another team? Perhaps. Yeah, so you could do, well like, was that dependency known before that task got pulled through or is that something that got learned? Okay, cool. So that, when we've seen that in the past, you know, you may, if it gets pulled, well it's not ready, I guess it does have a dependency, right? That wouldn't make sense to pull that through and then kind of leave it hanging out there. But if you didn't know about it and you learned it, you know, one of the things I think is important is the flexibility. It's like, okay, well we know what the situation is with this one particular thing. You know, we don't like leaving it here, right? It's now the right time to talk about why that's still here. Can we move this? Perhaps we need to represent the fact that there's this dependency as another column. But the team, and they were talking about organizational dynamics, right? You could be pulling a bunch of things through and then something just keeps getting stuck. So that would definitely be something that I would prioritize as a conversation. You know, is the person who did that, should they be part of the team? Or the person who's the dependency, if it's a person, should they be part of the team to help remove it? And encourage that to move forward. So that's one of those working agreements that, you know, when it happens, the team could talk about, hey, are we alright with leaving this here? Right? Is it something that's going to be resolved by the end of the day? Or is it looking like it's going to be three months from now when someone gets around to resolving this? But true to the point of Q hygiene, you don't want things hanging out in that state for, you know, an infinite amount of time. So if it's looking like, hey, we got something to work in progress, someone did 80% of it and they realized, oh hey, there's this key thing that's going to take three months. You know, the teammate decided, you know what, let's just abandon this task, right? Let's just throw this into the done column, but document why we're not doing this anymore. But again, that flexibility to talk about, hey, it's going to be done tomorrow. We're okay to leave it here. We're flexible. And then talk about it that next day. And is it still there? Right? What do you want to do about it? Yeah. So it sounds like you're in a situation perhaps where you continue to find yourself taking tasks that maybe they're ready, but then when you move them through, you find out and you realize that they're not ready. Or like there's a dependency that keeps getting blocked by something else. And is there an opportunity that you have to do perhaps a quick discovery on that task before you move it to in progress would be one thing I'd look into. Or rather, move it to in progress but have it as a discovery before it's actually the task, especially if you continue finding yourself in that situation. But perhaps also are you alone on this team or are there other people on this team? Okay. Because if there's like one thing that's worked is if there continues to be that same dependency from another person in another part of an organization, perhaps one idea would be to see if that person could join that team. Just even in the mornings for the stand-up to help prioritize their day. But that takes, speaking of politics, that could take a whole lot in some organizations. Oh, totally. Yeah, it's not a hard, fast rule, right? We got to remember that dogma can be really difficult. It could be demoralizing to a team if we approach this thing with those hard, fast rules. It's that flexibility that we're all humans, right? And that we're working on things the best that we can. And sometimes we need a little bit of a break. And that's okay, right? As long as we're all talking about it as a team. And definitely been in those couple different situations like that where someone's like, hey, I really want to break ground on this, but I'd like to wrap my day with this or something like that. And I think kind of where we were coming from was people had you know, there's this one joke we used to tell you, just assign it to this person, right? Because they already have like 90 things assigned to them, right? This is many, many, many years ago. And it just added to this person's list, right? And you'd add it and the person would get an email. It's like, okay, one more thing. I know I've got job security for forever now. But it's going from thinking about how to help teams go from 10 or more things assigned to one person at any given time to two to one or two and being flexible. It's a great question. I'm chuckling a little bit because that's exactly we had to deal with that for sure, right? And it'd be great to talk more about that too, kind of sidebar if you'd like. And how we address that. But just kind of high level is true to the limiting our work in progress and working at one task at a time. We found that it made sense to have a team work on one project at a time. So then you have the ongoing support. You built this amazing Drupal 8 site. You shipped it and now six months later, wherever that organization is, it's back with this feature or this enhancement. And you're like, oh, well, the best team to do that is the team that built it. But they're already on to the next thing. So how do you handle that ongoing support? So we actually rolled out what we call the SLA team, the service level agreement team. And they're a team that we don't schedule on bigger projects. So all that they do is they have a daily stand up where they review all the ongoing support requests and a queue system that we're working on. But I essentially know those things come through. That team, I think it ranges from three to five people at any given time. But the key point there is that they're not committed to any deadlines on any other projects. So when those tasks come through, they can pull them through. And it's kind of interesting as a business model, right, because you essentially then may have people on any given day that may not have anything to do. But you're building that slack on that team so that when those things do come through, you can pull them through quickly and you're not interrupting someone who already has a bunch of other commitments. Do you have a question? Yeah, it's different teams. We like to make sure that there's a different amount, there's like a range of skills. It's a multidisciplinary team. So there may be a tester on this team, for example. Someone who can take all these user accepting tests. User acceptance tests. And make sure that they match the original criteria, right, and then pull those over to ready for deploy. So I've been thinking about this more as a team that has that's fortunate enough. Oh, right. So like what, how does the person who's working through that queue represent the work that they have in progress? So the L look, there's a ticket rating over the end. Yep. So people have to, you know, that's always the priority, the closest to done. That's great. And do they switch like when they get the signal that it's ready or do they switch that next morning because they're working on something? Yeah. I mean, that's a great question. So it could be, you know, the team could look at this and ask that question and say, hey, how are you going to move all these things through in that daily stand up, perhaps. And maybe people are going to say, hey, look, why don't we as a team get all these out of the user acceptance testing, right? Good to have different people testing each other's work and get those things ready for deploy. That could be a conversation that they have in the morning. But, and then, oh, I don't know how big this team is, right? So there could be, in this example, five people on this team and two people that morning may say, hey, in this hypothetical, right? Hey, I'm going to, let's let's just crush these UAT tickets and someone else may say, okay, well, I want to pick up this. This could be either a pre stand up or post stand up representation of this team's work. I don't know if that, are you on this team? I'm imagining your daily stand ups and you're talking about things. And are you finding that things get stuck? No, I just think we actually limit it a lot more than that. Oh, cool. And as a team, what's the team think? They are all on board with that idea? Yeah. Okay, cool. Any other questions? So this is just, sorry. Yep, on some projects. Yep. So we have several different ways of working and when it makes sense, we can do those two week sprints or whatnot with your planning meeting in the beginning and your reviews at the end, if we're all familiar with that. So perhaps in your planning meeting, this may not be all the work for the team, for the whole project, but this is just a quick snapshot. There may be a product development team that's working on requirements, gathering feedback, etc. And they're managing things kind of, their workflow is, they may have a board like this, but it's not part of what the development team is working on. So in this example, in that planning meeting, they may review all those tasks, right? And then obviously as that prioritized list and then pull things to do and prioritize them there and that's the planning meeting, the things that are to do. And then in the review, obviously you have all your things that you're talking about and done. But this workflow would exist inside the sprint. Cool. I think those were all the questions. Thank you everybody and we're doing great on time. I'd like to usually do that for planning so that we can better estimate the tasks for the story. Yep. So like in this example, this was maybe an ongoing support team. So the to-do list is just all the tickets that have come in. And then, you know, the team doesn't want the timer, the team wants the timer to start when the ticket comes in.