First of all, thank you very much for the opportunity to speak in such a beautiful conference and such an event. And of course, somehow, the subject of talk is very closely connected to what Arthur did over the years. First of all, perverse chiefs now even admits that he is part of it. And also, somehow, I will talk about infinite dimensional generalizations. So, of course. OK, so let us, I will write down a plan. One of the reasons why I want to write, because I'm not sure how far I will go. But first, this will be motivation. Namely, it will be finite dimensional situation. Second, I will formulate my goal. Third, I will talk about characters, categories. Categories of eladic chiefs on prosthetics, or maybe infinity prosthetics. Next, I will talk about, somehow, there will be some categories. Categories will be infinity drive categories. Or stable infinity categories. And next, I will say about perverse structures, perverse chiefs on, let's say, nice prosthetics. Namely, categories will exist always in very big generality. And in order to define perverse structure, we will need certain smoothness kind of restrictions, or whatever, or some finiteness restriction. Finally, I will formulate main result. And after that, hopefully, I will get in order to this, because I will need, somehow, my result. We'll use some stratification. And stratification we will need is Garevsky-Kotviksman first on stratification.  You know, it's impossible to, you see, it's impossible to live in Israel without being optimistic. Smallness, or smallness of Grotendik Springer, a fine resolution. But it is actually just dimension count, so it's not. Okay, let's see. Okay, first of all, let us start. Start, first of all, motivation. So motivation, of course, comes from, as you probably all have known, I'm coming from a representation theory. Namely, I want to apply some algebraic geometry and category theory to get concrete results in representation theory, and specifically something connected to Langlund's program. So motivation is false. So let G will be the usual connected reductive group over some algebraically closed fields. Good example, algebraic closure over finite fields if you really want to apply to representation theory. Then I want G with G is a joint function. Okay, and then you can consider, yes. No, because it's actually a very nice notation because there are three actions. One is the left, right, and a joint. Actually, so at least this self-explanatory notation. It's a quotient stack, okay. If you consider on the level of points, it will be conjugate classes, but it's also very good. Okay, so far it's, you know, art and stack of finite type, it will disappear. Okay, and then we will consider D, is the category that usual familiar category, which is, you know, D, B, C, okay, L, or L bar doesn't matter, where L is prime different from K, it's a usual drive category. And then it, it's a- This will be finite since I want to define it there. Yes, yes, but actually, actually, actually I will soon give you a way that in some sense if you work with infinity categories, that to define it actually can do without no work, essentially. We'll talk about it in a moment. You're right, of course. It's, it's still, but somehow the, okay. And then it contains very nice sub-object, which is called character shifts, which I'm not going to discuss now, but I'm going to introduce one important example, which I'm going to generalize, or at least try to generalize. Example, which is called Grotten-Dexpringer-Schiff. Consider the following, consider B cross B, which is the same as a joint quotient where B is barrel. And what is Grotten-Dexpringer-Schiff, which I will call S, this is just pi of the, maybe I want to say that somehow this is very nice tech, which is smooth of dimension zero. In particular, there is a very nice shift here, which is dualizing. The constant shift with dualizing shift are just the same. No, even shifts and twists. So it's D of B. And Springer-Schiff, of course, is of whatever, QL. And all the factors will be derived. I will not write R in any point, okay? And this morphism, of course, is proper. So I can put I as the Shiliko star, but at the moment, at least, but I will put this one. Now, what is known about this shift? Okay, known is then. What is known as is perverse. Second, that S is minimal extension, where J is the embedding into G, regular semi-simple. Regular semi-simple is the second property. Third property is that double, double affine viral group. So let us, let us, I will say even stronger assertion. The set of automorphism of S is just equal to the W, which is viral group of G. No, automorphism, not endomorphism. Group of automorphisms. No, but if you're, if you're not set, then if you're not automorphism, then the morphism algebra, which is a QL algebra, automorphisms form the units in this QL algebra, which is bigger than that. Ooh, yes, what I want.  Yes, okay. This was this, of course, of course, what I actually need, but what of course, yes. And the morphism is a fine viral group, and moreover, for if you have a irreducible representation of W, then you can consider the, is a typical component. Let us say, in this case, it's finite group and the characteristic is zero, so it does not matter. So let us, I will write down the reason I'm writing down, because I have in mind something for the fine-setting that most likely I will not have time to talk about this. But okay, so this is irreducible, okay? And this, of course, example of the character shifts and more general character shifts, you do similar thing, except you replace here B over B by P over P by parabolic subgroup, and you will replace the constant shift by the shift, which is pullback of the hospital local system, whatever it is, which George defined and studied for many. Okay, intensively, and of course, some of this is more general, okay. Now the question is what is, so first part was okay. Now we are going to our goal. Go to extend everything to the fine-setting. Okay, so I want to, so what does it mean I have to extend? I want to extend this, then I want to extend this, then I want to extend this, okay. Springer shift and this result. And the answer is that it's possible to do it, there is some small modification. Okay, first of all G, you replace by what? But the loop group of G. What is the loop group of G? Which is the loop group of G, and what it is by the definition? By definition, loop G is a factor from algebras over K to sets, right. And what is lg of a is by the definition is G of a. So as a factor is defined, now it's known by, I am not good in history. Probably Gert was the first one who quoted carefully, but I'm not sure, so I don't want to. So that's somehow it's in, it's in scheme, but in scheme in a really in scheme, namely that's somehow noted like in the previous talk, in the previous talk there were in scheme, but it was inductive limit or finite dimension of varieties. Here it's really, okay. Now you can do, now you can, let us try to generalize. What you want G over G? You want to try the same thing. Okay, now we can ask what it is. And the answer it is you want a factor from affine K to, to what you just want to group weights. Namely, you just take, you know, every A goes to, so lg of a is a group object. So this is just the group point action of the group by the group, or if you wish it's the category whose objects are here. Okay, and actually I will talk, and later I want to say that of course later I will use the remark that it's group points will be part of the infinity group points, or what is the same spaces. Now you can ask the following questions. Can one define, can one define? First question, what is the D of lg of lg? Second question, can you define this element S? Grotten-Dexpringer-Schiff. Third question, can you define the, okay, can you define perverse destruction? And for is S is perverse. And question five, let me put the same thing. Just, okay, perverse and maybe some others. Question five says that let a, let, okay, yes, what I want. Okay, maybe you know what I will say even more here. The question is whether I want here, whether I want here. This is defined by a fine while group. And question five, let V will be representation of let us say irreducible representation. Irreducible representation of a fine while group. And you can ask whether you can ask SV by using similar format, whatever it means. First of all, can you define it? Whether is, is, okay, defined, perverse, and irreducible. Okay, so far I formulated some questions and now let us say trying to give answers. So first I will give answers, excuse me. When you form the LG mod LG, there's no notification that you're doing, right? No, no notification. There's no need for notification and I will comment on this later because later I will talk about chiefs and then yes, you're right. What is the main idea I learned from paper of, I guess, Dennis, that somehow that's, you don't need to, sometimes it's better not to chiefify things. Okay, so at least for certain questions, it's easier. Then you can ask what happens whether something changed after you chiefify. And fortunately in our case, the answer would be no. You mean the group would be changed after? No, no, no, the group says yes, but the category of chiefs would not change. Category of chiefs would not change, would not somehow, before chiefification, after chiefification would be canonically equivalent. Yeah, it is more like chiefification, or is it? Yes, okay, yes, chiefification means chiefification. Yes, you're right, you're right, you're right. Okay, now let us say answers. This is our joint work on partial and mean. It's not written, so it's almost done, but I don't know. I will write in progress to be on the safe side with Alexis Boutier and David Cajdan. Okay, first of all answers. A1, A2, so the answer to this question is then says yes. Okay, A3, A4, then says yes after some modification. And in a moment I will say what kind of modification you will need, and what is the reason? Okay, and answer five. Okay, first of all, it's okay. First of all, this is SV is defined. Most likely meaning that somehow it is, so we are sure that it is, let us say, conjecture, or let us say almost theorem, but not in the sense of almost mathematical. SV is perverse, okay? Namely, that there are some, okay, we have a reason, but we don't, there are some technical details to check, but what is not true, SV is not irreducible. Not irreducible in almost all cases. For example, take G equal SL2, and take V equal sine representation. If it takes sine representation, it would not be irreducible, it would contain two irreducible summands, and actually I'm not sure what is semi-simple, most likely no. Okay, anyway, this is something that we have to carry out. For example, on the other hand, we don't know the answers for this trivial, it's very easy to answer, the answer is yes, it would be irreducible. It could, can it also be zero? For some, can it also be zero? The answer is no, because we know over the regular semi-simple, over the locus where the reduction is regular semi-simple, it's a regular representation. Now, like in the case, like in the finite case, over the regular semi-simple, it's just a regular representation. Okay, so there you go at what you should get, yes? Yes. No particular, not zero. Yes, in particular, it's not zero. You're working with representation on that fine, very good. Yes, I see. No, as I say, in the fine case, it's also true. In the fine case, it's also true. Over the nice locus, it's precisely the regular representation, and you can ask whether it's extension. Okay, I will, in a moment, I will say you. I think we need a fine value of the big translation part, what do you mean, the regular representation? Regular representation? Even infinite group has a regular representation. On the dice? It will be, it will be infinite dimensional. Like Dennis constructed, it will be not constructible. Okay, it will be, you know, okay. This D would be not constructible, it will be inconstructible. Yeah. Well, in a moment, I will define the category. No, it's definitely not constructible, you can ask. Okay, good. Oh, okay, yes, yes, maybe I want to comment on this. What you do is the following. Let N, which is not the same as N, which is actually, maybe N is not good notation, but it's, it's what is called an important school, but important to mean anthropologically important. But actually now, okay, so it's not even anthropologically important, but the set of elements with, okay, let us say with LG, will be the set of locally closed, whatever, sub, subint scheme. Size it, let us, I will write what is, it's a point. Let us do the notation, let F will be K over T. So, LG of K is of course the same of G of F. And you want that I will say what is N of F, okay? What is F valid point, not F valid point, K valid point. It is the same as G into G of F, such that the G is regular semisimple, semisimple, and also I want that the characteristic polynomial, let us say G is bounded, let us say G is bounded. But it is the same as characteristic polynomial has coefficients in OF. And I hope to be, get to a point that I will define it properly. Okay, again? And determine it is invertible or something. Yes, yes, yes, yes, yes, yes. Determined, yes, is invertible. Okay, maybe I want before, so, yes. And now what is, let me write down precisely what is, what I mean almost, and answer, okay. And answer three says the following that there exists perverse structure on, what? Why is it called N? Because I don't know what is a better term. No, it's bad terminology, any suggestions I will, I will say better after the lecture. I don't know why it's, okay, I say somehow N is, because it's like topological and important, but actually it's even not topological and important. It's bounded, I don't know what's bounded. No, but v is overused, I don't know. How do you go there?  I don't know. Okay, anything, okay, you know.  Okay, so we will perverse structure on d of g. You can ask why is this, okay, why is this condition and the answer is as follows. We'll see later when I explain the perverse shifts, somehow our spaces are very, very infinite dimensional because they are not only infinite dimensional, there is the int part and propot, okay? And it turns out that the propot is not a problem, but the int part is a problem. So let us consider the quotient, lg divided by lg. Then both lg's has int part. And in some sense, this is both of them cause the problem and you want somehow to kill these int parts. And now what I claim is that if you consider n model lg, that we essentially killed both int parts because here this end with this characteristic polynomial is bounded. And here is that all the stabilizers are not bounded but they bounded up to some letters. But it's all topology and topology is, if you have discrete stabilizers, it's not a problem. Because the stabilizer is what? The stabilizer of each point, it's what? It's the loop group of the centralizer, which is the torus, right? So it has a propot and it have a latest part. Latest part is not a problem. So this is the reason, so our restriction has actually, there is a good reason why we need it. Of course, it would not explain why we, so somehow why it gives a structure because we need more somehow. Formally speaking, we're using more than this. But if you consider a torus, these values in the north side with a two string, the loop group, I mean, you can have in the loop group some... But it's a topology. It's a topology, it's not important, we can disregard. You're right, there are plenty of, you're right, there are plenty of importance which has to be taken with care. But fortunately, the not affect the etallic carmology. Okay, now let's start, okay, the next. Now we want the part number three. I want to give a categories of the, is it maximum? It's maximum, is it? Okay, yes, and here I am very fortunate that Dennis gave talk before. And before he did a part of the hard work, except we need actually more general setting. But not much more general setting. It will be categories, okay, categories of elliptic shifts on infinity prosthetics. Okay, first of all, what is infinity prosthetic? Oh, prosthetic. Yes, maybe I want to say that because, so despite of the fact that all the objects are infinite dimensional, but I personally, very ignorant person, I only know what is the elliptic shift on the variety of finite type of a field. Even more over here, I even need only variety of a fine variety of finite type of a field. And the idea is that actually what we want to do, we want to start from this finite dimensional station and then apply category theory and hope it will solve all our problems. It does not help, unfortunately, but in some sense it does. Okay, so what is infinity prosthetic? Infinity prosthetic is a factor from a fine, oh, just a minute, what I did, I want, what was it before? I was of algebras, I know what I say, a fine opposite to infinity group weights, which is the same as spaces. Okay, and actually at least all the prosthetic, okay, the prosthetics that will actually appear will be take values in the usual group weights, but if you want to develop the whole theory, you would better to use this set. Now you want to say that now for every, so go for every this prosthetic, ah, yes, yes. Okay. No, it's not, so the funder, okay, the funder should understand in the following way. You can ask what are the infinity group weights or spaces form? It's form, infinity category. This is a category, in particular infinity category. It is a factor of infinity categories, whatever it means. This is a big thing because many people work and work in infinity category. But nowadays it's, you know, what? No, no, but let's ignore it because there is no, no, no, I want to talk to some, I'm not, okay. I want to convince you that if you use the language of infinity categories, then everything becomes much easier, but of course, if I cannot do all the details. Well, let us assume that infinity categories are like categories, which is the correct way of thinking. And there are some thousands of pages that people, Ludi et cetera wrote. So in some sense, nowadays the theory is rather settled down. Okay, one has to, of course, one has to be careful. You're right. And maybe I will, I even point out the points when one has to be careful. But still, Prostek is a certain factor. For example, the Prostek we will be interested in is this one, LG divided by LG, at least you kind of understand what it is. Okay, let's do it. Okay, for every Prostek, our goal will be to define certain category which I will write it, namely, somehow there's actually several choices. There are at least, actually will be two categories. This one and this one. This means constructible, will be small category and this will be the big category. And big category, for a big category, there are four choices, kind of, because you have to choose its category with a stack to shrink or start and you want int or pro. And for some reason, I will, I mean, I will use the same terminology as Dennis. No, actually, by the same reason, pro-based Dennis. But I might want to say just the remark that if you want something like she functions correspondence, then it's better to consider verdiadual version. In a sense, verdiadual version will be, it will be actually star and pro. So the choices that you mentioned, the pro one give different categories? Yes, it will be different categories. Two of them will be verdiadual, but two of them are not. We will be verdiaduality, but it's not verdiaduality within one category? Between the pair. Yes. But the pair is not. It's also, it's also, so, so, so, so, but some, some, some, some causes, it's something less useful, somehow. There are reasons why, why, why is, why this choice is better. And of course, one of the reason is Dennis explain it, for example, that this is, that shriek has a, has a left adjoined. Okay, and Dennis explains there was a general, you know, the category of sets, it's not self-doll. Set is not equivalent to set opposite. And it's therefore left adjoined and right adjoined, there are some, some, some, some different features. What? Okay. Okay, let's start. Okay, so what you do, we do the same, the procedure is, is as Dennis, indicated case A, let x, x will be, let's say, a fine. So the fine does, does not need to find a type of k. Then we define in dc of x is dcb xql, but I want to consider the corresponding enhanced version. So it's the infinity drive category, whatever it means. Okay, I consider this one and also it's the other one, it will be just the int. Okay, then what is, what, what is important that all the six operations, or at least four, four functors can be lifted to, upgraded to this setting. In particular for every x, y, there exists a functor which I say, as I told you, the main functor for me is this one, the shriek pullback. Okay, so fun, so good. Okay, except of course, this is almost the same category, except as I said, that it's not, it's not a triangulated category, but it's called stable infinity category. Now the next step is you want to say let x be a fine. But for fine schemes, you know x is a limit over xi, where xi is a fine or finite type, am I right? And then what you do, you define d, d of c of x, is by definition is co-limit, actually I was careful enough that it has co-limit in the category of categories, except, okay, one digression, all the co-limit will be rheumatopical limit, and I don't want to, so everything would be rheumatopical limit, or if you wish, in other words, somehow the infinity categories call, so there is infinity category of infinity categories, and in the infinity categories, in every infinity category, there is a notion of the limit. And so this is the limit inside of this infinity category. What? Yes, yes, yes, but so it is something rheumatopical limit. Despite that, of course, in the applications that we had in mind, actually what happens that x, this factor would be fully faithful, and then you can really define everything on the level of triangle categories. Then the rheumatopical limit is actually the same as co-limit one used to. Yes, but now what's important is co-limit with respect to, yes, and now claim is, it is independent, what? Yes, it is just a pullback, yes? Star pullback, as I said, our main factor is a star pullback, you have a projective system here, you have an injective trick, trick, trick, trick. Oh, pullback, sorry, sorry, pullback, sorry. So on the operation would be, okay, so it's independent on the presentation, okay? It's independent on the presentation. Now, okay, this is, okay, now functionality for any morphism from x to y of affine schemes, there exists a, okay, sorry, I forgot, okay, I will say in a moment, there exists a natural factor from d of y to d of x. But since you're doing it over a filtering category, probably the rheumatopical limit, because the higher derived direct limits are zero. No, why? Because it's probably in groups when you have a filtering category, so I'm not sure, this is the case that that's the level in the int triangle. No, no, no, it's not fully, fully faithful map. It's not fully faithful, it's very important. If you pass to homotopy categories there, it's also still a homotopy column, right? No, no, what's that say, no. I'm pretty sure, okay, if this is fully faithful, no, if this is fully faithful, the answer is yes. In general, I'm pretty sure that the answer is no, I cannot give you a counter-example on the stop. No, the transition maps. If all the transition maps would be fully faithful, then the answer, of course, would be yes. Otherwise, I'm pretty sure that the answer is no. But let me not... Because it does not... No, you know, I'm not good in finding a counter-example on the... No, but I know the definition of the calling. Okay, no, there is a notion, okay, no, as I said, send the following, the correct definition is as follows, there, okay, you want... What? Compatible system of some kind... Yes, some. Okay, this is a... Okay, maybe, actually, you know what, maybe what Peter has is correct, but I'm not sure in this... You are working some world of replacing primary categories by what you call stable and... Yes. You didn't say what it is, so we cannot... I mean, I don't know it already, I cannot know what... No, no, but... It's the calling within this sense. Okay, okay, suppose I have a category, usual category, then there is a notion of limits inside this category. There is really certain diagram, you can... Now, what I claim that suppose your category is infinity category. Then there is also essentially the same definition which says that inside of infinity categories there is a notion of co-limit. Now, what I say that each this of guy is a stable infinity category, but stable infinity categories form a infinity category, and you form co-limit inside this infinity category. Whatever it means. I'm really sure that on the level of the categories. It might be, okay, but maybe it's correct, you see. It just means part of the usual... You know, I... Yes. No, no, no, it's definitely false. So, it's definitely for, okay. Each object comes from here. What is the mapping space? The mapping space, take two objects here and take the mapping space. And you want co-limit of mapping space that doesn't come used with taken by zero. It does. It's filtered. It's filtered. Filtered co-limits. Sorry. Then this. You're right. Yes. Okay, you're right, you're right, you're right. Yes, you're right, right. Here it is. But anyway, there is this one. Okay, now is the question. Okay, now is the third. So, let X be any pre-stack. And then what you do is the following. I define, yes, maybe it's the only thing. It's better to do it here. And I want to say what is D of X is in D C of X. Or it's the same as co-limit in the same sense that Dennis explained in the previous talk. It's co-limit of D of X size, but in the sense of co-limits or inside of categories which has all co-complete. Yes. No, okay. Okay, C is, okay. Then some post C, some call, let now X be any pre-stack. Then we define what is D of X is either I something and then I will explain what is going on. The question, take any morphism, take D of A, where A is a fine. That is to give a element object in the category, it is the same thing as is for every, you want for every morphism from the affine scheme to X to give it's D of A, which is functorial in A. Is it like some I? Not just functorial, but compatible with pullbacks. Yes, yes, no, compatible with pullbacks, yes. And also some I of coherence. Yes, of course. Yes, no, yes, as I said, limits here is everything. No, it's limits of infinity category, but somehow, but here, but limits somehow, it's actually rather usual operation in the sense that it limits you essentially can calculate naively. What? No, not at all. Like here's a really a lot of coherences in there. Yes and no. No, no, no, no, no, no, no, no, no. The indexes sense is complicated. What is the object? No, no, you cannot spell out, it's true. Like to call them at these events, the limit is extremely complicated. Okay, it depends what you call, okay. Okay, okay, okay, let us give example, which is, let us give example, which is compatible. I mean, if you want to spell out, you need infinitely many data, it's true. But then you even don't try. Compatible with pullbacks. Let us say, say, say example. What is suppose you have some, well, let us say even those more general situation, it will be even easier. Where's g, x, x, everything is finite dimension or affine. From these forms, we want one, then, of course, lg goes to lx. Then you can consider what is the drive category on lg over lx, model lg, okay. And then you can ask how to calculate it. And the answer is that actually, it's sort of, it's easy to calculate and you write the same bar complex that people would assume. Somehow d of lx, lg, limit of what d of lx, d of lg. And it does not matter whether you put errors in this direction or not. But now, what's important, somehow, it's told that somehow, usually, you can see that the drive category on some complicated object of the simplicial schemes. And usually, it's very, very complicated object. Here, you in some sense do the same, but you package the difficulties differently. You just write the same diagram as before. This is the usual bar complex. And you just take, take limit, but limit has to be taken in the appropriate sets. If you try to spell out it, it's impossible. But in some sense, it's an advantage you even don't try because the only thing what you have to do, you have to use some certain properties. And why, okay, if you wish why, and the reason is that lx, model lg is just called limit of this diagram. And this, after you spell out the definition, it's essentially, it's almost a tautology. If you write the down, down, down, what is the definition of collimits and you use that collimits in the collimits commutes with base changes, then some, some, some, some. It's just, remember that we are in the category of functions, right? So you should check any, any, your test affine scheme and you calculate its value here and value here. And then, then, then it's just some general nonsense, so, speculation. So, so, so it just needs some factorial properties. Yes, and this, from this is essentially a tautology. So this kind of definition, what it is. The only, somehow, the advantage of infinity category is that if you try to do in the derived categories, in triangulated categories, there's no limits. You cannot, you cannot even write this thing, you can write, but usually it doesn't exist. There's no limits inside triangulated categories so the limit is often good categories. Okay, now let us, somehow, now we can ask what about perverse shifts? Okay, as I said, somehow, on perverse shifts there is essential difficulty because, you see, perverse shifts, it's something about, in the definition of perverse shifts there is a dimension involved. And here everything is infinite dimension. You can ask what you can do in order to overcome it. Okay, but let's start. Perverse shifts on some rest x. What you do, of course, the same thing that we did, did before, but then you have to be a little bit careful. Okay, first, you won't let x be usual finite dimension of what I say, a finite, which is not necessary, a finite type of k. Then, then you can ask the following, okay, then your d of x has a perverse t-structure. The problem is that now you want that this t-structure nicely behaves in a functorial way. Problem is that if even it takes the nicest possible morphism, which is smooth, no, nicely. Smooth then is somehow t-exact only up to a homological shift, all right? Because there is some homological shift, and therefore, if you take limits, it will be infinite homological shift. It's not good because we don't want to get something. But there is, of course, the very easy solution, how to overcome this problem solution. We consider I shifted perverse t-structure. For example, let us say x will be equidimensional. So what you do is you just apply a homological shift in order to make it compatible. So you define, you say that d is db, is, let us say, I shifted perverse, if and only if, if and only if the f, I hope I do it correctly, is perverse. For example, that you have to make in the line, the dualizing shift is perverse in this new shifted t-structure. Sorry, if x is smooth, then you want the dualizing shift is perverse. This is what, x to the, sorry, it's ql, twice dimension, right? And you want to check when this perverse, the answer is when you minus this, it will be perverse. So just shift it in the correct direction. But now what is nice about this is that somehow the shift only depends on the x. So for every x, you know how to shift. Of course, there is some small technicalities what to do in the noticable dimensional situation, but I don't want to discuss it. It's possible to do it, and unfortunately there is a more than one solution, which I don't like. I mean, there is one solution which is true in general, but there are the other simple solutions which would have worse for functorality properties. Which is enough for many applications. But nevertheless, what we do, we just take the usual perverse shift, perverse structure, and then you shift it by dimension. Then, okay, this is what we did for the, let's say, for the finite type. Now b, okay, definition, let x be, okay, say x, say definition, let x be, an affine scheme, x is called placid. If x can be limit of xi, xi or finite type at all transition maps are smooth. For example, there is a, all the, all the, some from example, if you take, let's say, L plus of g, or let's say any R groups of this type. So it's just projective limit, projective limit of something which is all the transition maps are smooth. But in this case, we defined, okay, in this case there is a claim which is actually easy exercise to see that, that's what, what is our category? Our category that we know that dx, dx has a unique t-structure such that all transition maps, such that all maps for all t-exact. Why? Because I forgot whether this exists, oh, it's already, yes, because what is this guy? This guy, it's co-limit over dxi. So, let's see. No, but if you shift all of them, as in this, by the same integer. No, no, it's not the same integer. In, it depends on x. On every x, I change it by the dimension of x. Yeah, but in the claim, you say all maps, no, no, no, no, no, but t-exact with respect to shifted t-structure, in shifted t-structure, the shift depends on the xi. Okay, okay, okay, you are doing, yes. Yes, so this is that with dimension, okay, yes, yes, okay, I say it's possible to do it not because it's actually locally equidimensional case, but actually you can do it even in general, but let me ignore this issue, because anyway, I have to finish very, very soon. Okay, and now let us put c. And now, what is the functoriality? Functoriality says the following, okay, is a claim if x, y is prosmooth, then is t-exact. No, it's essentially general nonsense, because. And now we want to do the general case, okay. Now you want to do something which is not a finance case, but let us consider, let us do an example, which is essentially what we do. Let x will be a quotient, e x by r, no, mean quotient x by r, where we have the r is, where you want that x and r, sorry, r is what its prosmooth groupoid in placid affine skips. Okay, let's not discuss what is prosmooth, but no, but you can say it's the following. I guess I'm going for this purpose, it's enough to show this is the inverse limit of finite dimensional, this is infinite limit of finite dimensional, and you can assume that there exists a presentation such that it's the inverse limit of the smooth maps. Let's say this is not good enough. Okay, this is, and this is enough for this purpose, because you remember some how all the categories are coming from finite dimensional level. In particular, everything actually comes from finite dimensional level. Okay, let us do of placid affine skips, then what you want to say is that d of x, r, which is remember what it was. It was a limit over dx, d whatever, it was r, d of whatever, what was r, r, x, etc. All right, the request has unique t structure such that what you want that it's pullback is t, exactly. And the idea is very, very simple. What you want? You want, for example, you take any object here. You want to write it as exact sequence of less than equal and greater than equal. Take it here, consider this diagram. Take it pullback here, pullback here, and pullback here. Here, here, and here, you have already t structure. So you know how to decompose this as the exact sequence. And now the fact that all the maps are approximately means that they're compatible. So you define, for example, that the corresponding exact sequence here as the limit of the corresponding exact sequences here. Of course, one has to write it, but it's essentially formally follows. Okay, and now I have roughly zero time, but okay, yes, and now maybe I will say d the last time, unfortunately our space n is not like this. But now assume that our space x has a stratification, x i sides z, all x i has t structure. Then what I claim is that there is a general thing which is called co-gluing, that you can glue t structures on each of the x i's, and then you get the t structure here. Aren't you basically in the set up with g is acting on x, five dimensional affine, and aren't all these maps from lx times lg to lx, et cetera? Okay, okay, no. Right, but even on lg mod lg, why is it not pro smooth there? Which one? If you want to advance to lg mod lg, are you not in the situation where this is pro smooth before it, in this sense? No, no, no, because it's int. If it's l plus, if it would be in the case of l plus, everything would be perfect. No, no, if it would be in the case of l plus, everything would be perfect. Our problem is that lg is not smooth, because affine gas mania has an inductively limit of projective schemes which are not smooth. So lg is not smooth, this is the problem. Okay, and then sometimes I'm gonna say this has a stratification, and then there is by gluing, we are done, and might be one last thing. What I want to say, let me, I will just one last sentence, I will say what is the affine spin per shift, and say that what is, yes, let us say affine spin per shift. What is affine spin, or grotenic spin per shift, of course. What you do is the following, you can see that it's i over i, where i is the corresponding eva-hori, or might be l plus of i. There is a map from lg to lg, there is a projection. Now, the claim that this map is in improper sense. Yes, actually, it's better n, because it's compact element, so you get up here, and actually you need regular semi-simple. You remember somehow n was regular semi-simple condition. So you want, so then first of all, I say that this has a left adjoint projection, and you define s is the projection of the corresponding ql bar, shift here. And the assertion is that first of all, it's possible to define a t-structure. Namely, it has a stratification by the guys which we defined before, almost after some nil-potence that I didn't have time to discuss. And then it's also in, so the assertion is this perverse and equipped with an action of the fine-bile group. Thanks. I've been already many questions, so more questions. I mean, how critical is it that you use shriek instead of stop for that to define everything, because in this so smooth setting, the two don't really differ, right? It's interrupted a little bit. Critical. Well, okay, the question, first of all, the question is, what does it mean critical? It's more convenient, okay? You can ask whether they can define everything. Okay, most of the, okay, many of the things here, it's, let's say, the situation is false.  Pro-unipotent actually does not matter. For those, probably, it's not very much different. In general, it's more convenient to work on this one. But on the other hand, many of the results can be translated. And of course, I did not talk about the proof, but actually in some point, for the perverse, you need the shriek stock and the start stock. So in some sense, we need some kind, you need more operations. I say that the start shriek pullback, sorry, exists always, or the others exist only under some assumptions. So the answer is, let's say, I don't, okay. You can ask whether I can do it in the, for start. I did not check it. Possible, the answer is yes. But then there is the indirection when you start, this is one problem. No, no, no, no. But then of course, you have, instead of taking the shriek shift, you have to start shift. Of course, okay. There is a good chance that everything would work. In general, shriek is more convenient and, okay. By the same reason that Dennis explained it, there is a difference between right adjoint and left adjoint. But I'm not sure, let's see. So I invite you to continue the discussion with me.


Thank you. Welcome to my talk. It's an agile team. Just have people. I'm Simon Cohen. I work at Spotify But before I worked at Spotify, she mentioned I'd worked at other places and one of the places that I worked at We had a team of engineers where I was also an engineer and we were doing a bunch of different Stuff that had some agile practices in it like with their continuous integration. We had unit tests We had some pairing. We have many different practices, but we didn't use any of the teamwork practices They would see scrum or any of those things none of us on the team actually had any experience with it and Except for one guy and this one guy he had a lot of experience with teamwork and agile practices and he Really pushed us to try and Implement scrum and do any one of those practices. We always push back or like we don't need any of your stuff You know, we're productive. We're putting stuff into production. Everything's working. Well, we have testing. We're you know Doing XP practices. Why do we want any of that hippie stuff that you're talking about with all this scrum and all these extra Meetings and all these extra talking about stuff. We don't want that but he kept chipping away at us And eventually at some point he got us to agree to try something and The thing he decided he wanted us to try was daily stand-ups That was the part of scrum that he wanted us to start with so we agreed He said all right. Well, we'll run this for an experiment. We'll do it for a little while and see what happens so every day for a Few weeks we would stand in a circle kind of like that and we would usually stand in the same place relative to the other people because of where we sat in the room and We would go around and we would check in and talk about what we had done the previous day and what we were gonna do that day and We would do that every day for a while Then at one point this one day the data scientist that would usually stand to my right It was his turn to talk and he just he stepped back and he held his forehead and he scratched And he was thinking really hard trying to explain what he had done the previous day Eventually he stepped back into the circle and he said I'm analyzing data and he took the baton It just gave it to me and I took it and I'm like, oh, okay Well, I was working on the same data set that he was I was cleaning it He was actually knowing what to do with it, but I was like, uh Yeah, I'm analyzing data to pass it on to the next guy and then the baton kept going that way And you can imagine that basically for the next two weeks or so. That's what happened with the rest of the team It just evolved into yeah, I'm analyzing data. I'm writing code. I'm testing stuff and that was it It took us about four weeks until the whole experiment of introducing scrum or any other agile practices for the teamwork Completely failed and then we stopped doing that and we never talked about it again so that's how I saw agile practices being introduced as a failure and it wasn't until I had joined Spotify and I was a year into my term at Spotify that I was sitting on a deck kind of like this in California on vacation and I was reflecting about that year that I had spent at Spotify and I was wondering what had I learned What did I know from working at Spotify for a year that I didn't know when I was working at that other place Well, we tried to introduce agile and failed and I thought you know I'd be really interesting to try and capture everything that I learned and try to maybe kind of share it Because people really like what Spotify does and a lot of people from outside of Spotify. They don't really know what it looks like So I kind of set out to sort of write a letter to myself a kind of message in a bottle through time To send to pre Spotify Simon with the capturing of like hey Here's what you're gonna learn after you will have worked for about a year at Spotify and Here's kind of what I've learned And I first came into Spotify During the team the first thing that I started working with Immediately what I saw was a lot more structure a lot more process than I'd ever seen The first thing that I saw was something like this. You can see there's Trello board She probably all familiar with and this is something that we would start using at Planning sessions start seeing there were this notion of planning sessions We would sit down every sprint about two weeks for an hour and we would talk about what we were going to work on and we would populate the to-do column and then during the sprint we would move stuff from there to do into doing and Move through that process. So that's a bit of a con bun flow But inside of the scrum because we're doing some scrum bun kind of like mixing it up We don't really adhere specifically to how we do things So after the planning you see stand-up now you can see here There's a gross violation of stand-up rules people are sitting down, but I guarantee you it actually works And we go through everything that we've talked about you know the usual stuff in stand-up What did you do yesterday? What are the blockers? What are we gonna do next and then we move on? We have retrospectives at the end of every sprint we talk about what went well what didn't go so well and What were the learnings and things that we kind of picked up along the way that info into these other two categories? Pretty much every retrospective at Spotify follows those three categories in general. There are other versions of it But that's that's the main stuff All right, so Yes, but why you're probably wondering I know about scrum I know about combine why you tell me about all this stuff Why am I here instead of out there drinking some really nice filter coffee or chai or at that other talk that sounded Really interesting, but I came here Well, that's a great question because when I sat down to think about That year at Spotify. I was really wondering what happened in the first team that I worked out where agile failed We try to introduce it and you fail. Why did that fail? Why is it working at Spotify? So well So one of the real issues I had is that there's a sort of minimal set of practices that you have to have It's the minimal set of things that if you want your team to actually succeed And you want the team to actually observe that there's something useful in doing this you need to have these put in place You can't just put daily stand up and go that's it. It works and Through that thought process. I also realized that one of the things that's missing a lot for me And I think was missing conversations. I was having even at Spotify was trying to understand Well, why does it work? Why do I need more than just stand up? Why do I need the planning session? Why do I need the retrospective? What do I need all these things? What's the minimal set and why why does it actually work? So Do you want to know why?  All right, good. So at the core of every high-performing team is this concept This is the very very foundation What we do is you're learning and you're learning to get better This is what we need to do because one of the things that a lot of people Look at teams and they go like okay This is a high-performing team and they put a label on it and that's not actually accurate because the high performance is not a static label It's not like I have a team the high performance put the label done high performance is a dynamic label It varies with time even high-performance teams have Chuffs and they go down in performance and they go back up and what they're basically doing is they're adapting Because every team in every situation that we have in life has to adapt because the environment the external circumstances are always changing and Us as humans what we figure out the way to actually Adapt is by learning you observe what's happening you figure out what's changed and then we change ourselves so that we can adapt to the Environment that's what we're doing and the best way we know how to do that is to learn So high-performance teams at the very very core what you will see them doing is they're actually learning They're actually observing their environment. They're actively scanning to see what's going around them And they're using that to learn how to improve them so So what's a good way to actually learn? Well, there's this concept called the PDCA cycle first thing to know them about it It's a four-letter acronym which is fine because it's not a computer science term So it can be four letters and it's also it's a cycle and that's kind of important You'll see that throughout my talk that cycles are kind of the key thing to think about the PDCA cycle itself Is basically for repeatable steps first thing that you do is you plan? The next thing that you do is you actually do what you plant then you check to see Did the stuff that I do actually produce the results? I was expecting in my plan and Then at the end of it you act or you adjust some people use it as a just instead of act that adjustment is saying Or I'm gonna take everything I learned from having done and then checked on it And I'm gonna feed it back into my next plan. That's the basic idea And you're probably all very familiar with it In how it looks is scrum. The first thing that we do was how the planning session in the beginning of our sprint That's our plan for the PDCA. The next thing that we do is we'll actually do the sprint That's the do part of your PDCA Next step after that is a retrospective. This is where we check sit down with the team and we look how well did we do How close are we to the sprinkle? Was the sprinkle effective? What do we think we learned about what went well? What didn't go so well? How do we want to adjust to the next step and that's actually what you're going to get in the next one Which is capturing the learnings and actions from our perspectives and you feed them back into the next loop and normal stuff that you see around these kind of things to be changing whip limits changing behaviors for the teams changing sprinkles Anything what I want you to see here is that scrum itself at that level that sprint work is basically a PDCA cycle That's what we're really doing scrum itself the reason that it works though the engine behind it Is is it's a learning tool beyond everything else might in it's really just a learning tool PDCA In and of itself is a Is actually rooted in the scientific method and the scientific method looks like this First thing that we do is we ask a question and then we set up a hypothesis Think something will work this way The next thing that we do is we experiment with it We actually go out and we run an experiment and all we do in the experiment itself is we're collecting data This is if you look at it is really the due part of your PDCA cycle We ask my hypothesis of the plan the experiment is to do then you move on to analyzing the actual results We're looking at it. Okay. I'm gonna look at the results of the experiment that I ran Look at all my data and then with that analysis I can move on to actually conclude whether I reject my original hypothesis whether I accept it And then I can feed that into the next set of questions to the next hypothesis So when you look at high-performing scenes you see the stuff that happens in high-performing teams It's part of that for example when the ones that are going well and the ones that are working well They are actually doing things that will come like that it part of their scrum It's part of the regular basis of working they are doing lots of experiments for those of you are here for the previous talk This is the same kind of concept constantly running experiments We're constantly trying stuff and then we're checking on it And we take conclusions of the learns we have from what we checked we feed it into the next cycle And we keep getting better and better over time so That's kind of the idea of how PDCA works along your scrum Now we can play a short little game There's actually a secondary PDCA cycle that happens inside of the scrum and The little prize anybody thinks they know where it is raise your hand Anybody any idea where there's a secondary PDCA cycle that occurs in our regular sprint work that man wins the prize Throw you a little catch it Close enough. All right, that's true So Daily stand-ups actually it's a little bit tricky, but what daily stand-ups do is they actually start the PDCA cycle at the checkpoint First thing we do is we get together in the day for do the actually there you stand up and we're checking What did we do yesterday? What's changed? How did it go? Are there any blockers? Where are the pull requests of Terra Terra next thing we do is we act Maybe we decide that we need to unblock. Maybe we decide we need to move something from doing to done Okay, once we've done that we make the plan for the day. We take new stuff from the from the to-do column or Planning or whatever name of the column that you have if you're working with a kind of con balm Flow and then we move it on into doing and then the doing is what we actually do for that day in the next day We go through it again Now what you're seeing here is basically one of the main differentials between Waterfall and agile waterfall is about predictive planning I make a plan with an intention to try and predict what's going to happen in the future as much as I can whereas in Scrum and an agile what we're really doing is we're creating adaptive planning and the daily stand-ups are really a way to Constantly adapt to what's happening at the micro level The scrum is a slightly bigger level and then there are even larger cycles that happen inside of every company Happen inside of spot as well. It could be quarterly. It could be yearly It could be any length of time that you need and what I'm trying to show you here And what I want you to take away is that if you look at a lot of these cycles and a lot of these processes that we have We basically wrap them inside of a PDCA cycle What happens when we do that is that we're actually creating a learning environment around every cycle that we have So almost everything that we do effectively generates learning and we're very very kind of anal about it Making sure that we're always going through and checking and checking and checking whenever we have projects that maybe took six months long We'll have massive retrospectives. We'll spend a lot of time looking at that So the idea is that you want to be able to look at the organization You want to find where you have cycles you want to be able to? Wrap them in PDCA's so you can actually learn there's one other part about this That's really important to understand is that PDCA says is that you need to start by planning just like the scientific method you need to start with hypothesis a Lot of places you will see in a lot of times even at Spotify You see people that don't actually start with that they just go when they do stuff and they try and experiment a lot And that's very good wisdom. However, there's an advantage to actually setting out with an explicit hypothesis and The example is this if I think that I found a problem something that I want to change something I want to do in the system or my product or whatever it is and I go and experiment Great thing could happen is I try something and it works. Awesome. I saw the problem What if I try something and it doesn't work? Well, what you usually see is people say then you go and you do because analysis you figure out what went wrong Okay, well, you could do that and you figure out what went wrong and then you do that again to try and sell the Problem you still didn't solve it. Why? Don't know would cause analysis do it again do it again and again and again and that will work But that's basically trial and error and the problem with trial and error is you can keep trying it And who knows when you're gonna actually find the right solution You will eventually probably because we're smart people will figure it out The difference between that and the scientific method is that we're setting up hypothesis We actually have an idea in a theory of why something should work and when you set up hypothesis in the beginning of any PDCA cycle and then at the end of it You check on it. You get this extra nice benefit. She say I didn't get the result. I want it Why was it was it because I didn't do the experiment? Well, did I fail at implementing what I thought I wanted to do or did I not analyze the situation properly? Maybe I didn't look at it. Maybe I thought the problem was here, but I really had problems here So now you have the ability to separate and ask yourself an even better question How well am I doing and analyzing my actual situation? How good am I at actually implementing solutions? Those are two very different things and by actually setting up hypothesis up front You can actually learn a lot better.  So that's kind of important and in terms of practice What you ever you do make an experiment That's kind of the only thing that I can say about this if it's a cycle wrapping the PDCA Whatever it is that you're doing and people have said it here Just try it if you can set up a hypothesis up front set up a hypothesis Don't spend too much time on it But at least have some and I some idea of what you're aiming for and why you think it's going to change Whatever you're changing in that direction So whatever you do Try to make it an experiment that that includes spring work that includes You know trying out new behaviors for your team that includes Whether or not dogs should be allowed in the office. It's all good. It's all available for experimentation. I'm sorry Explicit hypothesis spring goals themselves are usually specific hypothesis We think that we're going to be able to move this metric and we're going to do that in this way So those those can actually be used if you frame them in the right way with a crude definition of done You can actually use spring goals as an explicit hypothesis. I'm hoping that answers your question Yes, you can you can use that the main the main point of trying to create the explicit Hypothesis is as I said is you want to capture what you thought was the actual problem Or what you thought was a situation because you want to separate What happened in terms of I did all this work, but did I screw up the work or did I do the work?  Or did I screw up analyzing what the situation was? Because then you just different responses to both of those situations And that's the actual value that you get by actually experimenting and by being a scientist by thinking about that So you want to be able to create this Good question Great, you're probably thinking we're done. That's it right well scientists. It's great We have high-performance team into the core that our learning will adapt to anything anybody throws our way We can just go out there now and it's all great. Well, no, it's not that quite that simple Maybe I told you I was sitting on that deck back in California long long time ago I was also sitting on a deck and reading this book This is a book that proves the phrase of don't judge a book by its cover. This is an excellent book It's called leading teams. It's written by J. Richard Hackman who was an organizational psychology researcher That wrote this book sort of as the culmination of the work that he had done over about 50 years five decades in that field of organizational psychology research and This book is all about teamwork and he had done work in many many different fields from airplane carriers and Hospitals You name it every other type of industry you can think of manufacturing all of it and the stuff that he puts in this book It's really talking a lot about the theory of what makes for a great team And that's the theory that kind of applies across any field and of course also applies in software development in the agile world that we live in Now what Hackman talks about is this concept of effective teams. Well, I'm highly effective teams We usually talk about highly performant teams. He talks about highly effective teams Now that actually brings up a really good question. It's a difference between effectiveness and efficiency Well in the agile world a lot of the stuff you see us talking about has to do with efficiency We talk about velocity. We talk about throughput. We talk about our deadlines We talk about all the estimates that we're going to put on cards or no estimates We're going to put on cards. There's a lot set up about that and efficiency is really really important however, efficiency is only one dimension of actually being highly performant and Effectiveness is something I think maybe a little less is said about in terms of teamwork Not in terms of product in terms of teamwork and that's something that I want to go through a little bit more in detail luckily we have a quote from Peter Drucker who was an American management consultant and he says this Efficiency is doing the thing right Effectiveness is doing the right thing So as you can see here, that's kind of a big statement, but it's a really important one So if you think about it, if you're working really well and you have no losses, no waste, nothing Everybody is at 110 percent efficiency But you're building the wrong thing Doesn't matter No, it doesn't you won't get any results you're building the wrong thing if you have the most fuel efficient car in the world and You're driving to the wrong destination Doesn't help So that's the extreme case. So let's talk about not the extreme case of where most of us live and we'll use a metaphor Suppose we're all going on a hiking trip now and we have this kind of backpack That's our backpack and we're gonna go away for a week Quite a bit of time.  It's really long. It's really big What do we do? We have this problem. We need to pack stuff. It can't fit. That's the backpack we have Right, we can try and increase the size. It's not gonna happen. There's only so much weight You can carry. All right, this is it. This is the backpack. We have this is the trip we're going on How do we do this? Well, the most obvious way that you can start with is like I'll pack as many small items as I can get in there Turns out maybe that's dried fruit. Great. Now I have a backpack full of dried fruit Is that gonna sustain me for a week of hiking in the Himalayas? Probably not. I need more nutritional value. I need protein. I need carbohydrates. I need fiber I need fat. I can't just live on dried fruit for a week while I'm hiking in the Himalayas So I need a different way of doing things So usually what we're doing is then we try and max, sorry, we try to like max, maximize our Efficiency by mixing different things of different sizes so we can get everything that we want. That's what we're trying to do There's a different way of, slightly different way of looking at it and asking yourself the question is When am I actually trying to do here? What's the problem in front of me? Well, the problem in front of me is I have a fixed-size backpack, right, certain capacity And what I'm trying to look for now is the stuff that I can put into this backpack for this one week That's gonna give me the best solution for weight that I'm carrying for the volume that it actually takes up in my backpack And for the nutritional value and that's the key part about it You want to see that you get the nutritional value that you want from that volume and that weight So what you're really kind of looking for are these things these energy bars which are by the way available here in India And these energy bars are actually the solution to that problem They are the highest density in the lowest weight For the best nutritional value. In theory, you could spend an entire week with a backpack Full of just these, not even full, that's the great part about it, right? This is what these energy bars are kind of trying to do. They're trying to give you the nutritional value that you need for the entire ride In terms of our backlogs, this is kind of What it means to try and be effective about what we're going to select to work on. It's not just about how many cards can we jam into the next sprint We're really looking for these energy bars. We're looking for the ones that we can put in there They're gonna actually create the largest amount of yield, the largest return on the work that we put in and the yield can actually be looked at in some way as the amount of value returned over the time spent. And that's that's the idea in those kind of selections. Now in terms of what it looks like in practice for teams This should look very similar to what you already know because there is a lot that's said about effectiveness in the agile world around product management There's Lean, there's Toyota Cata, there's Value stream mapping. There's a million things What they boil down to and what you can see at least also in Spotify is one of the things that we do pretty much all the time is to try to visualize all the things. Visualize all the things because what we're trying to do is we're Trying to capture the stuff that we're talking about outside in the world. Our brains are actually better at being able to look around and once we put stuff around Visually in front of us. It's easier for us to activate more parts of our brain to actually be able to make Comparisons and make sense of our world. It's just how we're set up and The reason we visualize other things part of the reason that is because what we're trying to do is we're trying to actually sort them Trying to like figure out what they what they are and what makes sense. What order we put things in So pretty much most of the time in terms of the heuristics of what we're doing is we'll visualize everything think about trailer boards They're a visualization of the work that we want to do But then we're trying to just sort Those things for the top-end things that matter to us for example and could be your whip limit for the sprint It could be other things in other examples like in retrospectives. How many actions are you actually going to work on? Right, you have to choose you can't have all of them if there's 50 actions You're not going to implement all of them So you have to sort for them first you visualize them then you sort for them and one example of an anti-pandemic that I've seen people do You say they can have backlog grooming sessions that go on for two hours every sprint because they go through 45 things in the backlog Over and over again trying to sort them and update them. It's not important It's not important because the next thing they're going to do is only whatever that whip limit is at the top of it So once you have your new top once you have they say you're three or four or five or ten Items at the top stop sorting. You're done for that sprint move on That's actually the point that I want to make here save the rest for later Don't worry about it. That's the idea of prioritizing. That's what it needs to be effective with time Remember what we said is efficiency is about how well we use the time that we have and effectiveness is about what we're using it for What is it going to be used for so we have to prioritize, you know It's in order to know what we're going to use our time for and that means the last thing which is you have to get into the practice of letting things Fail, that's the point of prioritizing when we prioritize we say here's what's important and that means that the other stuff is not as important and That also means the other stuff can maybe probably fail That's what we're saying and that's okay to say it because if everything is important then nothing is important So you have to look at that and you have to say to yourself as I'm doing this as I'm prioritizing This is what's important for now or for the next sprint or for whatever time period and everything else may be important May not even be relevant by the time we finish the sprint or by the time we finish this quarter and it's okay if it fails because We figured this is more important than the rest and if we get this done and the rest failed We know that at least we got the most important stuff done. That's what you're looking at That's what the order was well also said the nine tenths of wisdom is being wise in time Effectiveness is all about thinking about how you're spending your time This is a thought process. It's a bit meta and it's another practice of habit that I'm trying to Have you see here? That's really important if you're spending your time thinking about how you're spending your time That's good. You also have to think about then another level of inception of meta How much time am I spending thinking about how much time am I spending all right? You don't would you sit down for five days and do a planning session for a two-week sprint? Probably not maybe you'll do an hour. Maybe you do five hours. You have to figure out what's right for you based on the task So that's that's what you have to constantly be thinking about am I spending the right amount of time Figuring out what I should be doing So that's the point I'm trying to make here is be effective prioritize prioritizing Now we've talked about those two aspects of being a scientist of learning and being effective We also need to ask the question then what do effective teams actually look like? When you see one what do you actually see well luckily Hachman actually talks about that and he has the three traits of effective teams That's in the book that I mentioned in leading teams and they start with the first trait which is Teams that are highly effective serve the clients well these traits are things that you're going to observe About the team if they're highly effective you will see that they are doing this you'll be able to observe them So serving their clients well as the first one second one is they continuously improve and the third one is The members of the team find personal development and fulfillment from work Many of you are familiar with the three P's what you're looking at here is product process people That's what they basically sum up to so let's go through them one by one for clay Serving the clients well That's defined by Hachman as the teams output meets or exceeds the client standards This is actually kind of a key point to understand your team itself Cannot define whether or not it's doing a good job Just cannot do that that doesn't work. They can't tell if they're doing good quality work or not That's based off of Hachman's work. That's based off of academic research So who can define if your team is doing a good job or not? teams clients Whoever is consuming the output from the team if the teams producing documents specifications shipable code Mobile applications it doesn't matter whoever is on the other end of it who's consuming the output of your team They get to define if your team is serving them well or not They get to define the quality level of the work of your team So you want to have that in your mind and examples of doing stuff like that is user acceptance testing Which is the most obvious one because it's right there You go to your user and users says if it passes this level it meets my standard And then you go ahead and you hack on that and you're done every time your code runs and it passes to your acceptance testing It means it met your clients standards So that's kind of an obvious one a be testing is a maybe slightly less obvious one But how do you know if you're serving your clients? Well when you were building a mobile app and there's millions of users you can't ask millions of users to give you Acceptance tests just not gonna happen So you a be tested it's part of what you can use a be testing for you actually look for ways to get Feedback from your clients and whether or not the stuff that you're building something they want to use So it's another example of that And of course you can just ask And the infrastructure group that I've worked in spot-a-five the last couple of years We do a lot of that we send surveys we ask our clients We try to find out what they're doing and what they think we asked them what sucks the most about our infrastructure We keep getting feedback for them to find out where they think we are where you think we need should be and how our quality is So the next part or the next trait is continuous improvement and Hackman defines that in the book as the team's social processes for doing its work Enhance the team's ability to work together in the future It's a big big statement. There's a lot in it. I highlighted the words that I thought were kind of important We're focusing here in improvement for the team around the social processes That are trying to make the future better for working together better. That's what you're looking for So this is about how people are working together in your team But the orientation is towards the future. This is not about tactically How do we get this print right now or this meeting right now to go better? That's just the right now what you're trying to do with continuous improvements. You're trying to help the team Do meetings better do sprint work better as a whole it's a statistical move That's kind of a mindset you have to be thinking about that and examples for continuous improvement The things that you do for social processes are Collaborating looking at the team and seeing highly effective teams will be collaborating They'll be supporting each other people in the team will support each other somebody's struggling somebody needs help They'll go on they'll help them maybe pair program with them. They're giving feedback to each other That's a great thing to see in teams and by the way, we don't see enough of that at least in the teams that I've worked with Holding people accountable is also a very very good one This is about you said you were going to deliver this and you didn't show up We need you to do this or you're blocking my my pool request. I need you to unblock me This is holding people accountable and it's a very important habit to see so you can see that people in your team The team itself is not blocking for too long where people are actually changing their behaviors in a way That's actually making the team work better if you collaborate better So that's all around continuous improvement in the next part that we're going to go to Personal development. These are actually going to be anti patterns I'm going to talk about and what you look at highly effective teams And you don't want to see in a highly effective team, but you do see in a lot of other teams So the first one is senior over junior senior the people are more important than junior people They get the really interesting tasks and the junior people and not so much to get the scraps Okay, that's not good Because people are not going to be happy. You want people all the people in your team You want them to feel like they're developing you want them to feel like they're actually continuously proving themselves You want them to feel they're fulfilled So stratifying your team is saying senior people get this good work and junior people are getting like all the other work And when they get to be senior, they'll do that. It's not a good incentive.  Sometimes you have individual Incentives or compensation methods like bonuses etc that are driving people towards the wrong kind of choices And that would look like stuff like I'm the expert on a team on Jenkins Jenkins breaks all the time So I'm indispensable to this team can't fire me You got to keep paying me a lot of money because without me your team is not going to deliver anything And I'm not going to teach anyone because I have the secret and I have the knowledge I don't want to share that's another big anti pattern for the personal development and for the fulfillment of everybody in a team Because it stratifies the team. It actually makes everybody compete with each other Instead of people Collaborating with each other because there's incentives there. I either get a better bonus Well, I get to keep my job. I have job security. Whatever it is, of course never shipping That's kind of a big issue if you have a team that you see around that over and over again It's failing to ship or the stuff that they ship doesn't get used because their projects get destroyed or they get Defunded or whatever it is. That's going to be a problem over time People on that team are not going to feel fulfilled because you have to close that feedback cycle I write something ship it people use it I get some kind of feedback if people are not getting that feedback Then you're not going to see people who are happy and eventually you'll see high attrition. They're going to leave that team They're going to get frustrated. So solutions around that usually go back to things like MVP You want to like start cutting scope as much as you can to start creating feedback cycles that are meaningful to people Where they're actually shipping stuff that gets used you have to start looking into those kind of examples Those were the three traits that we that I just mentioned which were Serving the clients well continuously improving and personal development and fulfillment. What do all these traits have in common? If you look at them those three traits They're all actually cycles That's kind of an interesting thing because serving a client's well isn't something you do once and you're done Neither is development of fulfillment fulfillment by definition is cyclical like we said It's a feedback group and continuous improvement also by definition. It's something that always is happening So these are cycles. What do we do with cycles? You wrap them inside of PDCA Why because then we learn how to do it better. We learn how to get better at serving clients We learn how to be better at continuous improvement And we learn how to be better at having people who are happy and joyful and working and developing themselves and getting fulfillment from work That's what we do when we see cycles. How have we done that at Spotify? That's kind of an interesting twist on what I learned in that year working as pop actually now. It's two years when I wrote this This talk we added people and This is this is kind of interesting because what we've done actually with our Spotify model Which I hope you are familiar with is that we've created roles that are very specific First of all I'm talking about is product owner product owner serves clients. Well, that's their role their role is to Nurture the trait in teams that says these teams are serving their clients. Well, they are delivering on time They're delivering the things that matter to the clients. They are actually they're Doing the job that matters to the teams clients So there's a person whose responsibility is to nurture this trait of an effective team The next one is an agile coach. The coach's responsibility is to make sure that the team is continuously improving That's their job. That's what they're there for The last one is chapter leads. These are line managers and their job is to actually make sure That the members in the team are developing and that they have fulfillment in their job So as I've shown you here now, we've taken the three traits and we've actually split roles That are responsible for nurturing those traits in every team Then what we did is we made a team out of that leadership team Because we're all about teams and collaboration and we call that team the pocklock team, which is the PO chapter lead agile coach team the pocklock team is responsible for nurturing all three of those traits and There's overlap between all three of those roles when you really start to think about it and there's also this section in the Venn diagram where they completely overlap and where they completely overlap is where the pocklock team really works as a team and that's where all three of the Roles come together and they try to improve the team's work At every aspect of it now this this is kind of an interesting Part of the Spotify way of doing things is because in a traditional organization You usually have one team lead one manager that person is responsible for all three of these things they're responsible for delivery as a product owner and for the clients and getting all the Conversations going on with them. They're responsible for the team improving because they're the team manager and then they are team They're also responsible for the line management for the individuals And what you usually see and I've done this myself because I used to be a traditional team lead Is that you have to make these decisions on a regular basis where you have to think about all those three interests at the Same time and you have to figure out which one's more important Guess what happens? Almost every time where you have to make a decision on your own about which one of these three is more important You're gonna end up choosing delivery Just because that's the primary thing You're gonna feel like you're held accountable for and it's the most immediate thing if you fail to deliver this print People will notice if you fail to improve in this print if you fail to develop people also who knows It's not very visible so what ends up happening in traditional structures is that that one person that's responsible for the team has to manage the the tension between all three of those interests and Usually it's hard for them to see their blind spots the incentives are set up wrong And there's what it's just gonna be much harder for them to make sure that the team is doing the right thing over time so What is it that I want you to take from here This I want you to take that We saw the Spotify by having three distinct roles and we have multiple people doing it We have multiple chapter leads sometimes per team not just one It's usually only one product owner and one agile coach, but we can have multiple chapter leads and that's definitely happens often But you don't need to switch to the spotify model at all What you should do is you go home or to your office and you should look at your organization And you look at the roles and you look at the people and you ask yourself What do I need? Who are the people that I have in my organization right now or what roles do I have or do I need to create? Such that I can actually nurture all three of those traits And I want to be able to create a situation where there's more than one person who's responsible all three of them because what I want is I want the interest to be made explicit in conversation between people I want the product owner to have a damn good argument why this time around we shouldn't try to improve the team Not why shouldn't we let them fail this sprint so they can learn something important or Why is this print more important than a bunch of people going on a training session? That's going to give us a payback over time You want those conversations happening outside of one person's brain? So even two people is good enough co-getorship is great product owner and then somebody else and they be responsible for just The coaching or for like line management or whatever it is. That's another common structure I want you to think about it. I want you to make it your own And I'm going to give you one example of how to think about this a little bit What we see here is a basketball court. This is a game. So what can we see here? What do we actually observe? There's players. They have different jerseys. There's a referee. There's the hoop There's the audience What else do we see here? There's a coach somebody who has put that What's what's noticeable about this coach? First thing that we notice about this coach is he's wearing a suit Why is he wearing a suit? I don't know maybe he means business. I don't know but he's wearing a suit So the other thing that's really important is the coach is standing by the sideline a Sports team coach never plays the game when the game is going bad You don't see the coach take the suit off put the jersey on go in and stop playing the game It doesn't happen Why is that because the coach's job is to stand outside of the game and observe? That's what the coach is doing We as humans are not as good at being able to multitask at the same time to play the game and to also Be observant of what we're doing. It's much much harder and you're not as good at it as just Totally playing the game being totally immersed in it or being stepped back and look again and just observing When you think about the roles that coaches have in sports teams, they're usually paid for the team not winning one game They want the team to win the whole season. It's not one sprint They want the team to win the whole thing, right? So that's what coaches are there for when you're thinking about who's gonna do coaching How they're gonna do coaching or what kind of coaching I need you're looking for that You need somebody who's not playing the game in terms of software development not playing the game means I don't stand in the path of critical Delivery, okay, I'm not in a critical path. Sorry of delivery so product owners can't do it because they are accountable for delivery and Your engineers may or may not do it depending on how you structure it But if I'm writing code and I need to make the choice between writing code or helping the team improve and Observing how code is written? Critical path of delivery is always gonna win. I'm gonna end up writing code instead of delivering So think about it think about it in terms of sports teams. It's one aspect to think about I want you to take from that last point is be nurturing foster those three traits go back to your organization Think about it. Look at what's going on and make sure that you do that so Capture everything I said in this letter to myself Dear Simon, here's what I want you to know One be a scientist experiment to learn To be effective prioritize prioritizing. It's all about time three be nurturing foster the three traits For take the Spotify job. It's awesome. It really was yours truly the future. Thank you Could you please explain the spot if I spot if I word Is you're using I'm not able to get that the spot by what take the Spotify job What does it job? Oh the last one? It's just it's just because this is a letter from My future self to my past self. It's just if you want to learn how to Have highly effective teams during Spotify. You can see a lot of interesting stuff Trying to kind of work on it You mentioned about never shipping products or never the teams who are never shipping things. Yeah So what would you suggest for the teams who are into that situation? So what I suggest is doing your best to cut scope And doing your best to find a way to have impact in what you're doing on a shorter cycle. So My experience has been that a lot of times when you see people not shipping It tends to be things that either the team is stuck in Kind of waterfall mode. They're like we have to get all the data before we can go and we can make a decision We have to architect the final solution before we can go and do something. That's like one one example Which happens from within the team and you have to work with team to be able to Do fast iterations and to be able to cut down what you're doing to start producing something that comes back and gives you a little bit more Experience there's a good exercise for that. I Think he's available on the internet. It's called elephant carpaccio Which you can do with an elephant carpaccio Which is basically the idea of taking a very big thing and slicing it into really really small pieces And it's a it's a facilitated exercise that you can run with your team When done well that exercise really gives you a visceral experience of oh That's why we do agile that makes sense because it's it gives you that it Take something really big you go through it and it changes the requirements halfway through and it teaches you that if you're gonna sit there And you're gonna try to architect an entire system and build it for the next six months Things are gonna change in those six months and your architecture is gonna fail And then what usually happens you get like really really clingy to the architecture that you had three months ago And you can't let it go Doesn't work. So that exercise is a pretty good exercise to run with the team especially if they have never seen agile or if they're and if they kind of fell off the agile Horse and they're like, yeah, they need to get back in there Of course, if it's the it's the other side if your issues are systemic An organizational because of other problems you're working on the wrong projects or whatever it is Like they're gonna be funded or you know, you're working on something that's never gonna get shipped That's a very different issue that you need to like then take outside of a team and you have to work with the rest of the organization to find Even smaller things whether they're tangential or parallel or how to take that actual project itself and change it So you can get some small wins You have to start the the actual feedback cycle of people shipping something that they know has meaning to somebody else


Hey guys, I'm Rob Riches and on today's video for supplementsworld.com I'll be taking a look at the many benefits of using hemp protein. For more information about hemp protein and many other ingredients be sure to check out supplementsworld.com. Hemp protein comes from the sativa cannabis plant and it's considered one of the best plant-based protein sources. It contains at least 20 different amino acids, none of which are essential. It's also rich in omega-3 fatty acids including GLA, gamma-linolac acid which is often hard to obtain through a regular diet. It's also high in fiber. Hemp protein has been studied extensively and it offers many health benefits without any of the psychoactive compounds THC attributed to the plant of the same family. The benefits are plentiful. Just supplementing with hemp protein powder is a great way to increase your daily protein intake, prevent deficiency and maintain the optimal functioning of your body. By boosting your protein intake you'll also accelerate your metabolism which in turn can help keep body fat levels in check. The high fiber content of hemp helps to keep you regular by cleansing the colon, regulating blood sugar and reduce cravings. Hemp protein also contains the plant proteins Ediston and Albumin both of which are responsible for the enzymatic functions in the blood plasma along with antibody formation. Ediston is considered the most easily digestible protein in the plant kingdom making it a great protein source for both your immune system and muscle building. Now the amount of protein you need can really depend on your size and your fitness goals. A general rule of thumb is one gram of protein per pound of lean body weight so a 25 grams group of hemp protein provides around 15 grams of protein making it a potential significant source towards your daily nutrition goals. However if you suffer with autoimmune conditions I recommend consulting with your doctor before consuming hemp protein. This is due to the high levels of gamma globulin and antibodies contained within its structure. Whilst hemp protein is beneficial for the majority of us the immune boosting effects might be too strong for those with autoimmune conditions. For more information on hemp protein and many other ingredients check out supplementsworld.com and if you haven't already do subscribe to our YouTube channel. I'm Rob Riches I'll see you soon.