 Okay. Let's get started. Welcome everyone. So this is a talk on increasing productivity by uncovering costs of delay. And some of you might know me from the other work I'm doing which is on scaling agile, which is what I do for 14 years now. And distributed agile is something that I do for, I guess, 12 years. So this is also where my two core books are about. However, today I want to talk about which relates mostly to the book that I wrote together with Johanna Rothman. And we are at this moment updating it and providing a new version of it. And it's called Diving for Hidden Treasures. It's the name of it, finding the real value in your project portfolio. So cost of delay is the topic. And I thought a little, it can't work if I don't switch it on. Okay. I thought a little agenda with me, which is I want to first set the context of what I'm talking about here. Then I want to talk a little bit about metrics. And then about half of the session is the analysis of cost of delay. Oh, and I forgot the most important thing, I guess. I'm not sure if it's so important. But my name is Yuka Exstein. I didn't say that. And probably the pronunciation is also something that's difficult for some people. And I'm based in Germany. So that's where this strange name is coming from. Okay. So. Good. We start with the context. So if we say here, well, I'm saying that we want to increase productivity. That means that we need to measure productivity somehow in order to know if we increase it or not. Right? So what we have to talk about here in terms of the context, what does it mean if we measure something, first of all? And the thing is, and I can imagine that some of you have experienced this as well already, as soon as something is measured, you can also tweak it so that the numbers are giving the results everyone is looking for. Right? So there is, I'm not sure if I have the right translation because I know it's in German or in English, but I never trust a statistic you haven't tweaked yourself, something like this. So this is the key problem if we are measuring productivity. There's only, I believe, one way to get around that, and this is ensuring that everyone knows what we are measuring, why we are measuring it, and what do we do with those numbers. And whenever one of these things is missing, then we will fall into that trap very likely that the numbers are tweaked, and so they are useless. So just to give you maybe really a quick, simple example, but I have seen that and it still sticks with me, this was the quality assurance that, well, we want to measure the unit test in that system. Right? And so they had a typical QA like, they started coming with their checklist and running around and checking off, okay, there's a unit test or not, and you could really see unit test went up really great. So then I started looking at the unit test and, well, there was a lot of things stuff happening in those tests. However, at the very end, the last line was always assert true-true. Okay, so for the ones who do not know about unit test, so this just means the test will always pass. There's no way of failing. And so it doesn't really test much, right? And the thing was for the developers, they thought, well, we are writing those tests for the QA, and not for ourselves. So it was not clear for them or to them what purpose is behind that measurement. So this is really the core thing about being careful about what you're measuring. And the best is you discuss what's the goal with the whole team, with everyone who is involved with that measurement, and then come up with a measurement jointly. So it's like everyone who is involved or impacted by that metric, that they will measure it to know what the metric is and will measure it together. And therefore, they're also happy celebrating it together whenever those numbers are getting up or down or whatever you want to achieve here. So that's the first thing about the context. The other thing, which is a little bit related to that, well, whenever you start measuring something, it means you make something transparent. And whenever you make something transparent and you are in an environment that's not trustworthy, then that transparency turns out into something that's more like control. And as soon somebody recognizes that, again, we have the same thing as I said before, the numbers will be tweaked and the measurement is used. So measuring something in a not trustworthy environment will give you the wrong numbers. So that's what I have about the context here. Now, speaking about metrics, and I know because it's only 45 minutes, I have to look at my watch regularly, speaking about metrics. So what do we want to measure? So I first want to point out some things that probably come to your mind as well as I did to mine. Well, this is a good number for maybe measuring the productivity and then knowing how to increase it. So one thing that might come to your mind is the burn down. The most important thing about the burn down is it's a tool for the team, and it's not a report to somebody external to the team. So it's a tool so the team knows can we keep the commitment we gave at the beginning of the sprint. So we said we want to finish, no matter how you measure that, we want to finish that many story points or that many stories or that many tasks. So however you do that, it doesn't really matter. It is for the team to know how well are we doing along our way through that sprint and can we keep that commitment. And so it's not a means for measuring productivity. It's a means for the team for knowing what they need to do in order to get their stuff done. So this doesn't help. What about the next thing that Robert B, you're wondering already why I'm not talking about that, the velocity. Well, velocity actually and I'm really an absolute deep believer in it is unlike productivity. Velocity has nothing to do with productivity. Velocity is a capability planning tool and not anything how you measure productivity. And I give you one example and you might have seen that too. So as soon as you start looking at velocity in a way that it would be productivity and you say like oh the velocity has to go has to go up because well you want to be more productive therefore it should go up. Well then people would start estimating the points higher. So again you start tweaking the numbers because it's not really helping and but even more critical and I guess I will come back to this more often in this talk as we might measure only what will be done but not what kind of value we are providing. And that's the most important thing. I was providing a value for the market and in terms of our business strategy. Okay so what else can we measure? We can start to measure and that's one of the things that I find helpful the average cycle time. So how much time do we need in order to have a story from when it's planned so it's in the to-do state till it's really done and this on average which could also be used as a planning time however when the story is really done it should most of mean that it provides a value however it's not always like that and therefore my advice here is not looking at only well how many start you know how long does the story take on average from to-do in progress to be reviewed done whatever your faces are there in between or states are in between but also look in advance at what kind of value will that story provide and then measure on average based on that cycle time how much value do we produce on average over that period of time from to-do till done right. So that's a really different approach and it requires as well from everyone to look at value before we start implementing something because normally we look at only well the estimate how basically it's the same question that we have asked before we started with Edge also how much does it cost that's the same thing as if we ask a team well can you do a planning focus on that and what's your estimate at least that's how often we dealt with it and the more important thing than any kind of estimate is to look at what value would that story provide and given on given that also knowing then what priority it has have and once we have implemented deliver deployed it what value did we actually deliver. So the key thing here is what I think it was just cutting payments coming up with that it's outcome versus output so it's not productivity doesn't mean that we create a lot of stories and implement a lot of stories it means we create a lot of value and that's the outcome outcome with which is something that will create an impact with our customers within the market planning after we have deployed it and you probably have heard that as well so the typical story that we share is work the work processor system that it has like the Pareto rule that 80% of the functionality is not used and we are only using like 20% of the functionality so the same thing is true for whatever we are implementing so we might think this story creates such and such value but we are not measuring it afterwards so it's this is related to also lean startup right lean startup we think about how we measure so what will be used by the customers but even there we are not necessarily measuring okay does it really provide that value and this requires from us to come up with different kinds of tests so we have to create tests that are built in the story so we can also get the results from the market if the story is really used and if it's worth to maintain and support it over time or if this is more a cost factory here so is it really the value we thought of okay um what else well cycle time I want to come back to this you remember this maybe I go back so that was the cycle time thing right and this is only a part of the truth and if we look at productivity the real truth comes to if we look at the whole value stream and if we look at the whole value stream something completely different might come up and the example that I have here and I'm I fear it's not visible in the back because the color is too light well the thing is we have a line here and on top it says it's the work time so we are working on something and on the bottom of this horizontal line it says it's the wait time so nothing is happening and now if we are not starting as we did with cycle time well the moment when it is scheduled in for a team to work on it so it's on the board right like on the storyboard sprint board um but whenever that regress first came into our company so whatever somebody has heard in the market well it would be really cool if you would have that teacher or it's a customer complaining or it's someone figuring out according to the business strategy we really would need this that would be cool so that's the first time that I call it a regress at that point in time because we don't know yet if it's a story if it's really something big small whatever we haven't really looked at it this is coming in and typically this is only like a kind of a second of a time and then comes a long wait period so in this case it was like a four week wait period till we got to an approval which took about an hour okay and then we have another wait period which was one and a half week and then we had two weeks where we did something like gathering environments more or less it's finding out okay what's really behind that what are maybe the stories in it and who would work on that in which product project would fit in and all of that and then we have another six weeks of wait time and then we have to sign off from the customer in that case it came from the customer so we need to know if it's really what you want well and on and on and on and then finally at some point we are there right so this means we have lost already a lot of time here so it's almost three months till we get started somehow right so if we talk about productivity we should also look at that part and not only what's happening inside development so that's my message here so if you really want to make a change here okay so this is was the context the metrics and I believe now I come to the real the analysis analysis of the cost of delay and this goes back mainly to that great book of Thomas Reinerson on flow well the difficulty with this book is I on the one hand I highly recommend it it's a great book there's a lot of great stuff in it however I also have to warn you it's a half brief so it's really whoever has other people here who have read it is it a half brief no not for you yeah it's a lot with mathematics and yeah yeah it's great it is a great book but it's not like you you really like that so it really costs some effort to read it so that's that's one of the things where this goes back to then manage your project portfolio is what Jonah Rothman wrote and then kind of our johannas and mine translation of that book into like okay what does this practically mean is then what we have condensed there in our book I want to start with a definition that johanna came up and I really like that so cost of delay the definition here is it's the way to think about the very new you can lose plus the cost of continued development right and I guess the first example is already one which probably doesn't come as a surprise but it really strikes them makes that point clear in the best way possible which is this one as soon as you have work in progress so here we mentioned that the red bar is okay this is all that we have to do and then this is all that we have in progress the green one is all that we manage to deploy so as soon as you do have broken progress it's a revenue you lose it doesn't make any revenue it just sits there plus you have to continue development because it's broken progress right so it's really the the best way of understanding what cost of delay really means and um I I only can recommend to you to measure that regularly so what is your work in progress because I see too often that we like to ourselves and you think oh but this is done or that's kind of for 80 done or something like that so this is from a real um a development effort that I was out of the pardon and you see it really bad it's really bad well we got better over time it was much worse here we got better but it's still it's very bad but you really want this like a slice like that that's working progress and not something like that however if you are not like honest to yourself you will never learn it and again remember if um people don't trust in that and they feel like they will be punished once that's visible the data would look different because we trust to find stuff that's done okay that's one of the things another thing um I see too often as well is multi-projecting multi-projecting or even if you don't like the term project I know there's a lot of discussion about that so even if you work on different products in parallel you have the same thing so given um I make it really simple here given we have three projects each of the projects will last only two months so it's really short or it can also say it's just three products and they last two months each okay if we if we work on one after the other we would make the first time of revenue so thinking of the cost of delay right after two months because the first product would be done and then after four months more revenue comes in with the second product and after six months again with the third one however if we work in parallel the first time we theoretically can make any revenue is after six months so we lost already a lot just by working on the stuff in parallel and for whatever reason people in especially large organizations believe that if they start with multi-projecting they will be faster however they are not they never are and they will always lose money by doing so and please note that with this way of working in parallel on several products I still I haven't calculated in task switching and for task switching the research says we will lose about 30 of our productivity if we switch tasks so I really wonder how much money all the companies have that they can afford that and still I hear that well there are some economic and financial and whatever crisis everywhere well but there is a lot of there that we can just mine and ensure that we use it right just by giving up on that stupid thing multi-projecting and not really doing like one thing after the other so multi-tasking is it's another definitely cost of delay even if you are like within one product and you just pull out people all the time same thing another thing another cost of delay and this shows I think at best the query theory if you work with experts on a team and I see this most often with people starting with agile so you will have a cross-functional team and you plan the stories but the stories are planned for individuals because every individual on your team is an expert for something and of course I know that the system that's built that's so complex that there's no way to deal with that right so we have to have the experts and every expert is like okay I really know that stuff and that guy next to me have no clue about that I know that this is what we all think however as long as we think that way if we are really honest we have no control on priority and I hope I can bring this point across here so given this example so we have a team with like five people every one of them is an expert and we schedule the stories in the stories are prioritized now the problem might be that here the the expert sitting in the middle is the one having a problem because the story he's working on is really hot so he has to explore stuff research blah blah blah and so we take time and time and time and the thing is whatever has been planned in for that guy is queuing up now everyone else keeps working on their stuff well whatever they are working on is of lower priority than what's stacking up here right and it's not in our control if we prioritize those stories or if they're important or an urgent or whatever the way how it works on that is based on who expert is struggling and who is not so only if we are able to really work together on the same stack we are able to really work according to the priority we came up with so we are really controlling it and we can see what we are working on and yes I know at least in my cases and maybe you are better than that in my case it's very often it's not that everyone can do everything however one thing is we can strive for that that's at least one thing we can do and the second thing is well maybe if not everyone can do everything then at least everyone can do three things and everything can be done by at least three people on the team so in this way spreading it out the knowledge so actually if you look back at what etchel is about it's a lot about knowledge transfer wherever you look at so if we estimate together if we have the daily stream together if we plan together if we do pair programming it's all on knowledge transfer so use that and not stick with expert okay another thing another cost of delay which might sound strange which is quality well first of all we all well want to be proud of what we are working at so which means we maybe want to stick to glean code we want to ensure that there is no technical that we want to ensure that what we are building is absolutely false tolerance what we are doing here and maybe also that the system is so flexible that we can deal with different eventualities that might come up or not and that's good I'm not saying that this is the best thing however what I'm saying is well there are cases where I see it's more like a ghost framing what we do instead of looking at quality or putting it in other words it's sometimes more that we are not taking into account what kind of quality is really asked for so we are ignoring what the market and the business strategy is really asking for and if we do that then it gets difficult so because we provide more than somebody is paying for and this gets us into trouble so what we have to be aware of as well first of all maybe it's the other way around making the people who are requesting a story aware of like what the quality will cost and how important that is so that's probably the first thing and then if there is a decision for whatever reason that we need not that quality but a different one then we have to be aware of that and develop accordingly and although this might sound really bad for you I don't know I have seen companies really struggling with that and especially if you are in a startup market you want to enter a market then it's often much more important to have some functionality out there so that people can see okay this is where you're heading then waiting till it's really high qualitative on the other hand you might be in a market that's really kind of a solid market if the quality is not good then you would lose your customer so the thing is you have to know what's required and the answer is not always the same so as I said as this is so there is not a recipe however we should be aware of what's really requested so that's my my key point here and that's why quality can be a cost of delight now another thing and maybe now some people in the uh scrumptious field will hate me for that I don't know and this is a cost that I am seeing is about what I call not starting and not starting is sometimes expressed by using a sprint zero so people are afraid of starting with sprint number one but schedule in the sprint zero where they think well we have to set up this and that and then ensuring that everything works together and on and on and most often that's not the worst thing most often the worst thing is that this sprint zero is prolonged and prolonged so there's another one and a zero abc or whatever maybe it's called zero so in in my understanding the but what I see the most often here is that people are really afraid of really starting and just my advice as well first of all you're losing value here and you are not you're delaying the the revenue with that so that's the one thing the other thing is well why not just jump in the water and get starting started calling that sprint number one and just ensure in that sprint number one that you set up the infrastructure and sure that it's working by maybe it's only a hello world and a test approving it but you have the full path of it and you can measure what you've done in those two weeks so often I think just by the ladle of the zero it people start to I don't know not really trying to measure it and working part of something that's the one thing about not starting and maybe you are happy with that but the second one and which is also very well known in the scrum world is the definition of ready which I find is really a very difficult thing and for the people who don't know that definition of ready means well if we think a story is not ready for implementation we have to create it in a way or rather most often the way to implement it the product owner has to ensure that it is defined in a way so we can implement that so that's the idea of the definition of ready a story is ready for implementation now the thing is the ready for implementation what does it really mean or what does the story really mean a story means it's a token for dialogue nothing else so we are not talking about the specification here it's not a requirement spec that we are coming up here with and where we can say oh we check this this this and this is not there and therefore well we can't work on this this is one thing so it's a a token for dialogue nothing else the the other thing is what I see most often with the definition of ready that we start again that ping pong game that we know from the non agile role which is like there are the people who know about the business the product owner and here are the developers and now the product owner says oh I really want that story so I pass it on over there and imagine there is like a a wall in between so it goes over me so it's there so the story is there and then the developer says no no no that's not good enough it's not a con the definition of ready and so the story goes back over that wall and tips again with the product order and you can do this for a long time and again it's a cost of delay you are not creating any revenue on that time during that time so again um the dialogue I was uh talking about just a sentence ago the thing is if we think the story isn't ready it means we have to collaborate in order to make that ready so it's not that it goes back over the wall to the product owner it means we have to sit together to make it so that we can work on it and not delaying it by throwing it back and forth so maybe that's the one thing you take with you and my hope from that target whenever you see the definition of ready please reflect on it if you really need it and if you use it in a way that's really helpful or if you use it in a way where you are delaying the implementation and the delivery and you're creating more cost of delay maybe you are using it in a way that's helpful I don't know but most of the times I see that it's really a big delay and I'm good okay and the the last thing I'm having here is repeating mistakes um well repeating mistakes and you want to talk to you about the cows well the thing about the cows is it goes back to an idiom and I first use a different idiom that we are using in German in German the idiom says we can't sharpen the saw because we have to saw and I learned that idiom in Texas where it goes we can't build the fence we have to chase the cattle and that's why I have those cows here so if we run after the cows we cannot build it the fence right and that's what I mean with repeating mistakes most often we keep on doing stuff and we are not reflecting maybe we do have a retrospective maybe we don't have a retrospective so but even I see that if people are doing a retrospective they are not doing it properly like they're doing just a plus minus collection of stuff or they are not really looking at stuff like where is our cost of delay here so what you need to do from time to time to really look at what's hindering delivery here and maybe it's the build time that's too long maybe it's the test taking too long maybe it is that you have too many manual tests here whatever it is so look at this and ensure you work on that to make it happen because otherwise you are creating a big cost of delay and and really the the retrospective and I hope with the with the cows that stick to you that's the biggest leverage you are having in order to get over this and actually this is also why I have this as the as the last kind of analysis thing for the cost of delay this can help you with all the things I talked about earlier so if you have that chewing problem because you have too many I called them experts before but you can also call them like bottlenecks or knowledge silos or whatever it is so that's something to work on on a retrospective the same as to well maybe we are gold framing here and this is why we are not delivering sometimes I see gold framing also something that same as not starting it a fear of delivering and that's why we keep on well it's not quite ready yet it's cool so of course it's also the the okay so so in summary so one summary is you're producing a cost of delay whenever you are not shipping it's as clear as that and and again I really think the broken progress is the thing that brings that point the best across as long as stuff is not shipped and no matter what it is so it could also be that you're releasing only every six months the stuff sits here it's not creating any revenue and it's the continued development that's going on so again it's a cost of delay if you're not shipping the other leg and in summary about what what we talked about here is well first of all think about the metrics so you have to have a trustworthy environment in order to really know what you are measuring is really some data you can deal with and you know that you are more productive than you have seen before the the second thing is measure the value you are creating and not just the stuff that gets out of the door because producing stuff is not really helpful either it can also be late later on and then analyze and eliminate your cost of delay no matter what they are as I would like the broken progress most obvious on the expert the multi projects and multi-tasking the quality perfection thing that delaying off the star definition of ready and repeated mistakes and I was trying to speak very fast so we have we are safe for you and which is even better what I hope for we have some time for questions so maybe I say thank you first so thank you and if you want to take a picture up there's a link we created a discount a coupon for that book on link up so if you are interested to learn more about that so that's the link for it and as I said we are working on it right now so when if you download it now probably you will get a different version tomorrow but you still get it okay any questions yeah yeah exactly exactly yeah yeah I first want to check was this uh hearable at the back the question the point yeah I see but okay um so the first thing is not the real advice how to get over it it's more like how you can figure this out very early and it is you find this out in the daily scrum if people are standing there and they are all bored and if you hear ever so often well we don't know what that daily scrum is for it's a waste of time and it really is a waste of time because they don't share anything with each other and so whenever I'm part of that team and I'm reporting on well this is what I've achieved since the last time we're standing there and and that's what I want to achieve till next time it's meaningless to you because you're working on something completely different so it is a waste of time and the the thing is probably at the very start a lot of things have been missed so one thing is there is no common goal for that team so it's not that we are achieving something together and it's not that as a team we have estimated it together in order to learn what we want to build here and so this is these are already ways of how to work on that right so coming up with the goal and estimating it together planning together it's not that I plan for my story it's at least that three people of the team plan together for that story right and then also we work together on that story so so these are the things and if if you are in the state you are in right now actually I would make a focused retrospective with the topic on knowledge transfer so what can we do and first pointing and well the best thing is really kind of using those classical retrospective questions what's working already and maybe there are a few things that you discover well here and there something is already working and you can leverage that and keep on working with that then what might be easy for us to implement and change so we have that knowledge transfer and then what's what's difficult and what seems to be impossible so these are at least for me often the classical four questions when I when we have a problem like that very good cool well done good other questions in the back yeah yeah so you mean how to measure the value after we delivered both okay so before we delivered so there are a few things that come together so one is the expected revenue we are making with that feature all and the expected savings we are making with that feature can be true as well right and these are the the two key things then what comes with that as well as like how does it support our strategy our business strategy so this is um you might have wondered already why I'm saying this now is the third time also and the thing is it's kind of something that was my most recent learning probably that for too long I was focusing on customer and market value only and this is just one part of it the other part is also how does it fit in our business strategy right because it might mean we serve the market very well but we run out of business because of that but could happen so um that's the the one thing the other thing is um how do you define that so there are different strategies one maybe easy strategy that I I used was using just like planning poker but to use not estimation points but value points right and we had the people who could decide on that so of course you need also somebody from the from the technical part there but it's mostly business people coming from different angles and saying okay in the same way as you do planning poker poker on what's the value that's really behind that story so that might might already be an easy one another thing and that's more what um but Johanna has in her managed career project portfolio thing and you could also think of you have extra amount of money and and you you can't define X let's say a hundred thousand US dollars and you split the that money over if you will we are staying with one product over your stories and it's not possible to spend the same amount of money twice so even if you have like a hundred thousand US dollar and you have only two stories so it's exaggerating but you understand the thing you couldn't have two sources with 50 000 right so one can be 51 and the other one is then 49 so you cannot spend the same thing right so this is one way of ensuring the value is very clear and you are thinking about it in advance and then after the fact it's more like how is it how often is it used and the customer feedback of course as well as you mentioned aha yeah yeah yeah so that's a very good point so the thing is then the key answer is you need also cross functionality here so they need to talk so it will not work if you have the business dropping on that by themselves they have to work together um well is that true i see that oh it would be like one minute okay so is it a quick question otherwise okay so we we take it offline okay thank you very much