My talk today is going to be about fast and furious withdrawals from optimistic roll-ups. A little bit about myself, my name is Messa and I'm a PhD candidate. I'm doing PhD at Concordia University with Jeremy Clark in Montreal and I'm also integration engineer at the off-chain labs. Alright so what I'm going to talk about today is research that I was doing during the PhD and it kind of co-located with the time that I was doing the job at the off-chain. So it's kind of a collaboration between the folks at the off-chain and Concordia. So it's a research, we are particularly interested in solving a research problem but before I dive into the details of the problem I want to take some time and talk about how roll-ups work in general and how optimistic roll-ups work. So you might have already heard from other folks during the conference but it's always good to keep refreshing and make sure everybody is on board. So let's start with the question of why is the theorem slow and expensive? So we know a theorem is slow, there's unscalability problem with the theorem and it's really a fundamental issue and why there is a problem is that let's say you have a function that you want to get executed on an input X and if it was a cloud environment the cloud service provider would give you the closest node in the network and then what happens is you send the function to the node it would execute the function for you and it would give back the results and you learn what the result is but on the blockchain because we care about trust and integrity we can really rely on one node to execute everything for us. So what happens on a blockchain is you send your function to a node and what that node does is actually relays your function together with the input to all the nodes in the network and what happens is then all the nodes in the network execute your function. So it's literally like you have to pay for each and every node executing the function for you and then it takes some time because they have to run a consensus algorithm among each other so that they could all agree on a same output and it's only that moment that you can learn the result. So that's really why it's so inexpensive. Okay so but why is it that every node has to compute everything? So the answer is because they have to make sure that it's the correct thing. So let's say I have a function I execute it for you and then I come to you and I'm like here's the output. So what is the most straightforward way for you to actually verify if I'm saying the correct thing? So you have to go and compute the function yourself right? So the question people have been asking in terms of scalability of Ethereum is that is there any way I can convince you that I've done the execution correct without you having to go and execute everything yourself? So there are two main approaches to tackle this problem. The first one is you can actually throw some math at a problem and you create kind of a mathematical proof.  You hand it to me and then I can actually verify the proof and see if it's a correct thing or not. So very if like verifying the proof is less work than actually having to execute everything then I actually save some money and time right? So this is how ZK roll-ups work on a high level. So the way a ZK roll-up work is you actually send a function to a node, the node would execute it for you and then they create a cryptography proof saying that this is a correct output. Now generation of this proof takes a long time. It even takes like thousand times or even million times longer than when you have to like compute a function yourself. So that's kind of a hidden cost. But if like once you have the proof in hand you can actually go and send it to the network and then verifying the proof is really nothing. So it's really a cost effective solution especially if you're one of those nodes that have to verify those proof. And the second solution is to use kind of like economics. So I'm like I execute this function and here's the output and here's a million dollar worth of ETH backing my assertion. And it's open for you to dispute. Anybody can come along and they can prove that it's a wrong output but they have to stake money as well. So the way it works is let's say Alice is saying what output is right, Bob is saying the other output is right and then there's a dispute and disagreement right? And it's only in that point that Ethereum goes back to a normal blockchain mode where every node has to execute everything. So this is how optimistic rollups work and we call it optimistic because we're really optimistic that not every node has to compute everything because really nodes always assert the right output and you see why. So the way an optimistic rollups work is that I execute a function and I put an assertion, I stake on that and let's say Bob is coming and he says this is the wrong output. So he finds a dispute. So what happens is Ethereum would be like hey I know you guys are disagreeing on this output. I want you to pinpoint me to the exact step inside the computation where you started to disagree. So maybe you were fine for the first 30% of the computation and it's only this little step where you started to disagree. So it's actually going to verify that little step. So it ends up being very cost effective even if Ethereum has to step in. And that's why actually it's really not easy to get away with a wrong output because everybody knows that at the end of the day Ethereum can come along and it can settle things and you can lose money. And then yeah and then that's why actually the only way you can get away with a wrong output is that nobody's watching the protocol. So at least one honest party watches the protocol then you can never get out of it. Yeah and yeah this is how optimistic rollups work and like in real world it never happens. The dispute like in arbitrum there's never been a dispute before. So let's say let's see how it works on arbitrum on a smart contract level. So what happens is arbitrum puts two smart contract on the L1 inbox and outbox and what Alice does is she wants to execute some function right. So what she does is instead of putting the function on L1 and having the L1 to execute everything she puts a message saying that I want this function to be executed on layer one. And it's only the inbox contract is going to record the fact that Alice wants this function to be executed. So what happens is somebody outside L1 comes along they dump the contents of the inbox smart contract on L2 and then they're going to execute everything on the RBOS and it's really based on like the how they were sorted inside the inbox smart contract and then they're going to update everybody's account on the RBOS and then they put the output of this execution inside the inbox smart contract in the form of an assertion. So an assertion is basically a fingerprint of the latest state of the RBOS. So it doesn't care what is RBOS or how RBOS works. It actually works a lot like Ethereum. It runs a blockchain. It has blocks. It has miners. We call them validators. It has block explorers but Ethereum doesn't care about anything about that. It only cares about like here's the list of function that I'm seeing that are going to be executed on layer two. I want to see the output of this execution. That's all it cares about. So we have to wait for seven days because we want to make sure that everybody have time to come along and they react to it if there's any dispute and if there's not no dispute it's going to be finalized. So let's say Alice wants to do something slightly different this time. She wants to withdraw 100 ETH from L2 and to make that happen, Arbitrum has to introduce a smart contract which is called bridge. So bridge's job is basically to scroll whatever tokens or ethers people want to move to the L2. So if Alice wants to withdraw 100 ether from L2 it means that she has previously moved 100 ether to the Arborus. So what bridge does is hey Alice I know you're moving 100 ETH to the L2. That's fine. Just give me 100 ETH. I'm going to scroll it for you and then I'm going to mint 100 ETH on L2 out of tin air. You'll be the owner. Do whatever you want. Go ahead transfer it to Bob. And the end of the day what I care about is somebody comes along and they want their ether back from me. And that's called a withdrawal transaction. So yeah. So like any other transaction I just described Alice puts a message for the withdrawal transaction inside the inbox and Arbitrum does it things. So yeah somebody dumps the contents of the inbox on the Arborus. It gets executed and then the assertion would be placed inside the outbox. Now we have to wait for seven days so that we make sure that the assertion is finalized and our withdrawal transaction can go through. And only in that case when it is finalized Alice knows that her transaction is in assertion number 20. She can go to the outbox and she'll be like hey outbox. This is the assertion. It's just finalized. It's sitting there for you to go and see. Go check it please. And then if you're happy with that I want my 100 ETH back from the bridge. So outbox is happy. Bridge would give back the ether to Alice and then it's going to burn those on the L2. So here's the problem. I'm sure you've noticed. Withdrawals take seven days to be finalized and it could be even longer if there's any dispute. And although there's never been a dispute before but there could be and people really don't want to wait for seven days. Sometimes they have a pressing reason. They want to really do something with their ether but intrinsically you don't want to wait. And then seven days is just really an arbitrary number but there should be some time window for people to pay attention to the protocol and react to it if something happens. But something interesting that we notice is on Arbitrum let's say there's an assertion that you're just looking at it for the first time and you're trying to figure out if it's going to be finalized or not. So if it actually happens if you run a validator on Arbitrum what happens is what is validator? It's just a software that goes through the inbox transactions one by one. It's going to execute those and at the end of the day it's just going to compare the output of this execution with the state that is being asserted. So if you run an Arbitrum validator you can be 100% sure that this transaction is really going to be finalized. The assertion is going to be finalized. So we found that this is really interesting that we can leverage to get a relief of this pain point of having to wait for seven days. So the question we were asking in this research is can Alice withdraw 100 ETH from L2 back to L1 without having to wait for seven days? So we have come up with four different solutions in this work and I'm going to go through them one by one and they actually get better as we go through. So the first solution is Alice can actually use centralized exchange like hop. So what she can do is she can go to the exchange, she can trade her 100 ETH on L2 with the one on L1 and it's really easy. So these centralized exchanges they have piles of ETH on both L2 and L1 and you can actually trade with them. So this solution works, a lot of people have been using it but the problem with that is it's centralized. So now we ask ourselves, is there any way we can do it in a decentralized way? And so that's where we go to the second solution. So the story is Alice is holding 100 ETH on L2, right? So if it happens to be somebody somewhere that has the exact same amount of ETH on L1 and is willing to trade that with Alice, then they can do something called atomic swap. So I'm not going to go through the details of what atomic swap is, but it's basically like a little bit of crypto combined with smart contract that allows you to basically do transactions on two different chains at the same time. So it's like, arbitrom here is a different chain than Ethereum, right? So it's like, both Alice and Bob, they agree on atomic swap. So they have to lock up some money. And then there's a secret somewhere that if it's revealed on one chain, then you can use it to send a transaction on another chain. So it's either like, either both transaction goes through at the same time, or they don't go through at all. So this is the beauty of atomic swap. So it's perfect, it works, but the problem with that that you might have noticed is that Bob can agree to do the atomic swap, but then he can just disappear in the middle of the protocol. So there's some time window for Alice to go back and get whatever she has locked up before. But it's actually very awkward, because she's not getting what she wants. And she's actually losing some time here. So we go to the third solution. So we're like, hey, Alice, we know that you initiated your withdrawal transaction on L2 and from L2. And then now you're waiting for your assertion to be finalized. What we can do is we can give you a ticket actually that says you are actually the owner of this hundred ETH, and then you can do whatever you want with the ticket. You can go ahead, you can transfer it to Bob. That's fine, even though the seven day has not passed. So so it's basically like we're giving a tradable ticket or a claim of whatever is going to go out of the breach after the seven days. And as I said, these are tradable, they can transfer it. So if Bob happens to be an arbitrom validator, it means that he can be sure if the assertion is going to go finalized or not. So what Alice does is that she can actually go to Bob and she'll be like, hey, Bob, I know that you're you're actually validating everything.  But what I can offer you is that I have this ticket that worth 100 ETH in seven days. So what you can do is I give you a discount or a bonus, you can buy my ticket because you know that this assertion is going to be finalized. And then you get the ticket, you get the ticket, you get the bonus. And then at the end of the day, you have profit. So Bob can do that is great. But as you may have noticed, Bob here is having two roles. So first off, he has to have the liquidity, meaning that he has to be sitting on a pile of ETH and he has to be willing to trade it with Alice. The other thing is Bob needs to run and a validator on arbitrom. So he needs some assurance. He needs to know that this assertion is going to go finalized someday. Otherwise he's not really willing to trade with Alice. So the problem, this solution is really great. But the problem with that is there's not probably a lot of Bob's in this world. So there could be some people, they have the liquidity. So they have a lot of ETH, but they're not necessarily arbitrom validators. Or there could be some arbitrom validators, but they're not sitting on a pile of ETH or they're not even interested in participating in these kind of like markets. They're just doing that because they want to be part of the arbitrom ecosystem. So that's the problem. Finding these Bob's that work for the both side of equations is not really easy. Okay, so we are at our last solution. So we were like, is there any way we can split Bob? So is there any way we can have Alice? She wants to withdraw 100 ETH from L2. Then we have David, who is the arbitrom validator, but he doesn't have the liquidity. And we have Carol, who has the liquidity, but she's not a validator. So is there any way these three can arrange something that can give Alice what she wants at the end of the day? And it turns out that yes, there is a solution for that. We have this solution and our solution is not necessarily the only one, but we think it works great. So the solution is to set up something called a prediction market. So what is a prediction market? So a prediction market is basically a betting market, but with a difference that you can get inside and outside of your position. So in a betting market, what happens is you can place a bet, but then you cannot transfer it or you cannot get out of your position. You have to sit on it, and then you have to wait for the event to happen. But on the prediction market on the other side, what happens is let's say you think the odds of Joe Biden being the next president of the United States is so high. So what you do is you're going to go place a bet against it. In three months, the odds are actually going down. So what you do is you can actually sell your position and can get out of your position. So this is the difference with a betting market. And then it's really like a betting market, but it designed more kind of like stocks, I'd say. So we have this prediction market. The way we set up it is we put the market. It's really like a vending machine. There's no bookkeeping or anything. It's autonomous smart contract. We put it on L1. And so a user would go to it. I can go to it. I deposit one ether inside the market and it would give me two shares. One yes share and one no share. So and these shares are betting against if the assertion is going to be finalized or not. So at the very beginning, I'm actually covered for both cases. So if the assertion is finalized, my yes shares are going to be worth one ether and my no shares actually worth nothing. And on the other side, if the assertion fails, there's a dispute and then my no shares going to be worth one ether and the yes shares are actually nothing. So in any case, I can go and redeem my one ether back. Okay, so how does it work? So let's say Alice wants, Alice is the one who wants to do this withdrawal, right? So she initiates the withdrawal and she's like, Okay, I want my ether now. I don't want to wait for seven days. So what I do is I come along, I go to this market and pay attention to this, that she wants to withdraw 100 ether. So what she does is she deposits 100 ether inside the smart contract, the market, and what market does, it actually gives Alice 100 shares of yes and 100 shares of no. So if Alice actually believes that this assertion is going to be finalized and at the end of the day, her ether is going to get out of the bridge, what she would do. So she would keep the yes shares for herself because it's a bet against the assertions being finalized and she would get away the no shares, right? Out of the no shares. But she's not going to do that and I tell you why. What she does is she actually keeps the yes shares for herself, the no shares for herself, and she's going to give the yes shares to David who is running the Arbitrum validator. So she goes to David and she's like, Hey, I know that you're already validating the Arbitrum chain and David doesn't care about this withdrawal at all. He doesn't even know what that is. So Alice is like, I'm giving you these 100 no shares. It's a bet against this assertion number 10 going to be finalized or not and I'm giving it to you for a discount or bonus so you can give me 99 cents per shares. So at the end of the day, you pay 99 ether and if it's going to be finalized, you can always go back to the market and you can redeem it for 100 ether. So Bob's going to profit, right? So, yeah, sorry, David's going to, I was skipping saying Bob, right? Sorry about that. So I meant David. Yeah. So David's going to profit, right? So he's willing to do that. That's fine. So what she does with the no shares that she kept for herself. Now she can actually go to Carol who has the liquidity but she doesn't know what's going on on Arbitrum chain and Alice would be like, Hi, I'm willing to trade my ticket with you. This is the ticket. It works 100 if it belongs to me now but I can sell it to you and I know that you don't have any idea about this assertion number 10. You don't know if it's going to be finalized or not. That's fine. You don't have to do anything. I provide insurance. So what I do is I'm going to give 100 no shares to you for free. So in any case, if the assertion is going to be finalized and my withdraw is actually confirmed, what I do is what you can do is you can go to the market and you can redeem your, you can go to the outbox and then you can redeem your ticket for 100 ETH. And if no, if there's a dispute happen and this assertion happens to be like not finalized, what you can do is you can go to the market and you can redeem your no shares for 100 ETH. So in any case, Alice is ensuring Carol. So Carol would be able to do the trade with her. There's no risk for her. So this is great. This is the best solution that I guess we have come up with. And for the implementation, this is a work under progress. So what we did so far is we modified arbitrom nitro to support our solutions and we provide measurements. We fully implemented solution 3 so far. It's a proof of concept. So what I did was I implemented an L1 market. It's really like a vending machine, as I said. So there's no bookkeeping or anything. And we modified the outbox so that it would support our market. And for the solution for the prediction market one, it's still under progress, but we modified the roll-up and outbox mark contracts so they could be prediction market friendly. Okay, so I'm going to walk you through the protocol of solution 3, how it works and what are the functions that we added to the arbitrom protocol. So let's say Alice wants to do a withdrawal. So she puts her withdrawal transaction inside the inbox. And then what she does, this is a function that we added to the outbox. She wants to participate inside the market. So market needs to know that she actually locked up her ether inside the market. So what Alice needs to do first is she has to go to the outbox and calls the transfer spender function. What basically it does is it transfer her exit, her withdrawal to the market smart contract. So it's like it's collateralizing her exit. And then what that's done, she can go to the market and she can actually open a market on her exit. And market would check if Alice has really deposited her exit inside the market or not. And if yes, that's fine, she can open a market. Then the market is open for some time until there's a trade. Bob comes along, he's a trader, he's willing to trade it with Alice. What he does is he submits a bit that actually is greater than what is Alice is asking for. And that's when the trade occurs. So that trade happens, everything gets settled down. What market does it first is going to send the ETH back to Alice. So Alice is happy, she got her ETH. And then what it does is because it's owning the exit now, what it can do is it can actually go inside the outbox and change the owner of this exit. So it reached inside the outbox and it changes the owner to Bob. So now Bob owns the exit, we wait for seven days.  And then because he's the owner, the bridge would send 100 ETH back to him. So easy peasy, everyone's happy. And then we run some measurements too to find out how much at one gas it would cost us to run this function. So it turns out it's really cheap. So for transferring the spender inside the outbox smart contract, it's around 86k. And it's really like the most expensive one because it's the first transferring of spender. So it's actually you're paying for creation of a mapping. So because there's a mapping that keeps track of all the owners of an exit. So this is really expensive. The first one is really expensive but the second one and the third one, I guess they were around like 40k, which was really great. And for opening the market, we had to pay around 300k. And for submitting the bid, I had to pay around 100k. And then for executing the transaction, it cost 90k. And that sums up the talk. I hope you enjoyed it. It's really a work under progress. So the repo is not really public yet. But I urge you to reach out to me on Twitter if you need to learn more. We're going to submit it somewhere soon and the repo will be fabricated.


The question that is commonly asked is, which is better? It's called more Kanban. I am not going to discuss that, but I'm going to make a clarification on it. And the other point, which is the important one, is a lot of people think that Kanban cannot be used, for example, in software development because it has no iterations. So we're going to clarify that there's no need of iterations to be able to work effectively. However, Kanban does offer a way in which we can handle something alike iterations. OK? So let's get started. So first off, it looks kind of fuzzy over there. I don't know why, but you guys don't mind about the image being a little fuzzy on the side. I think we're OK, or maybe. No, I don't know. I just leave you like that. OK, so I'm going to start talking a little bit about waterfall. And I think it's very important to set up a mindset. So there is this very strong belief in the agile industry with the agile field that waterfall is bad. It's like evil. And I strongly disagree. Why do I disagree? Because the problem isn't really waterfall. The problem is that we really, most people don't know what waterfall is. So we think waterfall is something like this, right? So we have our big monolithic set of requirements and design and all that stuff that we know. But that's not true. Actually, a waterfall came from a paper that was written by Winston Joyce in 1970 as part of his PhD research, which was sponsored by the DOD in the US, the Department of Defense in the US. And what is really interesting is that this is not waterfall. Nowhere did Winston Joyce say, this is waterfall. This is actually one of the introductory diagrams in his paper. And actually, this paper is very easy to find nowadays on the internet. So you just Google it and download it. It's a PDF. And this is not waterfall. So here's where the surprises begin, OK? So taking that into account, we all know that the most popular agile methodology is scrum. And we like it because it's actually cute. It's nice. You have these very nice looking structures with these loops. It's just kind of cute. It has a nice balance. It could be probably a piece of art on a wall or something like that. That's why it is popular. One of them was a marketing strategy that has to do with certification and all that. But if we ignore that, why do technical guys love scrum? Well, there's two reasons. One of them is, oh, now it's going to be hard for the stakeholders who have nothing to do with the project to come and bug me. So I can go heads down and focus on adding value. So that's a nice one. That's a big deal. I have somebody who is protecting me. We know who that is. But the other aspect is this mechanism of having this short period of time to create and deliver value actually really cool because they helped me have a discipline for value delivery, which is much better than having to wait six months or a year or so. And an advantage of having that short periodicity on top of getting that discipline and having a sustainable pace is the fact that at the end of each sprint, there's a demo. And it doesn't matter how outgoing or how shy the technical people might be because we have all kinds of them. We all, I used to be one of them. A long time ago, I used to be a developer. No matter what, we really like showing off. Like, hey, look, I do that thing. Everybody's looking at or using it like, oh, wow, yeah. So having this very short periodicity of that kind of feedback or showing off my stuff, we just love it. So that maybe is very, very cool. And of course, from the customer standpoint, is values being delivered. So that's nice so far. So now taking that into account, let's go back to Waterfall. So Waterfall is actually really more something like this. So as we go through Winston's paper, what we realized is that what he's suggesting is actually iterations. He said, that diagram is just an introduction to understand that we have a sequence. But what he says is, as we go about doing that, we have to revisit what we're doing, OK? So this idea of short iterations, so that is not new. I just didn't bring something new with that. Royce, instead, was saying we have to loop. And there's actually some more really cool looking ones. So I put these ones just to make it easy to understand. And not only that, he said, you have to do this. If you do this whole thing, you have to do it at least twice. And he also said, beware, this is the result of a PhD research. This is academic. This is not to be applied directly as such in the real world. But what happened? Well, we know what happened, right? This is why we are here. So we know what happened. So I don't need to go beyond that. But what I want to point out is, you can keep very successful organizations and very successful products doing Waterfall. Of course, you can be more successful if you start maturing that idea. A reason why I'm mentioning this is because maybe some of you, and in my line of work, I encounter many customers and potential customers who work on their Waterfall approach. And they are like, I'm not sure if I want to do this agile thing or this lean Kanban stuff. I don't know. So if they are like die hard, Waterfall, then we can tell them, then why aren't you doing this? You want to continue doing Waterfall, then do it right. And to do it right, you have to start going this route. And you know what that means. It's going to be easier for us to start bringing new elements that are going to maybe approach more effectively. So we shouldn't see Waterfall as the evil enemy or whatever. We can actually help mature that. So even organizations who don't want to adopt agile can be benefited. We start bringing this in a gentle fashion. And I think that's huge, particularly in certain companies and some customers. They're really hard to convince. So these arguments will make it easier for you. OK? All right, so far so good. Now, so we all talk about time boxing. A lot of people say we're doing agile. They are really not doing agile. They're just doing the scrum. The scrum and agile is not the same thing. You agree? Agile is a mindset. Scrum is a methodology. And something that is very characteristic of these approaches is time boxing. So why do we do time boxing? What's the advantage of that time boxing? Beyond what I mentioned for a scrum. Well, what we have to begin with is whip limits. As people say, we're a second master. Whip limits has nothing to do with a scrum, for example. That's a lean or a campan thing. In campan, you have whips, but you don't have that in a scrum. And that isn't true. We actually always have a whip limit with a scrum. We just don't call it that way. The whip limit is the number of tasks, the number of user stories, that we have on our spring backlog at the beginning of the sprint. That number of tasks that we have is a whip limit. Why? Because I'm saying this is the maximum number of tasks that I'm going to work on during this sprint. Yes, we don't have whip limits anywhere else, but the entire scrum structure has a whip limit. And of course, something that is interesting in this case is that whip limit changes sprint after sprint because what we keep fixed is not the whip limit. It's the velocity or accuracy of that kind. However, something that is important with the time boxing approach is that we have whip limit. This is also another aspect, which is small batches. The fact that we have a small time box obviously forces us to have a small amount of work to do. Having a small amount of work to do means we want to have a small batch. What is the advantage of having a small batch? Well, the advantage is that it allows us to focus more easily on getting a small amount of work well done, which is much better than doing a large amount of work poorly done. And there's also a psychological advantage. And if you don't believe me, just try yourself. Either with yourself or experiment with someone else. Just give someone a small amount of work to do, a tangible amount of work. Like put a pile of paper or something and say, you have to do all this work. And then give another person like four, five, six times that amount of work. And be very observant of the body language, the facial expressions. And what you will notice is that there's actually a reaction of stress in the person who gets this big chunk of work to do. And they will be like, whoa, hey, what's going on? If it's a small amount of work, they're like, oh, OK, cool. Yeah, man, I can do it. So just probably from the purely psychological standpoint, having a large amount of work to do already starts lowering quality. Because I'm already stressed even before I began. And that affects quality. Then we had the periodic delivery. So again, the fact that we know the benefit of being able to provide a small amount of value and being able to either get feedback from the customer or getting some feedback from the test side of things or the user acceptance test, et cetera, this periodic delivery allows me to more quickly be able to know whether I'm doing OK or not. So that's an advantage. And as I mentioned, it brings discipline, which is, I think, the biggest advantage of having a sprint. But there's a small problem, a small, big problem. If we're working with the sprint, the sprints have absolutely nothing to do with providing the best value to the customer. And it has absolutely nothing to do with really taking into account how the customer is appreciating the value or if he's actually getting the value the way that is best for him. The sprints have everything to do with just bringing a discipline of work towards the team. So Scrum is really cool from the development standpoint towards the team or towards the customer beyond the fact of getting this benefit of getting this value every two or three weeks, there's nothing else. And that's dangerous, because the customer, after a while, it could happen. I say, well, it's nice. I appreciate what you're doing. But it's not really giving me the best I could get. So you start having some problems there. So what we have to understand is that one side doesn't fit all. We cannot just say, I'm going to pay something. And whatever it is, I just encapsulate it in two weeks, and I'm going to deliver to you whatever. I'm just happy that I have the discipline and I can deliver to you. And the news is, it's not about us. It's about the customer. So what we need to do is that which really satisfies the customer, that which really increases the value that we are delivering to the customer. So what I'm saying is that whereas, yes, there is value on having the sprints and being able to deliver, there's something even there that we can do for the customer. So I am not saying that Scrum is bad. I am not saying it's wrong. I mean, I still do it. I have customers with whom we work on the Scrum framework. But we mature that to be able to deliver better value. So what I want to bring into this talk is for you guys to realize that we can do even better than that. So this is pretty good, but let's not stop there. Let's take the next step. And what we realize, hopefully everybody at the end of this talk, is that even if we're talking about Kanban iterationless approach, we will learn that this can be applied to Scrum as well. So let's just go the next step. Let's do even better for the customer. That's what I'm trying to bring into this talk. So what happens? We want to fix things into a sprint. So what do we do? Well, we have epics. And we break them down into stories. And we just keep on breaking down until they fit into a sprint. And if they don't fit into a sprint, then we have to be creative. And what we try to do is make sure that we don't do that. So it would be really nice if we could have stories that can be completed in between one and three days. You know, from the technical standpoint, that's ideal. For example, LinkedIn in Mountain View, California, their IELIN implementation is more than impressive. And they work mostly with Scrum. They do some Kanban. And their story points, maximum size is eight points. And the maximum amount of time to deliver these stories is three days. Most of them are between one and two days. So that's a nice thing to do. However, maybe sometimes this is a little too much. Maybe this idea of breaking things down, I mean, from the technical standpoint, it's okay. But when you talk about the story, trying to break it down into smaller chunks might make things just harder, rather than easier. So we have to be careful about that. So what do we do? Well, typically, you know, the considerations are let's use variable speeds, right? So some, so we change our speed for our screens as we go along to adjust to, you know, what we want to deliver because we just can't fix the things in to what we have. So that's one strategy that is used to deal with this kind of situation. Another strategy has to do with generating different kinds of requirements. So then we say, okay, this kind of requirement, it always has to fit within a screen. This one is okay if it takes two screens and so on. So we start being some sort of flexibility, but with discipline. And one way to do it is just we have, we classify different kinds of requirements. So that's another strategy. And another one is, well, what I mentioned, we can just say, let's leave this story to bleed to the next screen, okay? So basically, we are acknowledging that in the real world, things are not as pretty as they look just in the diagram or as it was written in the book. You know, we had to accept the natural philosophy of things, that is we have to accept the way the real world works. And in the real world, things are not that pretty. So we have to adjust and we start being creative to be able to fit things into that structure. So there has to be a better way to do this, okay? So what can we do? The big question is, okay, so yeah, that sounds kind of interesting, but what else is there? What is it that we can do? And why do we want to do it? So what we have to take into account first of all, is when we are dealing with knowledge work, and specifically we were talking about software development, we cannot see inventory. If we were working at a factory, we can see the accumulation of work. But when you are talking about software development, you don't know.  And as your manager, what is the amount of our designing process inventory?  But it does make perfect sense. There's a homing, right, from the sound. Excuse me, there's a homing there. He's on the cell phone, he's paying attention to the phone. All right. Hey, girlfriend, hold on. So what we have to understand is that even the fact that we cannot see it doesn't mean that it doesn't exist. There is actually an inventory that we're accumulating on different steps of the process. And what this means is that what we have to do is we have to make sure that the flow of value throughout the entire process is the best possible one. And that's something that we're not used to taking care of. We're just saying, I have a limited amount of work that I'm going to take care of during two, three weeks or whatever my screen size is. But we really don't care about how that is worked within the screen itself. How do the designer, developers, testers, and all of them go about doing that work within the screen? We don't care. It's like, oh, it's autonomy, go and do it. You know really well how to do it and go and have it. And yes, autonomy is excellent. But that doesn't mean that we shouldn't figure out a way to improve the way we're actually creating that value within the screen, for example. So what that means is that we have to understand that there's this aspect to consider when we're talking about queues. So what happens? Well, depending on the size of our queue, we can run into this. So if our queue increases, then we have a longer cycle time, which means it takes longer to finish the work. We increase the risk, obviously, because the larger the amount of work that we have to work on, there is more to consider. And then risk accumulates. There is more variability. Something inside that amount of work has some sort of issue or there's a variation. That variation can trigger other variations. So then that also accumulates. There is more overhead. Seeing that we see with large projects, even with a small batch size, if we start increasing it, even if it's within a small range, we start having overhead. And this compromises quality. Why? Because I think we need to focus more on the amount of work than on the quality of the work. And of course, people lose motivation. So we have to be very careful about that. And what does that mean? Well, what that means is that we have to reduce that size. Why? Well, to attack those issues. So we want to reduce all those aspects. But one important point is to accelerate the feedback and improve the efficiency. So how can we manage the handling of that within the execution? And how can we deliver to the closer in a way that is reasonable? Well, so what we can do is actually to the couple. What is it that we are used to? What we are used to is, OK, here comes a sprint. OK, so everybody is ready. And so we have to get the customer or the representative of the customer, my field, to say, OK, so I have to have my backlog ready. And I have to decide what I want to propose to be done. So then the team takes it. And we do the sprint backlog and so on. We just move on. I'm using Scrum as example, because it's very clean for explanation, but this applies to other approaches as well. The point is, in the real world, let's say that for some reason, the product owner is on vacation and the customer for some reason is on available within the sprint. We are ready to take over. And we don't have anything to take. Or we don't know if the value is up to date and so on. So there's a problem with having this synchronization that happens in the real world. So what will happen if we can decouple that? And also what will happen if we could decouple the value creation with the value delivery? Well, that level of flexibility will make it a lot easier for us to deliver better value to the customer and to reduce dependencies. So this is what we can do. We start decoupling. And the way to decouple is beginning to bring elements into our approach. So either we can just say, well, let's go the Kanban route because Kanban already includes all that. But what if we're not doing Kanban or we don't want to or we can't or this particular team has some allergy towards Kanban? We cannot do it because it inches. Well, we can just bring elements that make it easier to do this. And the decoupling can happen in different ways. So what if we were to decouple not only the fact of when we get the requirements and when we deliver, but also what will happen if we can decouple all sorts of activities in such a way that we get the best possible value flow? Well, we have to consider always the economic factor. So what are the economic reasons behind the ideal methodology? What are the economic reasons behind an approach like Kanban? What are the economic reasons behind wanting to decouple? So we're used to saying, I finish a sprint and I deliver. And over time, if it became accepted the fact that we can actually do a different kind of delivery that has an economic reason, which is my MMFs, my minimal marketable features. Well, another economic reason could drive us to do an MMR. MMR is minimal marketable release. And what that means is what we're going to do to determine our MMR is to consider the transaction cost of the release and the cost of my cycle time. Why is that important? Because we're talking about money in the end. So maybe doing deliveries after each time box, the sprint or whatever it is, can become a little too costly. And we are actually delivering something that is not really ready for the customer or that the customer isn't ready to take. So then why do it? It doesn't make sense from the economic standpoint to do it. From the functional standpoint, yes. From the process standpoint, yes. From the economic standpoint, hmm, question mark, okay? So we had started taking that into account. So then what we have is that if we have a process, a given process, whatever it is, in this case, this Kanban, but whatever it is what we have to take into account is how can I go about flowing my value and being able to deliberate in a way that makes sense? And let me give you an example. So in this case, this is a process for a customer care organization. And so we have different tasks going on. We have two teams working in parallel. And we get to this point and I think it's very clear where we have more tasks accumulated are exactly at the last column. And the last column is guess what? User acceptance. So we have this work happening and this accumulation of work. And what does that mean from the economic standpoint? What that means from the economic standpoint is that nothing is being really done. Meaning if the objective of what we're doing is to deliver a benefit to the customer in terms of value, the customer is receiving zero value. He's just not going beyond this, he's not being delivered. In this case in particular, he's not being delivered because the customer itself is not doing its job. So in a regular point you say, hey, well here it is and you're not taking it as your problem. I don't care, but we should care because basically if we're doing all these work spending all this time and effort and money, to do something that is never going to benefit the customer, what we are doing is we are creating waste. And what benefit does it have to generate waste? Nothing, none, okay? So these customers say, okay, we don't know what to do here, very simple. Take a photo of this, email it to the customer, call them up and say, you know what?  So what we are going to do is we're going to finish what we are doing right now because we are not going to do things have done, you know, it's not a good practice. It has no economic value, but we are not taking any new tasks to work on because we are wasting our time. So we're just working on this and then we're going to start working on something for another customer. Once you're ready for us, then we will come back to generating value. Two hours after that phone call, this was smaller, okay? The customer realized that the value was being generated but was not being received by him. So what can we do? You know, I'm still having to do this, how can we just be proactive and make sure that this doesn't happen? Well, so there's something that's called cadence. Henry Gnever mentioned the word cadence, right? I know if some of you attended his talk, he mentioned that. So I'm going to dig deeper into this so this is a very powerful point. So cadence has to do with being able to deliver value in a way that actually has economic sense. And what this means is that we can have more than one cadence established to deliver that value. And we can take into consideration different aspects. So these are some of them that we can take into consideration. So let's think about this, okay?  So I say, well, you know what? I'm just going to hire a laundry service.   We make sure that you get the best satisfaction ever, we deliver great value. So what would you like us to take care of? Well, my personal clothing, bed sheets, table clothes, curtains. All right, yeah, we can do that. And you can trust us entirely.   And they go, well, you know what? I mean, for the tablecloth, it's okay. The bedding, maybe I'm not quite sure, but personal clothing, having to wait three weeks, I really don't think I like that. I mean, just doesn't work for me because I will have to buy a lot of clothes and they'll have like a ton of clothes waiting, you know? And that doesn't work for me. So then they say, oh yes, you're right, no problem. As we say, 100% customer satisfaction. So now we're going to deliver everything to you every three days.  I'm not quite sure. That's what happens with the current approaches. It's one fixed time box to do everything. So that brings discipline into the team, but that is not really satisfying the customer need. So what if we were to start understanding what is that the customer wants? And one way to do that is, let's say we have different kinds of tasks. So instead of having one kind of task within my value generation, I understand the different kinds of tasks that we are working on. And then we make it explicit. And then what if we say, what will happen if instead of having a time box for everything, we determine a time box depending on what it is that the value of these different kinds of tasks bring? That's point number one. Point number two, what will happen if we do this in an intelligent fashion instead of just making it up? There's just going, I think this will be, okay, no, no, no, no. Why do we actually have a way to really understand that which is what the customer will satisfy, that which will satisfy the customer better? So, and also understand that this can be applied to anything. So this is, for example, in solar development, you could have something like this. Your urgent tasks, you know, the unavoidables, something urgent is going to happen every now and then. What that has to do with tasks that the customer doesn't perceive. We're adding a new server rack, updating the database, stuff like that. We have work that needs to be finished on a specific date. Oh, we need this for Valentine's Day. So this functionality has to be there. Or just in every other task. Why do we just have a way to really maximize the value, the way we deliver that value with the best economic terms? And also being able to do this for any kind of context. So this is, for example, for business development. And all these are real cases. The first one is very typical for development. This is for a company that has a large customer base. This is a solution for a hospital. And this is a real thing. So we have a different way to treat and deliver value. We were talking about an outpatient versus an inpatient, administrative tasks, and so on. Imagine somebody comes into the emergency room and says, I know we treat one patient every two days. Just wait there, it's okay. Hey, I'm dying here. Yeah, just wait, don't worry. So we have to be realistic. So how do we get into the realistic point? Well, we quantify it. Okay? We are used, if we are very much into agile and strong, to do a lot of qualitative evaluation. We cannot stay stepping away from quantitative. But it's actually good to go back and taking that into account. So if we quantify, we're gonna have a huge advantage. But not only that, when we quantify, we have to be careful to quantify properly. So we are used to saying, okay, I have my somewhat Gaussian curve with my sigmas. And based on that, I can know what my variation is. And I can make promises to my customers based on that. But most of the times, we made a mistake of quantifying only up until here, to this part. Or this part here, or this part here, or this part here. So the curve is, it can be quite uniform, or you can just lean a little bit over one side of the next. And we could say, okay, I have the idea of what my behavior is, for example, of how long the tasks that I'm working on, how long the user stories that I'm working on are taking to be delivered. Yeah, I start quantifying that. If I only take this main curve, and I say, I'm going to take my one sigma, for example. And then I'm gonna tell the customer, if it's a customer, 93% of the tasks, the user stories that we're creating, we're going to deliver to you every seven days or less. Okay, that's better than saying we're going to deliver a hundred percent of them every 15 days or less. Because the customer will say, well, 15 days is probably a little too much. Seven days sounds kind of cool, even if it's not 100%. And then we'll say, well, we're quantifying, so we're safe, yeah, we're delivering. And what we will realize is that after a while, the customer will be very unhappy because we are actually not delivering as promised.  I don't like that, you know? I don't like being taken advantage of. And it's not that we were taking advantage of the customer, it's just that we weren't taking into account the whole story. And the whole story is taking into account your full data set. Because what you will see is that in the real world, this is the behavior, all these charts are for real things in the real world, in different contexts, okay? This is something from NASA, has to do with gravitational lensing, that has to do with something, has to do with supplier evaluation, that has to do with advertisement, this has to do with customer portfolio management. And what we will see is that we have outliers.  So this usually like one, two, or more. So if you take a larger sampling of your data set, then your promise is going to be realistic. So what that means is that we will tell the customer, instead of every seven days, we will say it's every nine days. And even though nine days is longer than seven days, if we are actually delivering as promised, the customer will love it. And that's huge, because that increases confidence, okay? And at the same time, we are delivering, you know, in a way that really works. So what that means is, okay, we can try that out. So how do we do it? Well, we can take different approaches. We could take a sampling of everything we do, okay? So let's say in the case of an approach like a storm, we only have this story, we don't differentiate. We can take a sampling of everything and make a promise based on that. But we can actually go and do better. And there are different ways to do it. One of them is, you know, the classes of service, the different types of tasks that I showed before. Or we could say we have, for example, for a project, we have capacity allocation. So we have one team is working on this and the other team on this, and these are other tasks, like defects, infrastructure, whatever. And we quantify and we could say, well, if we assign the specific kind of functionality to team one and we understand the way that team one behaves, then we can make a promise based on that. So we could tell the customer, you know, this kind of functionality is going to be delivered to you every nine days or less. This kind of functionality is going to be delivered to you every five days or less. And this work, we're always going to make sure that it's done every 48 hours of work and this is done every half a day or less. What does that do? That actually increases the discipline within the team. It makes it easier to understand what we have to do. It makes it a lot easier to make decisions and we actually deliver much better value. And what the result of this is that the time of delivery is going to start getting better over time. So for example, if you look at this graph here or this graph here, what you will see is that these lines which indicate time to start getting shorter over time. And what does that mean? Well, that means that this project that we will finish sooner, we actually finish it more sooner. Or if not, at least we're going to get better quality. So basically what this means is that we do this capacity allocation and we apply this concept of cadence. We're going to have a really nice improvement which was impossible to obtain before. Before the only thing we could do is we're here, we apply something like this from, we have a really nice improvement and then it goes almost flat. It improves by very slightly. So everybody's really excited because like, wow, look at this big improvement. We have a sprint and so on, but then what happens? It's the same thing, it's the same rhythm, it's the same modus operandi. Why else is there? Whereas here we have a way to actually start going and doing better and better. Okay, that's very, very important to consider. So again, we can apply this to any kind of approach. So for example, if you're talking about scum, what could you do? Well, something that you can do is improve your board. You have your board and instead of just having to do the wing and done, they do in part visualize it better. That doesn't mean that you're going to make it waterfall style, like how development and testing and so on. You practically have a board in which you have, you're doing a column and they subdivide that column in sections and then you visualize where it is that you are within that development part. Are you doing unit testing? Are you developing test code? Is there such a development going on? What is happening with it? And that increasing on visualization added to, I did find that different kinds of tasks will allow you to start doing this kind of quantification. So imagine that instead of being seen, you say all these are say, my regular tasks, these are my fixed deliveries, these are my urgent, et cetera. And you quantify that. What will happen? What will happen to the urgent tasks? Well, instead of being treated as a hook, as usual, we could establish a discipline behind it, which will be something like, if an urgent task comes, what we have to do is, we look at it immediately, we determine what needs to be done, we pull out the resources that are necessary in the order that is adequate. We keep a log of that behavior and we quantify. And then at the end of that, when we finish and deliver that solution, that's not the end of the story. We're going to do root cost analysis. We do root cost analysis and we determine which variation that generated that urgent task can be tackled. What it is that we can do so that this kind of variation either doesn't happen or has a lower impact. So the next time we have an urgent task that has something like this one, we can tackle it better. But then eventually, some urgent task will stop happening thanks to this. So we start having that kind of improvement and we will see it because if we quantify, we will see that, let's say, your typical urgent task takes six hours to be resolved. Then eventually, similar urgent task will take five hours and maybe four, and maybe less, and so on. And that's what we want to do. So what does that mean? Well, that the value to the cost, the delivery of value to the cost might be more efficient without us having to work harder. Where you're working is matter. And we're still keeping our approach of the way we do things. Do you have a question? Okay. Okay, so this has to do with Kanban. It doesn't mean you cannot do it with a scum. So what those numbers mean is the maximum number of tasks that you want to have at that step. And this is what, you know, at the beginning of the talk, I mentioned that in the scum, you have only one week limit, which is the number of tasks on your sprint back load, back load at the beginning of the sprint. So what you can do is granularize that. You can indicate I want that for design, I can only have a maximum of four tasks at a given time for development five and so on. And also there's a criteria that helps us determine how to do this. There's not a magic formula as to, you have these resources or this condition, this is the right number, that doesn't exist. Because it depends on, it's a case by case thing. But what is important is that you can make story or whatever it is that you have, you know, use case, whatever flows from the beginning of your process to the end of your process in the best possible way. That's what you want. Because again, what matters is the delivery of value. Okay, okay, thanks. The best thing that you can do, independently of whether you're doing Kanban or not, I mean, it doesn't matter, it really makes a lot of sense if what you do is make sure that your board reflects your current reality. What is my process right now? That's what I want to visualize. I don't want to visualize what is documented. I don't want to visualize the idealization of my process. I want to know exactly what's happening at this very moment. That's what I visualize. So if you visualize that, then you're going to understand what's going on and information, well, do you guys agree that this is an information right here? In the end, it's a way to visualize what's going on. Then, you know, I have a rich way to visualize my reality. And the advantage of doing that is then, whatever I encounter, that something is not going quite right or that it could go better, then that's an opportunity for improvement. And I can say, okay, now let's analyze this. Let's explore it. Let's get into detail. And how do you do that? Well, if you're quantifying, and if you have a log of activity behind that task, or behind the behavior of your entire section, then it's easier to determine what's going on and then figure out a solution. So what is important here also is, this is not going to give you the solution, okay? It's never going to give you the solution. This just makes it evident that something is going on there and it's up to you to figure out how to solve it. Yes, this is a Kanban ball. So, okay, thanks. So the first thing to understand is that Kanban is not a software development process, okay? You can apply Kanban to a process that already exists, but you cannot say Kanban is my process. Something is already there and you use Kanban to visualize that and then start working on it. So if your process has iterations, then that's fine, Kanban says good, there's iterations here. If your process says there's no iterations, Kanban says great, there's no iterations. So talking about Kanban being iteration-less, for the purpose of that, doesn't really make sense because it's entirely independent of Kanban. But what we are saying here is that you can actually use Kanban and the information that you have, the information they provide to quantify the behavior and then be able to make decisions. And one of those decisions that you can establish is a cadence for value delivery. Now, this is based on this quantification. So you're not saying that what you have is what one person is doing. It's the behavior of your system. So the system's behavior is what allows you to establish that cadence. It's not one person versus the next because that really doesn't matter. We don't care if it's Bob or James who is doing it. What we care is for this type of work, what is that the behavior that allows us to make a promise to the customer. You have to apply these two. Scrum, for example, you can get rid of the spring because the cadence, the different cadence that you have replaced the spring. Henry actually mentioned this often when he stopped. Why are we doing the spring? Because we have this, we have a cadence. So it's a different way to bring this point. And actually something I'm going to take out by this to mention this. If any of you, in your organization, you have a team or your team is already a very highly effective, very mature scrum team. There to remove the spring. The moment you remove the spring, the protein is going to go off because the spring where it was bring the discipline. But if the discipline is already there, it actually starts being an element of friction. We could do more, but now we are limited. So you could try that. Many things have done it and they get shocked by the improvement. Okay, so yes, you want to mature your board and you just want to mature that status. So basically what this means is if I have a project and I have a visualization of the project through a Kanban board, I'm hoping that everybody on the, we end up getting really interesting discussion. A project changes over time. The indicator of a project changes over time. It doesn't indicate the same way as the beginning and the middle towards the end. If the Kanban board is a fingerprint of my current process, that means the Kanban board is going to change shape. And then what you're doing is bringing continuous improvement, but that also means that down the road, as you observe your behavior, you may come to the decision of changing the width. Beware, the moment you do that, all your previous quantification is no longer valid. You start anew, which is okay. Well, I mean, yes, it is true that you have, you know, the similar design, well, the more predictable it is, right? I mean, that's a nice way to do things, but we have to verify that there's not going to happen. And if I force to break things down to that, I'm making more trouble than not. And that will have all these samples. So you have different tasks, but I should probably put this one up here, to make it easier to see, because this one is a bunch of dots. But what you see there is that different tasks are taking different time. Or like here, for example, these are days. So if, well, you know, these satisfy customers' demand within a certain range of time, there are some demands that take longer, and some that take longer. So we have different size tasks, and I would say it's not really the size of the task. You know, it's the complexity of the task, you know? So it can be a small one, but it could be a really hard one to take care of, and it takes a long time to work. Okay? All right, so actually a pretty good time. So they just go into the conclusion. So just to, you know, to graph this up, it's important to take into account different variables to be able to do the decoupling. Okay? So just consider different alternatives, and then make a decision and act accordingly. Do I want to decouple, you know, the way things get into my system, you know, the how frequent or in which way the customer tells me what I need to work on, what I work on, and then how I deliver. Do I want to decouple that? Do I want to take into account, you know, the size of what I'm doing, the complexity, depending on the shape of my board, do I want to do it based on how I allocate my capacity, et cetera? Do you have to make a decision on that, and then establish your cadence based on it? What is important is that the customer is going to be way happier. Why?  I'm a lot happier with that because I don't feel like I'm being fooled, and I'm overpaying, you know, for the service. There is also less work for the customer. If I force, you know, like in the spring, that every two weeks something has to be there, you're like, hey, wait a second, no, I cannot, that doesn't work with me. You know, the way I operate or my needs are such that I cannot do that. So I appreciate that it's good for you, but it's not working for me as a customer. But if I decouple that, then I as a customer can provide to you what needs to be done in a way that works for me without affecting the way you have to do your work. And of course, it increases the team's productivity because we are actually doing the work not only just based on the number of tasks per time box, but we're actually doing it in terms of the kind of work that needs to be done because of the value they provide to the customer, okay? So nonetheless, we have to still keep those good practices which have to do with considering a small batch size that's something to do, you know, establish the cadences.  So those who are new to this, you know, to agile and lean, it's very important to understand that time begins to lose importance as you mature your organization and the value of the leader. Okay, so that's all I have. If there are any more questions, please do. Let me, okay, okay, okay. So what I refer to specifically with this dependency is the dependency of you as a customer having to give things to me in a given phase which is the one that works for me as the creator of value. So you're the customer and I say, you have to give me something to do every week. Like, well, you know what? I can do it probably once or twice, but then I get busy with something else and I didn't have time to prepare what you need and so on. That's what I'm talking about. Is that dependency? So when you tell the customer, you know what? I just need to have work to do, you know, and in this way, this is how I need it. But how you create it and you provide it for me is up to you. And then you can actually help, you know, then make the decision of how to do it. But what is important is that you eliminate that dependency. So you decouple one from the other. It's good to have small things to do, but it's not a good idea to have things smaller than they should. Okay, so you can break it down to certain point and if that critical point doesn't fit your thing, what do you do? Right? So that's what I'm referring to, that you have to be careful about that. Don't make things more complex than they are. If breaking something makes it more difficult, more complex, then you don't want to do that. Yeah. What is what? How do you know it's quantifying?  Because there is no magic number. It depends on your process, it depends on the project and the kind of product. That depends, you know, it depends on the team. So there is no one number or one range. What you have to do is you have your own context, you quantify and then you determine what to do. But definitely, the smaller the device size, the better, up to a limit. And one way to actually appreciate this that is independent of hard quantification is the stress level. If you have a large batch size, what you will see that your team is going to be stressed. You start lowering it, you start getting better, but then you see people lowering it and the stress starts going up again. So you have to be very careful. There's actually an exercise to do that. And there's an opening space. Okay, so I am going to do this. I am going to attend a talk after this, but at five, five, five, four, five, I don't know where open space is and I know there's open space at that time. But maybe what we can do just to be on the safe side, once you get to the launch area, you go to this, there's these rooms and the other rooms, right? And then the elevators are on this side. You go exactly the opposite way. There's like some sofas there.  Okay, of the stress level. So I will be down to 35, four, five, okay? That's an interesting question. No, I mean, that was an early belief just because Kanban was born there. But I mean, let me tell you, my company, more than half our customers are not even software or IT. So we have applied this into new projects, new software projects, existing projects, software projects, IT, healthcare. So what I tell you there is actually free that we have worked on, healthcare, education, telecom, so, yes, no. I think to think where we have encountered particular challenges. What I have encountered is different challenges.  I really don't know. The one that I'm actually curious about is one that we haven't had the thing to put our hands on, the proposal is on the table, but it hasn't been approved yet. I mean, it's for exploit a copper mine using this. But I mean, within a bit, say software and IT, I can't seem to be saying there's actually a pattern. I haven't seen that. Maybe there is, but I haven't seen it. Yes, yes, yes, yes, and actually, well, I'm gonna tell you one right now. So I have this team, they are doing the scrum, and they are being effective. I'm definitely in effect doing the scrum, but it was clear to me that again, the way the value was being generated wasn't really a clock. And I wasn't happy with the amount of value. It was like, this team can do much better. So the only thing I did was, you know, one day I took a post-it. No, no, no, they were delivering value. They were delivering value, okay, they think. But you also have the behavior, and you don't see a pattern of behavior. What you see is that they are just doing something. I can do something else right now, take this task, do some testing, or to the development, do some design. So you see that they are taking tasks and working on them, but there is no pattern. So basically what they do is, I have 15 days to finish this amount of work, and I'm going to do whatever it takes to get it done the best possible way. Of course, we don't want to compromise quality, but that's it. Is your talk, oh, perfect. Okay, we're out, we're out. Let's talk outside.


The number one challenge I face when I work in tech industry is the fact that I don't know how to code. My very first product I launched was in the AI space and the second product I launched was in the edge computing which is cloud computing space. This is extremely challenging for me. However, the first AI product I launched received the mayor's best practice award and I also launched a super technical cloud and edge computing product which the first time ever in the world we have used this 5G edge computing product and I was the one who's leading the launch of the product. Here is how I conquer the technical challenges. Number one, first of all, I tell myself even if I don't know how to code, there's a way to solve this problem which is to learn system design and that's why I learned from MIT system design which I was able to use the systematic thinking to break down any complicated problem so that I was able to communicate with engineers and tell them what's the best methodology to solve the problem and ask very smart questions even if I don't need to code at all. This is darkness cv like and subscribe watch the next video right here


What's up everybody, I'm Jason here for jaspyscasebrakes.com Doing a quick one-pack break of 17-18 prism cello, which is random teams number 38 And this is a chance to win spots in NT basketball random teams number two So the way this works guys is we're going to randomize a team the names They'll strip you the hits out of this one pack and then at the end of the break We'll randomize because for names again a separate dice will a randomizer and the top seven names out of 30 Well, what a spot each in the NT basketball random team number two break In a fraction of the price. So good luck. Let's do the break first Here's the dice roll and we got a three and a five eight times. Good luck one two four, let's go eight times team one Two Chicago Bulls down the Atlanta Hawks I agree with the bulls ride with this verse Tim with thunder Brian with the heat Allen with the Raptors even with the Rockets Matt with the Cavs will open the Lakers Brian with the Knicks deep with the Pacers Kevin with the 76ers Dating with the magic right with Hornets Leonard with the nuggets Allen with the pelicans Josh with the wizards Leonard with the T Was Eric with the pistons Matt with the Celtics John with the Nets Curtis with the Kings Patrick with the Clippers Greg with the Jazz John with the Bucks Leonard with the Grizzlies Eric's with the Suns Allen with the Blazers Blake with the Mavericks Matt with the Warriors and Nick with the Hawks. I think boss man's breaking down some stuff All right guys, well, no one's gonna trade so I'm gonna close the trade window stick with what you got get several dice Well around my door. We'll see who wouldn't spots an empty Jim and Brown Green the Tatum rookie. How about that? Was the Celtics Matt McCrae Tatum stuff has gone up a lot sweet now Let's see who's gonna get spots in the NT break now and again top seven get spots in the break And he ran until number two Let's roll it and we got a two and a five seven times. Good luck. Top seven get in seven times One two three four five six and seven Boom seven times So Stephen P. You're in Tim you're in Matt you're in Brian you're in Blake you're in Brian you're in an Eric you're in Congratulations guys. You guys are in the break itself Which is round on teams number two of NT basketball. I'm sure we'll post up another one of these up soon To bring down the breakdown of two left Jasper's case breaks calm


Oof, thank you for being here. Today, we're talking about temporary hair color. It is one of my favorite things. I used to use temporary hair color all the time and you guys may or may not have even known it. Sometimes you guys thought it was permanent color and I was like, girl, it's not real. This is just fake and it looks really real. If you're wondering what temporary hair color is, well, it is color that you can put in your hair. It shows up instantly and it washes right out after one wash. It does not stain your hair, it doesn't stain your hair. It's just an easy way to change your hair color all the time without any damage and no commitment. Well, we're testing out four of them today and once I pick the best one out of all four, I'll be coloring my own hair with that dye. I'm excited to have some different color hair for the day. It's been a while, maybe take some photos. It'll be cute. Follow me on Instagram at www.bremando.it. I'll make the link below. And yeah, let's figure out which temporary hair dye is the best. Let's do it. So, we're gonna begin with the one I used very often which is the colorista one-day color and the shade purple.  You know what? I have a lot of things to do this week and I don't want stain hands. It doesn't actually stain, it just like leaves a cast on your skin sometime so be careful. Especially with these sprays, ooh, it gets everywhere. You're about to see what happens. I'm gonna put her hair down in the middle. I grabbed a piece of paper because this is so important to have when you're doing this stuff with the spray. Cover your bathroom or wherever you're doing this or do it outside. The thing with spray is that it doesn't really like get on everything. You have to like really move the hair and like it's annoying. I will start now in the back. The best thing about this is that the hair tends to still be like movable when you're done. We need to be doing it in a closed environment.  Now you can see that there is so much stuff on her neck. This is the only thing I hated about this process was that I had to like wash my face. Also the color payoff is kind of disappointing right now. It's like, where's the color? Let me just attempt to make this all even. It's empty, that's so upsetting. Well, good thing I have another can of this purple because girl, you're not done. This cannot be safe for me. If I keep doing this, I'm gonna...  Does it look like a blob? Yes. Does it look bad? Yeah. That was tough for me, Miss Menequin. That one was tough.  Hopefully what we do next is going to be a lot more user friendly and a lot better because Hollerista, oh, I'm disappointed. Okay, up next we have our Menec Panic die hard in green. I'm feeling good about this one. Let's see the directions real quick. I can't see them. They're blocked out by a big price tag. Awesome, I don't need directions. Totally. Ooh. No, totally. That's disgusting. I don't know if her hair is light enough for this. No. Okay, actually, no, what is going on today? Am I supposed to blow-dry it in?  It is churning green and it's a lot less messy, I will say that, so that makes me happy, but it's really hard to get this stuff in the hair. Her hair looks like seaweed. There's nothing wrong with seaweed. If you're watching, I have nothing against you. I honestly actually like the taste of you, but her hair looks gross. Okay, update. I ripped the label off the back to see what it said. It doesn't have any directions. I don't know if I'm supposed to blow-dry this in, but I feel like I'm not supposed to leave it like this. I also don't want to wreck my blow-dryer and get green all over it. What are we doing? Do you know what we should do?  You want to?   I'm just going to try and blow-dry just a little bit. I guess. I quit. Now, that's it for me. That did not work. I don't know what you're supposed to do with it. Like I genuinely don't understand the product. I just tried to blow-dry it and it was so sticky like there was like gum in the hair. I mean, I guess if you wanted to do like a ponytail and put your hair back with it and color the ponytail, it would work, but this is just not going to cut it for me. I just took a little second to do something, as you can see.  So I was like, okay, what if a girl just did like a front piece and then blow-dry her hair with it? Honestly, this feels so bad.  This just still feels like hard hair spray and it doesn't even look good. Like there's all little clumps of gel in there. It's so gross. And look at my hands. All right, let's move on to my final thoughts about these two products. I'm actually like not that mad. Now that I sit down and really think about it, it's way better than what we saw. This Colorisa spray is $10. I will say like I like the spray because it dries instantly and you're not going to get that like pomade gross feeling after.  I think that was pretty noticeable. I still don't feel very good. The color payoff was good. I felt like it really covered the darker hair and looked nice.  I should have just in a small section and like call it a day. But this also works good on a hair like mine. It's short and I can like spray it on but it gets all over your skin and it's kind of like messy. So that's the downside. It's hard to get even and knock it on your scalp. And if your scalp's all colored, it looks really ugly. Let's move on to this piece of work of a product. This retails for $9.50. For what they made the product for, it actually is great, you know? It is supposed to be a gel. I probably just didn't use it how they would have liked somebody to use it. I'm sure this is probably geared towards more people with short hair but you really can't even do like small pieces with it because it just gets everywhere and it's so sticky. I don't know. It was so not user-friendly. Just don't use it how I did it and maybe it'll work good for you. If you're looking for a gel that also colors, well, this definitely does that. I think we can do a little bit better. And yeah, without all that, I guess we should begin with the next two and hopefully we get something good here. Hopefully they actually work. However, my standards are set very low now. The two next products are different from the ones we just used and you will see that in a second. Okay, I'm back. I'm more hopeful than ever because I want something to work so bad. Mm, okay, I want it to work. Gently, please. I washed her hair twice and her scalp is still stained purple in some spots, whatever. We're gonna be using Next Poser Paste. Okay, so this is one I've heard of but I've never actually used before. This one says stir before using. Okay, weird. Apply to clean dry hair. Add more for greater color intensity and dry as quickly. So brush it out for a softer look. Good to know. I guess I'm just going to apply to the front piece of her hair. I don't think I need to do the entire side. Like that was really obnoxious last time and way too much work for me. You guys know me. Just trying to do the least and do the most at the same time. Interesting texture. It's definitely like a putty feeling, like Play-Doh, but softer. I kind of like it. I kind of would stick my fingers in here all day. Okay. That is not, yeah. Okay. Ooh, it smells really good too. I feel like we're gonna get a lot of good color payoff. Ooh. Oh, my interest has peaked. Okay. I guess I'm just trying to figure out like how this is going to work or get soft. Excuse me, miss.  Thank you. You have one job and it's to keep your head up and you're not doing it well.  Please just work for me. When I do to you. When I do these brick and colors today, like they all hate me. I'm sorry, what? Let's try combing this in the disappointment on my face. I don't know what to say. This is bad. Drys fast? What is drying? There's nothing drying here. I guess I'll just keep combing it until I rip out all of her hair or until it dries. It's all over my pants. This is gross. That's enough. I'm gonna call it quits on that one because that is even worse than the green one. I mean, her hair is not gonna move and it's all gross and it's all over me.  It's in my nostrils. Let's move on. Ew. Okay, lastly. We have Mofajang and it's called hair coloring material. Seems sketchy. Good thing I'm into sketchy things. This product is easy to wash, giving rise to no harm to hair quality. Yes, indeed, that is the exact sentence. I actually did read that correctly. As a disposable product, it is water soluble? What? Method of application, wash your hair and then take a little of hair clay to rub with fingers only. Then apply to your hair in a button up way with fingers gently until apply uniformly. That's not even like broken English. That's literally not even English.  So let's dip in here. Ooh. It's much more pliable than the last one. Ooh. It actually does look pretty. Ooh. And it's soft and it's not making her hair feel gross. Wait a second. Are we about to get something here? The last thing we try. Wait, I'm liking this. Well, let's give it a little comb root and it calms through. Whoa. I'm gonna go ahead and give it a little blow dry. Whoa. Definitely looks greasy. I think I put a little bit too much, but that color payoff and also my hands beautiful. Her hair is still shiny. Okay. Well, let's move on to my final thoughts about these two products. Okay. Let's talk about the Good Day Young Poser Pace. It retails for around $18. Girl, you're doing too much. I don't know what this would be good for. To be honest with you, I really can't exactly think of a good thing to say about it. You could just use so much better like so easily. It was really like crusty dusty and nasty and didn't have good color payoff. It was so dull looking and there was no shine. It's way too expensive for what it is. I just really didn't like the experience. I don't know who's using that and thinking like we should keep selling this. Is that so mean?   And then we have the Wild Card Mo Fajang, which has a label that's not even really in English. It's like partially English. And let me just tell you guys, it was the best I've used all day. That's right. This is our winner, baby. It is only $10. It leaves the hair shiny, looking healthy still. You can actually comb through it. It's soft for temporary hair color. I think this is one of the best. Also, I really do still like color stuff for certain uses. It's definitely the one that makes your hair look the most realistically colored because it is a spray. Cummings are a lot less messy, a little easier to use.  These two for different occasions, but today I'm going with Mo Fajang. I want to put this in my head. I want to see how it really works on myself. So why don't we do it? I'm excited. I've been meaning to color my hair. Oh, I'm so excited. Just go in, I guess. Whoa. Okay, this looks really cool. Wait, I'm obsessed. Wait, this is so easy. Why have I never used this before? Um, and yes guys, I do have a mullet. I've been growing it out. I know I see all the comments being like, does Brad have a mullet? I'm like, yeah girl. What did you think I was going to do? Not actually do it when I told you I was going to? Like, come on. This is like startling. How good I feel.  Literally not one person can tell me I don't look good right now. I won't believe you. It almost feels like conditioner. Like, it makes it pretty easy to comb through your hair, which I really like. A little bit more. Yeah. Always a little bit more. Let me go check it out. Oh, I mean, do I look really good or is it just me? I want blue hair now. Like, it's definitely not perfectly applied to my head, but I'm obsessed. I feel so good. If you have short hair, this is 100% going to work for you. If you have long hair, this will work for you. It might be a little bit greasy. It's never going to be perfect with temporary hair color. It does have to like lay on top of your hair and it does leave a little film, but it is linked below for you. It's amazing and it has such a good color payoff and it's so fun. Like, I'm obsessed. That was so easy to do and it was not messy and it doesn't look like that fake, I think. I feel like this should be my real hair color. What do you guys think? I don't know. Might see me next week with some blue hair. I'm also just so relieved we found something that I actually like. All right, now that I'm feeling fresh and feisty and blue, let's conclude today's video. That was fun. Temporary hair color is messy. Like, I remembered it to be protect your surroundings if you do this because it'll get everywhere. But it's a lot of fun just having a temporary hair color that you know can just come right out of your hair and you can just wear it for a day and take some good Instagram pictures and post it and pretend your hair is actually colored, which is probably what I'm gonna do today. Make sure you guys subscribe if you're not already and click the like button and the bell if you would like. Also, make sure you guys follow me on all the different social media networks. They're all right here listed out for you. Super easy, super fresh, super fun. Make sure you guys text me. This is my number. Yes, I really get all your text messages. Yes, I can read them all. Yes, I can text you back and I will be choosing a few of you to do just that. Make sure you guys follow X-MundoHair on Instagram at X-MundoHair and check out all the hair care products we have to offer down below at X-MundoHair.com. Today's Instagram goes to Jocelyn and she says, my mom of one, I have black hair. It's very long and thick. I haven't been feeling pretty with it lately as it's very boring. What do you think I should do with it? I send a picture of myself below. Thanks for any tips. Okay, Jocelyn, what I'm gonna say right off the bat is do a haircut. Do a chop, chop, chop, chop. Go to your shoulders. I think it'd be so fun for you and a good change without changing the hair color, without doing anything too crazy. I think it's an easy thing you can do if you feel like you're not fresh enough. Go get some color done. Start off with some highlights maybe. Either one of those things I think will help you feel brand new and feel so cute and fresh and beautiful. If you end up doing it, let me know. Send me a picture, I would love to see it. That's all for today, you guys. Thank you so much for watching. Don't forget to live your extra life and I'll see you next time. Bye, guys.