Estimating cost

- But if I know that all the rooms that I want, I'm pretty definite about what I want in my house. I know I want three bedrooms as well as the kitchen, bathroom and stuff. As an Agile person, can you tell me what that's going to cost and when it's going to be ready? - Well, I mean what I could do is I could tell you roughly how much construction will take place based on the number of people working and the number of sprints that we'd estimate if you're using Scrum. And so, I could tell you, you know, here's what we're going to make. But seeing an Agile product, you could be six sprints in and you could say, you know what? I don't want three bedrooms, I want two kitchens. - Yeah. - It's possible, and so-- - Well with my app I did change my mind quite a lot as I went through. - Yeah. - But clearly with a house you wouldn't change your mind, but with an app. - But you might, I mean if it's software product it's very common and so you could, if your customer decides they want to, and maybe do something maybe then instead of second bedroom, they want an office. Or they want a room with a fire place or something. So if you're working at a team with an Agile mindset and the customer has that flexibility, then because your giving them that flexibility, you can't tell them exactly what's going to be delivered at the end because they could change their mind. And so, this kind of iterative and incremental delivery is kind of the key to the predictability. - So if I'm a customer who really is definitely not going to change my mind, there'd be not point in using Agile because I'd be wasting the one really great feature that it has, kind of thing. Having said that, does that type of customer ever exist? 'Cause they always change their-- So something you said just then that I hadn't thought about. Well I have thought about, but I hadn't thought about it with Agile, is in normal project management, conventional project management, there are two types of times, hours worked and there's elapsed time. Which, I prefer to use weeks for that and what I teach on my training courses is, you shouldn't really talk in days, 'cause if you say, this job is three days work, does that mean it's three days of cost, if you like, one person working for three days? Or is it three days of elapsed time? Whereas if you talk about hours and weeks, then you know that a ten hour job might take you three weeks because of other work and interruptions and things like that. So the game in ordinary project management is to estimate how many hours of work are in something and also how many weeks of elapsed time it's going to take. And, I'm realizing, listening to you, I don't know whether this is right, that if you've got developers working on stuff, if you know that a sprint is a week, - Two typical. - Two weeks. Then that two weeks is solid work, so that's both hours used and duration. Or do you distinguish between hours worked and duration? Or are they kind of the same because they're full time on one project? - Right. And so, typically if you're in an Agile team working with, using sort of a Scrum framework, then people will be timeboxed. Because in a typical project you might crash it, you know, might broke more people into it at the end. You might pad the hours to try and give yourself some flexibility. But there's no room for that in Scrum, because it's only two weeks. And so, every developed should be timeboxed to eight hours, that's their workday, and they should be able to focus on having a predictable amount of work come out of the team every spring. And so, when I said that I thought that Waterfall was too flexible, this is what I meant, is that Scrum is extremely rigid. - So what about if there's creativity in there and we don't know how long it will take to solve a problem or design something that's good enough for it? How do they cope with that? Not that Waterfall copes very well with that either, so that's not going to work is it, 'cause they won't be able to finish that sprint in the two weeks? - Well Scrum always says that if you want to have sort of creativity or something like that, then the best thing to do is think smaller. And so, if you are working on very specific, you know, a lot of times typically they'll use user stories or something like that. If you're working at a very small chunk of work, then you have a lot more flexibility to be creative, then if you're working on something enormous. And so there is creativity within that two week sprint but at the end of the day, you're going to be showing that product to your customer at the end of that sprint. And so you can't sort of have your creativity, have your delivery come at the expense of your creativity. - So you can't just play as long as you like? 'Cause there is a showdown with a customer every two weeks where you have to show something to them. - Right. I mean you could and maybe you could explain it to your customer and just be like, well look, you know, we've came up with a much more creative way to do this and that's why your not really seeing the product this week, you know, at the end of the spring. But the customer has to understand that in real time. So you can't just, you know, and a lot of times in projects you'll have these things called handoffs. You know, in typical Waterfall projects, where people will be waiting for someone to complete some work before they start. And so they'll that time to do research or come up with some sort of creative ways to do it. But the problem is is that you're still getting your work later and so you don't know if all that research and creativity is going to have any impact because you don't actually receive your work yet. But in Agile, since you're working in Scrum, since you're working every weeks, you're constantly interacting with your work and coming up with creative solutions at the same time. And you have your head down working on it.