 My name is Pavel, I'm work for a company called Think Adol and I own this company. I will not use any slides, so I will not have any presentation there. But I'll use a lot of flea charts. So if you don't see what's written on this flea chart from before, it might be a good idea to just come closer. Should I give you a couple of seconds to do that? Just come closer. Before I started to consult for my own company, many years ago, I was a scrum master. And scrum master, first small organization, small team. It was nice and easy. We were very agile. It was easy to interact with the team. It was easy to make decisions. But then at some point, I decided to move on. And I joined one of the management consultant firms in South Africa. And then I started to work with big banks. And how many of you work with big, large organizations in the room? I'll zoom a lot of you, right? So you know that working with big organization is not as easy as working with a small, little startup. Right, so there was a lot of challenges which I started to face when I was talking about even some basic comments. And I was like, well, those big companies, those big organizations just don't get it. They just don't get it. They'll never be able to do agile. So at some point, I was under that impression. And I was doing a lot of trainings in that process. And I also do executive classes. And one of the executive classes, one of a senior executive, he had $200 million worth of portfolio. He said, well, Pavel, it's all nice about all this agile scrum teams with respect to services, blah, blah, blah, yada, yada, yada. But how do we capitalize software on agile projects? Well, first of all, I didn't even know what capitalization meant at that point. So I was like, hmm, probably the same. I don't know why you're asking me such a stupid question. So obviously, he wasn't really satisfied with my answer. And I went home. And I was like, well, what's that capitalization thing? What he was actually talking about. And I started to research. And I've done enough research that I was actually writing a chartered financial analyst exam at some point. So I really got into the topic of agile economics and things just beyond the process of agile and how it all works out together. So I'm going to use this flip chart for my presentation. I'm going to go through a lot of basic concepts quickly, just to get everyone on the same page. So stay with me, be with me. And then we're going to dive into some more interesting topics. So imagine you need to make a decision investing in two different companies. The first company, their revenue and the expenses look something like that. And that would be a second company. Which one would you choose? Which one would you choose? Do you guys see from that side? Not really. Should I move it a little bit further? How about this? Can you see now? No? A little bit further? Well, I still need to stand here. Is it fine? Okay. Is that fine for everyone? Can everyone see? Perfect. All right, so these two companies. Now you can see. Tell me, which company would you invest into? The first one or the second one? First one? Or the bottom one? The bottom one. Second one. The bottom one. What would you invest in the bottom one? A consistency, some sort of a growth. You can predict how well it's going to grow in the next year and you're going to make that 10%. So what accountants really care about is revenue forecasts, right? So what executives really care about revenue forecasts and dividend spreads and how much tax you're going to pay in the next year, right? So what I realized, accountants are actually not stupid people. We just don't speak the same language to them, right? So maybe if we understand the language, accountants speak, then we'll be more successful at implementing agile in big organizations, right? So let's jump into that. So looking at that and looking at that projected growth, there's some level of forecast in the organization needs to do and they do some sort of capital budget and saying, well, IT gets this amount of money and finance gets that amount of money and HR gets that amount of money. So your CAO or IT director gets his budget, which you need to split into maintaining the business, right, running the business as usual, growing the business, there's new projects, new initiatives and do some sort of regulations, right? Compliance, so you still have your license. That's clear. But usually in your environment or your client's environment, there'll be many different competing ideas, right? We wanna do that project and that project and that project. How do you choose which project to do and which not to do? So how do you do that? Based on value, yeah? Based on value. Of course. So there's some sort of, almost like a document or thinking process you need to do. What's it called? All right, it's part of that. What the document is called? Business cases, right? So when you start any project, just to see if it fits the budget and we have enough money for that, we create business cases. So one of the purposes of business case is to make a decision. How many people work with business cases? Okay, all right. But that's not all you have there, right? So you might even have things like resource allocation. You mentioned return on investment ROI or cost-benefit analysis, that's what accountants call them. What else can be there? Scope, right. What else? Risks. Advantages, well, that's probably, yeah, the advantages. Yeah, that's cost. And if we have scope and cost, we probably can derive some sort of profitability and some sort of timeline, right? So does it look like a lot of information to do? Yeah? Okay. So if we look at traditional way of running projects, so we said, well, we create a business case in that concept phase. The output of concept phase is business case. We decide how much money to allocate to this particular project and how long it's gonna take and if we wanna do it in the first place, then you move on to just remind you analysis where you create some sort of documentation in a waterfall traditional way, right? And then you do development. At the end of development, you get some unverified code, which you do in your test through testing. Again, some sort of a product and then you get to deploy it, to get to your happy customer, right? So that's how we traditionally run the projects and that's why we needed the business case for that. But then agile comes in, right? So agile comes in and says, well, that's tough. Come on, we can just do it so much quicker. So we replace design, build and test with short, very short and incremental sprints. So in fact, we can have products and happy customer at any point when running Scrum. What hasn't changed yet? Business case, right? How long does it normally take you to create a business case and get it approved? Three months, I once work, three months, six months, I once work on a project where they said, we need to run our next project agile. So we're gonna create a business case and then spend 18 months on that to run the agile project. I said, oh, agile, tell me about it. Right, so, and the reason for that is because, well, when we're in IT, we can control that, but we're not necessarily controlling that because that's a business part. That's our contract between business and IT. So it's more difficult to change. But if you really wanna be agile, you need to be agile from top to the bottom. You need to be able to do your agile business case in such short period of time. So it maybe reminds you, it's just one of the other sprints. And that's where the spring zero came from, right? You've heard of spring zero. That's where discovery phase comes from. I personally like calling it lift off. So in agile projects, you need to be able to lift off your project in just a matter of a couple of weeks. You should be able to build your agile business case in a period of time, no longer than one single sprint. Well, that's all fun, but we just listed so many things we put in there in the business case. Sometimes it's not possible to figure out all the risks over the times and all of that. So you say, well, Pavel, that's all very nice to do a business case in two weeks, but well, how do we actually do that? So I'll offer you a couple of tips on that. First one is there's an iron triangle of project management, right? You know, there's quality in the middle, but there are three constraints. Help me out, what does this three constraint? Scope, cost, and time. So if we look at traditional way or wonderful way of running projects, we tend to fix our scopes. We tend to create requirement documentation saying this is everything we need to develop. But if you do it right, you need to make your cost and your time variable. In fact, if you took a look at Prince II or PMP, it says at a point of business case, you need to come up with interval of minus 25 to plus 75%, confidence range, right? Not 10% contingency plan, but that much. So you don't say it's, this project's gonna cost you $1 million. You say this cost is gonna cost you 750,000 to 1.7 million. That's what you are actually supposed to do. In agile, we say, oh, forget that. Let's flip the triangle. Still have quality in the middle, but let's fix our cost and time. Because here we don't know what we don't know, but let's fix the cost and time. Let's say, well, how do we fix cost and time? Our sprints are fixed in terms of time, and the cost of the sprint is fixed because we have a dedicated team working for that. So what ends up being variable? Scope, right? If you really wanna run agile project, which is agile business case, you should stop focusing too much on the scope and you start fixing your time and cost. So you need to flip your triangle. Flip your triangle. Can you see from the back? No, well, that's the whole point, right? So you're not supposed to. That's a little spreadsheet you have in your business case, which says this particular person gonna work for this team and even break down of hours. This person is gonna work for 83 hours in April and for 42 in July. You might even say, they're gonna work for that many hours in 2018. We've got that type of little spreadsheet in their business cases, a lot of people. Do you even know if this person's gonna work for you in 2018? You might know that if they use you the next month, but not till 2018, right? So what we wanna do in agile business cases is to stop focusing on very detailed but very inaccurate information and say, well, we need a team. Don't deliver the project or this product. We need a team. Who should be in the team? Well, maybe we need three developers, a tester and a business endless, right? Or maybe we need a database administrator, UX designer, we also can think of it. Who do we need in our scrum team or who do we need in our Kanban team to deliver this product? All right, okay, then if we run a scrum, then we have two weeks iterations and each iteration in each week is about 40 hours, right? And then, well, just to simplify that, let's say each person costs me about $50 per hour. All right, then how many people do I have? Oh, let's say I have seven people in the team. So how much does my sprint cost? Oh, that's cost me about $28,000. That's the cost of my sprint. Right, because it doesn't change because I always have this constant team or I only have $200,000. So how many sprints can I have? About eight, maybe seven, eight, right? Right, so that's how you don't need this spreadsheet anymore. All you need to say, well, who needs to be in my team? What type of skills? And for how long can I have them? So you need to really simplify your inputs. You try to put too much information, incorrect information from the beginning, which is not that useful for your decision-making process. Yeah, so you're welcome to do that, but it will average out in your velocity in any case, right? So you just know you need a team and the cost of your team is that. You might say, well, plus minus 10% because we need to have specialized skills, but there's also operational expense, which we maybe infrastructure or something which we need to procure separately. So we'll talk, yeah, yeah. So there's the next slide. And there's a good question though that's actually helped me to come to the next slide. Any other questions on that one? Okay, so we're gonna go to, well, that's people costs, that cost of building, but there's also cost of, we call it operational cost, cost of infrastructure and cost of training, yeah? Yeah, so you can take a blended cost, blended cost or you can even, you can split it, even, you know, you can split and say developers, business analyst and test is cost slightly different. So you can do a little bit more breakdown, but just for sake of showing this example. So you might have a like little small table saying we need three developers at cost of 50, we need one test at cost of 40 and one business analyst at cost of 65. And you can still do the very similar type of calculation. Or you can have a blended cost table taking care of all this extra training and all of that, yeah? Yes, yeah, yeah, yeah, yeah. Yes, it's the same purpose, but in order for you to baseline, re-baseline it every month and so you just, you just break it down so much more detailed so it start losing the accuracy. You start creating this rounding errors which when they accumulate then they actually give you the wrong impression. Yeah, yeah, yeah, you're wasting time anyway. So that's what I'm saying, all you need is how much my sprint costs, right? Not how much my project costs, how much my sprint costs and how many sprints can I feed into my budget? Yeah, so I'm gonna get to some other costs just now. Right, so let's, but before we do that, forget my ignorance, but I actually don't know. The cinema movies, if you go to the cinema, do you guys have popcorn? Do you also take popcorn and cool drink? Okay, cool. Who likes going to movies then? All right, so sir, which last movie did you go to, or into the cinema? Okay. Okay. Well, maybe which one you remember? Okay, did you take all of those, fine. Did you take some popcorn with that? And cool drink? And what size? Large, okay. Yeah, that's good. Do you know how many milliliters in a large cool drink? 350, are you sure? Does anyone know? What does, does anyone know? 500, 750? Try another guess. 650. Does anyone care how many milliliters in a large cool drink? You're like, well, the movie is long and I'm thirsty, so I'm gonna get a big cool drink. In fact, if you're in America, any America in the room? In America, you go and, so I went to this fast food restaurant and said, well, can I have some, whatever, chicken burger and medium cool drink and they bring me a large one. I said, well, it's a large one. It's like, what are you talking about? It's medium. And then I'll start to get curious. Oh, what's large? She showed me a bucket. I was like, it's a bucket and she stopped talking to me after that, so. So we actually don't care how many milliliters in our medium cool drink. The same, we should not care that much about the details of the infrastructure, right? So all we wanna know is, do we need a lot of infrastructure or do we need a small infrastructure? And this information you can usually derive from some historical data. If you've done similar projects, that was approximate cost or approximate configuration of our infrastructure for the previous project. And that's enough for you to make decisions, right? Because you don't go to the movie and say, can I please have 367.5 milliliters of Fanta? No, you don't do that. And in fact, one of the financial directors of one of the organizations in South Africa told me the story that they were discussing in the executive committee meeting, a piece of software which was $500. And she just kind of blew out and said, well, you know that you wasted $2,000 by just having this conversation. So you just don't care. You don't care about the small details when you're making a decision to go, no go. So all you care about is how big is it gonna be? What's the order of magnitude? And you can derive some estimate cost of that. So that's the third tip. Don't focus too much on details. Your hardware is gonna be obsolete in six months anyway. So there'll be new prices in any case. So just think of the scale of it. Think of the order of magnitude of the cost. All right, so once you simplified your business case, the next step is to draw some sort of a contract, right? So you still need some sort of a contract. So let's talk quickly about agile contracts. So we said agile works much better with fixed time, fixed cost contracts. So it's when you, so this is a lift off, right? And there's a couple of sprints. So you say, well, I only have 200,000 dollars. So it gives me about six sprints plus lift off. So that's my contract, right? So we're gonna work really smart about the scope and we're gonna try to prioritize and put the most important items first. So this type of contract is called upper limit contract. So upper limit or fixed time, fixed cost contract. But it doesn't work that well if you work in very uncertain domain where you're actually not sure if you're actually gonna be able to deliver something valuable by the end of it. Do you agree with me, right? So there's too much risk in this one. Saying, oh, thank you very much. Here's 200,000 dollars, please be good with it, right? So please deliver something, right? So you might not be in that position to have that full trust with your client or with your IT. So you might look at something called iterative contracts where you say, well, we're not gonna give you full amount of money but we're just gonna try a little experiment. Run for three sprints. And maybe at the end of three sprints we already have some sort of a product but we collected some historical information how fast we go in and if it even possible to build that particular product. Doesn't make sense, right? And then you will, if everything's going well, then you can just go and draw another contract or another piece of work. So that's iterative contract. Or you can do extreme example of iterative contracts. After three sprints, you just contract for a sprint and I saw some organization have one sprint length contracts. So that's an example of iterative contract. We built something iteratively. Why shouldn't we have an iterative contract for that? So it depends, so I'm gonna show you a couple of more but it depends on level of maturity of your organization. So you might be here, you might be here but I'm gonna show you some compromises as well. So the problem with this one is, well if someone terminates your contract here, so what do you do with your team? If you have vendor, let's say, you have vendor and both. Now if someone tells you, sorry we don't need you anymore in two weeks time, right, so it's a high risk. But also if you're in sales and I know a couple of sales people, they don't like those because they need to do like little sales, they wanna make one big sale. So there's another example of contracts. It's called fixed profit contract. And this is a risk sharing contract where let's say your vendor, so you contracted for this amount of time and as a vendor you obviously try to make some profit out of it. Let's say the cost of running the sprint for you is $15,000, right? But the cost you provide to your customer is $20,000. So how much profit do you make on that? Five, right? But what happens if you run over, right? So you contracted for this amount, you run over. So if you run over, just say to your customer, listen, you just need to cover the cost of it. So the cost of it's 15, you're not making any profit but customer pays you the cost of it. That's called fixed profit contract. You see what it does to you as a customer, you as a vendor? You as a vendor want to finish the contract as soon as possible, finish the product as soon as possible because you don't wanna run at no profit. And you as a client want to finish as soon as possible because you don't wanna pay anything extra. Both of you are disadvantaged if it runs over. Fixed profit contract. Yeah, so one challenge with this one is you need to let your client know about your margin. But the funny thing about software, there's so many different vendors that your margins are actually exactly the same. So it's not a deeply kept secret. Everyone knows what's the margin in software, right? So you can say, well, I'll give it to you at 30% discount, I'll give it to you at 50% discount. If you wanna turn it the other way around. But most, if we're in software, we know each other's margin more or less. So target price contract, it says, well, let's say we contracted for six sprints but the customer doesn't want us anymore after sprint number four because we've built enough functionality. So target price contract is a contract where customer can cancel at any point but for the amount of canceled sprint, they just pay you a percentage for that. So they still pay you but not the full amount. Let's say we canceled something and then the customer needs to pay you 25% of that. It kind of covers the cost of getting a new client or placing your team somewhere else. So you are more safe because you still get some money and they are more safe because, well, if they don't need you for the full time, they can always cancel, right? And there's a variation of target price called, it's got a very interesting name, money for nothing and the changes for free. So in this model, so you have to do some sort of upfront thinking, upfront, the same as with this example of upper limit, you have to do some sort of initial analysis, maybe initial product backlog, a story map. So this one is good, this one target price kind of assumes there is probably a fixed scope if we finish earlier than cut earlier. But this one deals with this problem, money for nothing changes for free. So this one says we just want you for two months or three months. We actually don't know what we're gonna do. So we're gonna, so all the changes are for free because you actually don't know what you're gonna build but you can stop at any point and money for nothing, it means you just get money for nothing to do nothing in the last sprint. So you can deal with that by having money for nothing changes for free because you don't pre-agree the scope necessarily. Any questions on the contrary? There's different models, you need to select the one which you think fits to your way of working right now and you need to kind of select the one which you wanna be at some point, right? Why would you say it's a lot of, no, there's not a lot of paperwork, it's just you need to change maybe paragraph five and seven and ta-da, it's money for nothing changes for free. There is actually examples of, give it to your lawyer and they'll draw it for quite quickly, maybe in one day. So there's not a lot of paperwork. So that once again it depends on where you are with your clients. So you might start with upper limit and do a little bit more upfront thinking about the scope and then once you have built the trust you might end up with money for nothing changes for free. So for your first client you might not be able to pull that through immediately. So there's no single answer, otherwise I would just say this is a contract and do that. So I'm just giving you all the different options. What's a good start? What's good for startups? Probably money for nothing changes for free, it's good for startups. All right, then the last part, let's talk about capitalization, yeah? Yes, yeah, yeah. So then you go with just a simple upper limit contract, you had a budget, budget is your contract. So you say you have that amount of money and you're done as soon as you spend it. So capitalization, so just to give you a couple of basics of capitalization, your company generates revenue, right? Some of it you spend and some of it you retain as a profit. But the way you spend some things, they're actually two different things. One of those expenses you spend and write it off, but some of those you spend on good things like factories and automobiles and software product is one of those which called assets, all right? It's something potentially you can sell in the future. Right, so capitalization is that rule which says, well, not every spend is an expense and some of us we shouldn't treat as an expense for tax purposes. So whenever you build your product, software product, some of those goes into expenses and some of those goes into assets. For example, development time goes as an asset. So you can say we'll build that amount of asset, that amount of actual product which we're gonna use for the next seven years. Or when you buy infrastructure or service, it's also your asset which you can reuse. In fact, if it doesn't work on this product, you can put a new product and still be provided to be valuable. So how we tend to capitalize, we tend to capitalize, we tend to expense everything until the point when your business case is approved. So the process of creating a business case is operational expense or just expense. When you build your product in waterfall, right, until the point you go live, everything is capitalized. So everything you write back into your books saying that you've created an asset. And after you go live, all the support, all the bug fixing, all the maintenance, then it's operational expense again because you're just doing business as usual. There are very specific rules at which point you can start capitalizing. You can't just capitalize everything. There's rules of research and development. The things like, well, you need to be committed to actually finish the product. You need to show how this product will be profitable, it will be useful. You need to provide technical feasibility of the product. You need to have written managerial approval of going ahead with the project. So it's a lot of different rules. So that's the reason why we don't capitalize from the beginning. In fact, those rules are written in, those things called IFRS or GAP. For example, if you're in the US, it will be called GAP US. In Europe, some of them have specific GAP, but some of those uses international financial reporting standards. So those rules are pretty much well defined. But now, let's think of it all. You don't have necessarily a go live day because you can go live after two weeks. And you don't necessarily have that fixed approved, heavy business case date as well. So I'm gonna show you two different approaches in capitalizing in agile. So there's a conservative approach because remember you need to show that you disability of the product. The conservative approach says, well, you can only capitalize from a point you've created your first release. Maybe once you've built it for a couple of sprints, you created the product. It might not be released to production. It might be released to some sort of staging environment, but you actually put together a product and it's working. So conservative says, wait till the first release and then capitalize. But before that, expense. Aggressive says, well, just capitalize all the sprints. Just expense the first lift off. That just that part when you're actually creating a team, creating your backlog. There's two approaches and it's purely based on your organization's risk for appetite for risk. So if they use aggressive accounting, then they would probably do that. Otherwise they're gonna do this one. All right, let's talk quickly about time sheets. The reason why accountants love you to do time sheets is not because they like you to suffer, right? It's not just because, oh, we want IT to suffer and feel the pain of submitting time sheets. Time sheets are financial controls for their organization. Time sheets is for them to see which activities the team and individual undertaken are expenses and which ones are for capitalization which spent on building the product. So in a nutshell, in agile, what you wanna do, you wanna simplify your time sheets that is probably have two lines. Capitalizing activities like development, testing, creating requirements, also capitalizing. And OPEX, so expenses, bug fixing, maintenance, training costs. So that's where you leave, if you went on leave, that wouldn't be capitalizing on your time sheet. But let's say you hate time sheets. Like, y'all can't stand time sheets. Can you do something around capitalization without time sheets? You wanna get rid of time sheets completely? Well, there's a way you can capitalize on using story points. So imagine you have a sprint backlog with four user stories and you even estimate them in story points, three and eight and 13 and 20. So all you need to do is to create an extra column and say, well, this story sounds like we're building a new feature. So that's definitely something we can capitalize. This one is a technical spy. Or maybe it's a bug or a maintenance item. So this one we can't capitalize. And this one we also can capitalize. So at the end of the sprint, we'll deliver these four stories. Three was capitalizing activity, one wasn't. So how many of 44 points did I capitalize? 36. All right, so if my sprint was $28,000, remember from a previous slide, and 36, well divide 36 by 44, and it's about 0.82, right? So the 82% of my sprint, I can actually capitalize. So my sprint, in fact, I've built $21,960 worth of assets and the rest was an expense. And this way you don't even need time sheets and accountants are happy because you have a financial control based on user stories on which different activities your team undertaken. You fix the bug in production. So it's a way your organization treats them but usually bugs are treated as non-capitalizing activity or you had a technical spice. So it's like a research and development type of activity or your team went on training. So that's something you, but yeah. But you wouldn't have a story for training so I'm thinking, but that's already would be built into that. In the sprint. Yeah, yeah. Whole part of it. Because it's part of that story potentially. If it's a defect which you discovered which was put into production about six months ago, then you wouldn't be able to capitalize. And yeah, I don't want to focus too much on specific rules because they're different per country as well. But you can always find them somewhere in software they're quite well defined. So if your story, so all your case, so all your case to take the snapshot at the end of the sprint. So this is a snapshot at the end of a sprint. Yeah, so you'll take that what was changed. It's not upfront. How do I, what? Oh, I divided 36 by 44. Sorry, I should have mentioned 36 divided by 44. I just did pre-calculation in my hotel room just an hour ago. I'm gonna finish the last thing and then we'll maybe go to the question. So just because, yeah. Yeah, yeah. Because this is a cost for the team and this is the way the team done the works. That's still fine. Because remember, if you think of timesheet, it's also subjective to how the person actually spends their time. So one spends four hours and one spends six hours. What you care about is in a nutshell how much money you spend on specific activity. So that doesn't matter. And in a timesheet, you don't give control to developer? And I mean, how timesheets? That's okay about it. Okay. So we're gonna run over but I'm gonna answer this question. So how developers submit their timesheets? They go at the end of a month and they're like, hmm, on the first of the months, I think I've done eight hours on this task. So you under impression and the accurate, the timesheets. If you really, really do some investigation around the way people submit their timesheets, they're not that accurate. So you're not losing that much. And so the last topic I wanna talk about is seed funding in your organization. So I think it's a bit unfair if we only select a couple few of projects to go headways and we reject all the rest of ideas. So maybe we can get rid of business cases at all. Maybe every idea deserves a chance. But how would you have money for that? Well, maybe every idea deserves a chance but they only deserve one day, right? And you might have heard of hackathons and other events like that. So you say, every project idea is a good idea. Let's have a hackathon and let's try every idea and see what kind of comes out of it. So create a team, try to build it. So all of our ideas, you will start, you'll spend one day on that. Some of those will be complete rubbish. You'll be like, oh, you shouldn't have done it in the first place. Some of them would be good enough to maybe give them one sprint, you know? Dedicate a little bit more resources. So you carry them on. And some of them will fall through and only the last two survive and maybe get six months worth of funding. So even in your organization, you can create that competitiveness between different ideas when you test all of them but you only dedicate a limited amount of resources, limited amount of money and you run through cycles. Very similar to Angel finding in America, right? So seed finding, but nothing stops you to do similar type of thing in your organization. So I'll finish in there, that was 45 minutes. The contact details of me, if you wanna take a picture of that, if you wanna contact me later, if you wanna get the pictures of the slides or the recording of a talk, there are URLs in there as well, right? So take a picture of that if you want to. Thank you very much for coming and I hope it was valuable.