No Estimates - Let’s Explore the Possibilities
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 133 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/48828 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
NDC London 201676 / 133
2
6
10
12
15
17
23
24
28
30
31
32
35
36
39
40
43
44
45
47
51
52
55
58
59
60
61
62
63
64
67
69
71
73
74
75
82
84
86
87
97
103
107
108
111
112
114
115
117
120
123
126
128
129
132
133
00:00
Software developerBlogNeuroinformatikEstimatorGoodness of fitBitSoftwareWeightMereologyProcess (computing)TwitterComputer animation
02:46
BitMereologyRandom matrixSoftware developerIntegrated development environmentEstimatorQuicksortState of matterMultiplication signLatent heatObject (grammar)Volume (thermodynamics)Computer animation
03:45
Type theoryLatent heatApproximationSoftwareCalculationEstimatorLatent heatSoftware developerType theoryPoint (geometry)CalculationBitMultiplication signDifferent (Kate Ryan album)Metropolitan area networkApproximationNumberGoodness of fitProjective planeWordFood energyExtension (kinesiology)Computer animation
06:04
Right angleMultiplication signProjective planeSelf-organizationData managementClosed setCommitment schemeEstimatorCASE <Informatik>PlanningDecision support system2 (number)WordShared memoryComputer animation
10:00
PlanningDecision support systemSoftwarePredictionSoftwareDecision support systemMereologyReal numberEstimatorProjective planeMultiplication signProcess (computing)Right angleBoss CorporationSoftware developerBitException handlingComputer animation
11:44
Cycle (graph theory)Software developerIterationDisintegrationBitProcess (computing)Object modelTerm (mathematics)Software developerExtreme programmingDesign by contractConstraint (mathematics)PressureFeedbackDisk read-and-write headMultiplication signIterationPlanningConfidence intervalEstimatorProjective planeMotion captureCodeINTEGRALOffice suiteView (database)DiagramSoftware testingComputer animation
14:49
IterationEstimationMathematicsIterationComputer programmingEstimatorMoment (mathematics)MultilaterationExpert systemMathematicsShared memoryFigurate numberComputer animation
16:10
EstimationControl flowIterationMathematicsEstimatorVideo gamePattern languageMereologyData managementMultiplication signRule of inferenceDecision support systemProcess (computing)Computer animation
17:18
NP-hardEstimationControl flowIterationMathematicsPattern languageSoftware developerQuicksortCycle (graph theory)Wave packetSoftwareIterationProjective planeComputer animation
18:34
Continuous functionCycle (graph theory)MereologyTransformation (genetics)Cycle (graph theory)Analytic continuationMultiplication signSlide ruleEstimatorTransformation (genetics)Block (periodic table)Computer animation
19:49
Direction (geometry)Right angleComputer animationDrawing
21:29
Control flowGame controllerPredictabilityDisk read-and-write headClosed setMultiplication signQuicksortDeterminism
22:40
Game controllerQuicksortEstimatorBitSoftware developerPredictabilityReverse engineeringCodeSoftwareData managementProjective planeTrailCross-correlationCausalityRight angleVelocityProgrammable read-only memoryComputer animationEngineering drawing
25:02
EstimatorBoss CorporationProcess (computing)Level (video gaming)FreewareMultiplication signRight angleComputer animation
26:18
Decision support systemEstimatorMultiplication signCodePhysical lawProjective planeDecision support systemSound effectQuicksortBitLine (geometry)Computer animation
27:47
Decision support systemCoefficient of determinationBitBoss CorporationMultiplication signSound effectSoftwareOnline helpSoftware developerDecision support systemComputer animation
28:45
Projective planeData managementMultiplication signBitGoodness of fitBoundary value problemMeasurementComputer animation
30:02
EstimationEstimatorPlanningQuicksortSound effectWeightExterior algebraComputer animation
31:10
SoftwareExterior algebraProduct (business)Pay televisionData storage deviceExistential quantificationMultiplication signBitShared memoryComputer animation
32:17
Integrated development environmentSlide ruleIntegrated development environmentDifferent (Kate Ryan album)Exterior algebraClient (computing)Regulator geneEstimatorMultiplication signSpacetimeFlow separationKey (cryptography)Computer animation
33:39
Control flowVapor barrierMathematicsGame controllerSelf-organizationMereologyWater vaporMoment (mathematics)CuboidEstimatorMathematicsVapor barrierForestComputer animation
35:17
Code refactoringWordGroup actionMereologyProgrammable read-only memoryExecution unitOpen sourceUnit testingExtreme programmingComputer programmingComputer animation
36:12
Computer programmingEstimationSlide ruleExterior algebraComputer programmingRevision controlSet (mathematics)Special unitary groupEstimatorMultiplication signTwitterComputer animation
37:13
Code refactoringEstimationDivisorFactory (trading post)Term (mathematics)Code refactoringPoint (geometry)EstimatorSoftware industryMeeting/InterviewComputer animation
38:19
EstimatorBlogSystem callProjective planeTerm (mathematics)TwitterType theoryData conversionComputer animation
39:40
Broadcast programmingDynamical systemSoftware developerVisualization (computer graphics)Projective planeData managementMultiplication signRevision controlScheduling (computing)MereologyShared memoryComputer animation
40:33
EstimationProcess (computing)Point (geometry)Series (mathematics)CalculationVelocityEstimatorSoftwareNatural numberSoftware developerTwitterBlogMetropolitan area networkBoss CorporationPattern languageDivisorScaling (geometry)Code refactoringPoint (geometry)Series (mathematics)VelocityCalculationData managementComputer animation
41:33
EstimationProcess (computing)Data managementEstimatorGoodness of fitMeeting/InterviewComputer animation
42:28
Software developerShared memoryTwitterData conversionSlide ruleMereologyMultiplication signBlock (periodic table)Video gameOffice suiteSoftware developerEstimatorSelf-organizationDesign by contractProjective planeComputer animationLecture/Conference
45:01
Product requirements documentSoftware developerNumberSoftwareProjective planeCuboidOptical disc driveAreaMereologyFuzzy logicRippingLibrary (computing)Computer animation
46:33
Product requirements documentLibrary (computing)CodeEstimatorProjective planeMultiplication signCalculationData conversionDatabaseBlock (periodic table)Computer animation
48:18
Cohesion (computer science)FeedbackMereologyCodeEstimatorBitProjective planeFood energyComputer animation
50:16
Maxima and minimaFeedbackCalculationCycle (graph theory)WebsiteWeb pageCalculationProjective planeSystem callProcess (computing)MereologyShared memoryDifferent (Kate Ryan album)Multiplication signBitEstimatorPoint (geometry)DataflowChain2 (number)Type theoryDirection (geometry)Web 2.0Cohesion (computer science)Computer animation
54:13
Software developerNumberReal numberCohesion (computer science)FeedbackCalculationImplementationComplete metric spaceDirection (geometry)Text editorSystem callProjective planeWhiteboardImplementationBitComputer animationLecture/Conference
55:17
ImplementationProjective planeQuicksortVideo gameBitDecision support systemLogicSoftware developerComputer animation
56:23
FeedbackBitSoftware developerFeedbackCodeProcess (computing)Computer animation
57:23
Cloud computingMultiplication signWhiteboardGoogolProjective planeSampling (statistics)QuicksortMathematicsEstimatorState observerMereologyComputer animation
58:24
MeasurementMereologyState observerBitMeasurementEstimatorSlide ruleProcess (computing)Goodness of fitLie groupWordComputer animation
59:47
Slide ruleSelf-organizationDrop (liquid)Forcing (mathematics)Goodness of fitSystem callQuicksortMathematicsBitProjective planeComputer animation
01:02:18
System programmingElectronic program guidePhysical systemComplex (psychology)Insertion lossLoop (music)Physical systemProjective planeCausalityWeightInternetworkingReading (process)Forcing (mathematics)Knot theoryReal numberComplex systemBitFunctional (mathematics)Right angleXMLUMLComputer animation
01:03:39
System programmingPhysical systemDampingPhysical lawSelf-organizationMultiplication signComplex systemFitness functionProjective planeBitPhysical systemSoftwareIntegrated development environmentComputer animation
01:04:39
System programmingIntegrated development environmentPhysical systemIntegrated development environmentFigurate numberPetri netQuicksortComputer animation
Transcript: English(auto-generated)
00:06
So I'm Woody Zuhl, I'm a software developer, I also have managed a lot of software development work and other kinds of work. I've been programming about 32 or 3 years, I got my first computer in 1982,
00:22
but I had worked in computers peripherally a little bit before that. And I really enjoyed computers, and it kind of overwhelmed me, eventually it was all I wanted to be doing, and so I converted to just doing that for my living. I've been doing software development for other people for about 15, 16 years now.
00:43
I'm going to share some of those experiences with you because they're really central to what I'm trying to share today. The talk's about no estimates. I'd like to ask, has anybody heard of this beyond this conference? How did you know about this? You know it beyond the conference? How far back?
01:01
A year or so? Where did you hear about it, may I ask? Don't remember, okay. Yeah, I wouldn't admit either. I did talk about this at Agile on the Beach, but under a slightly different title. Is anybody else familiar with no estimates? A little bit, where from?
01:25
Oh, yeah, yeah, okay. Okay, good, good. So at least somebody else is talking about it around here. So he's from the Cucumber folks or something else? Oh, I know Matt very well, Matt Barkham, okay.
01:41
He's a US guy. Yeah, he's great, he's great. I hope he did a good job for you. And someone else? From Twitter, yes, yes. So let's see what this is about. So if you don't really know what it is about, then that's what this talk's about. I'm going to share with you some ideas,
02:01
not so much about how you can work with no estimates, but why we need to be thinking about this. So let's see where we can go with it. About four years ago, I started becoming serious about talking about this out loud in front of people. Prior to that, I'd bring it up every now and then at conferences,
02:21
and I found that nobody wanted to talk about the problems with estimates. And as a matter of fact, I'd even found it to be very difficult sometimes to get anything beyond someone saying, no, we gotta do estimates. So I thought, well, let's see what we can do. And I started tweeting about it and writing some blog posts. And a lot of people became interested,
02:42
and that's why I'm here today. It's because some people became interested and wanna hear me speak about it at conferences. So this is the first part. I'm gonna just do a little bit of an introduction, a disclaimer, a question maybe that we need to answer, and a definition that we're gonna maybe do together. Let's see how it goes.
03:00
This is the most important thing. The object isn't to make art. It's to be in that wonderful state which makes art inevitable. It's a quote from Robert Henry. He was an art teacher and artist in the US in the Ashcan movement about 100 years ago.
03:20
To me, this speaks volumes. This is about the environment. If we set out to do something, if we prepare a wonderful environment in which to do it, that thing can just happen. That environment means a lot of preparation on our part. And that's sort of what I'm talking about here today. If you take one thing with you,
03:40
then this would be a good time to leave. Okay, we'll go on. So I have to have this disclaimer. We're talking about a very specific kind of estimates that are used in software development for a very specific purpose. Otherwise, people wanna talk about estimates of all sorts, and this is very focused on estimates
04:01
as used in software development of a certain type. So we need a working definition. So maybe somebody can share with me in one, two, three words, something like that, what is an estimate? What's an estimate? What's that? How long do you think something will take?
04:20
How long will something take? You think it will take. That's good. I like that part. Anybody a little different than that? How much effort? So, and how do we usually measure effort? Calories, burnt, or what?
04:42
Man hours, so we're back, we're on time. What else? What's that? Story points. Totally mysterious concept to me. I love the concept of story points. I think it started with the idea that people were having trouble getting past
05:02
discussing things as far as how long it would take, and he wanted to break them out of that and just make it some nebulous number. Is this bigger than that? So apparently, everybody thought that was a good idea. Does anybody still think that's a good idea? Hopefully not too many. Alrighty, so this is the definition I'd like to use.
05:24
An estimate is approximate calculation or judgment of the amount of time, the cost, the difficulty, or the extent, we could say or effort, of a project or feature or some bit of work in developing software. Now one thing I probably need to add to this,
05:41
sometimes the estimate is about how long it will take to do the work, and then a really funny little nuance is how long will it be before we get this work done? Because it's not the amount of time it takes to do the work, that we can kind of think about. It's all the stuff that comes in between, the blocking questions, the changes, the oh, we discovered something different kind of stuff.
06:04
Okay, so I think I wanna take about 30 seconds to a minute, if you don't mind, I'll get my timer out here, to discuss with someone sitting close to you, why do you do estimates?
06:21
And I'm gonna ask across the audience from a few people an answer to that. So let's see what we can gather, and let's say, we'll start with one minute, if that doesn't seem like enough time, we'll go to another minute. Would you do that for me? Go ahead and start. Just somebody close to you, if you're not too embarrassed to talk with them,
06:42
if you're sitting all alone, that's okay, talk with yourself.
07:45
You have three seconds left. All right, was that enough time? So what I'd like to do is just have somebody who's bold enough to just say, why do you do estimates?
08:00
Broken down here, why do you do estimates? What are the estimates you do used for, how are they used? I try to give us a little way to think about it. Somebody share it, yes. For customer commitments,
08:20
so the customer, you wanna commit to the customer, okay. They wanna scapegoat, is that what you're saying? So what you're basically saying is that the business needs estimates, so they turn to somebody in the organization.
08:41
Usually you push that down as far as you can, so you got somebody you can hold down. I'm probably speaking out of school there, but yes, so that we can make a commitment with a customer, to a customer. You had a?
09:05
So if the customer wants a fixed price agreement, but so let's go on, let's get a couple more. Yes, planning and for investment purposes. And so if we already have an estimate for value,
09:34
and we get an estimate for cost, then we can make a decision of what's more important to do. Yes, to know if it'll be ready on time,
09:44
the arbitrary time which we've set for it to be ready by, okay. Because the project manager tells you to. Let's see if that, is that a predominant thing here? Okay, so I think that we could take each one of these, see if this rings a bell. I think we could take each one of these.
10:01
We use estimates to help us make decisions. Somebody needed those estimates to make a decision. The customer's gonna decide whether to use you or not for this project. I won't go into more stories about this right now, but real quickly, I worked at a project once where we made a bid on something that was about $250,000 for this chunk of work.
10:20
Somebody came in with a $90,000 bid, and the company went with those people. Now, they were friends of ours or people that we knew, so we went in and talked to them and said, when it's all done, calculate how much you actually spent when you get to the end of this project. And guess what? It was way greater than what we were bidding on it. That was part of the time when I was discovering
10:40
this bidding process isn't quite working well. Sometimes we use it to spark a discussion about the work we're planning to do. So can we agree to this concept that it's about making decisions? I think in all these cases, except for the one when we're just trying to spark a discussion, but the end of those discussions
11:00
are usually some kind of decision we need to make, right? So is this close enough? Is this acceptable? So there's another way of looking at it, I'm afraid. In software development, estimates are often used to attempt to predict the future. This is about when will it be done? Somebody brought that up almost right away.
11:20
How much will it cost? How many people will we need? These are the things we're doing the estimates for. And if the estimates served us well, then we probably would be very happy to be using them. I'm not sure they serve us well. I could take a poll right now and get your temperature about that, but you might be here with your boss.
11:42
We don't wanna mess things up in your job. Okay, so what I'd like to do here is talk a little bit about my history so that we can see where this started for me and my feeling that we need to be talking about this. So first of all, before I go into this little lessons learned,
12:01
I had just gotten off of a job, this was in late 98 or early 99, where I was introduced to extreme programming. The guy didn't use the term extreme programming, but he was in that, he'd come out of the small talk world I think he knew a lot of the people who were talking about extreme programming, which later became agile. This is pre agile.
12:23
And so I learned a lot about extreme programming. Some of the things he did was rapid delivery of stuff. So he would fly to wherever the customer was. He was trying to solve some big problems. He'd fly to wherever the customer was. The first day, as soon as we knew we had some work to do, he would communicate with the right people,
12:40
get to the right engineers to figure out how to solve this problem. He'd start communicating back to us at the office, and he would send us diagrams, object models and all kinds of stuff, and we'd start writing code. He would fly back the next day or the day later, and we would start deploying stuff so that they could start using it and giving us feedback as to whether we were solving the problem or not.
13:01
And so on and so on. And once agile came out, I noticed all these things this fellow was doing was kind of captured in the agile manifesto. And that gave me a lot of confidence in what the agile manifesto was. As soon as that contract was, the three-month contract was over, I went on to this job here, where, and I just got to change that to 16 years. I think it's 16 now, 17 years.
13:22
It was a large project. To me, it was maybe the largest project I've worked on. 200 developers. It was going to be done in the IID, you know, IID, it's iterative incremental development. It was like a pre-agile concept. They were gonna use these six-week iterations
13:40
with two weeks of design, two weeks of code, and two weeks of integrate and test. It should be clear to you that two weeks is sufficient time to break those up. I'm sure that was a good plan. And then we were gonna do a lessons learned, and that's the main thing here. I don't mean too much to make fun of the people who were managing this, because I think they were doing the best they could,
14:01
given the constraints and pressures they were under. But breaking it up into arbitrary two weeks for this and two weeks for that immediately clicked off in my head that maybe we're gonna see some problems. I signed up for a three-month contract on this one. How long is a three-month contract? Some developers here. How long is a three-month contract?
14:21
What? Six months. Three-month contract goes six months. And they usually want to extend you after that, because the estimates weren't very correct. But this was supposed to be done in three months, and they didn't get it done in three months. They didn't get it done in six months. I left after six months because of some of the things we're gonna learn about here.
14:43
Matter of fact, they didn't get it done for a year after I left, and so I was just sharing this story with someone else just before. Here's the thing. We all charged into the first iteration. Let's get this work done. This is from my mob programming stuff, but I like to think of it as like, these people have gathered together to do some serious work.
15:02
Let's get it done. And then we did our lessons learned. The first one, the end of six weeks. What did we learn? There were two main things. The first one was our estimates were off. It was real apparent at that moment, our estimates were off. So we're reflecting on what we had done. What can we do to improve?
15:20
Well, what do you think? We need to get better at estimating. And the firm that was helping manage this had experts. They brought in experts to train us and show us and help us work through it. Also, the second thing I noticed, the big problem, the requirements weren't clear when we started, or the requirements kept changing. Do you see the relationship between the two? Have you ever seen or heard these things come up?
15:44
I hope you have. So what did we decide to do? We need to get better at understanding the requirements and controlling changes. Now that's not a new thing. That's been around forever. If we could just control the changes. Well, agile people were recognizing that controlling the changes isn't working well.
16:01
What do we need to do instead? Let's embrace change. Let's figure out how to work in a world where things are gonna be shown to us as we do the work. We'll share more about that later. So we worked hard to get better. We started right in studying stuff. We had to get better at estimating, so we learned a lot about it. We had to get better at controlling the requirements
16:21
and getting a better understanding. So we charged off to do our work. At the end of six weeks, we had another lessons learned. I noticed there were two things that were really predominant in this lessons learned. So we set out again to get better at these things.
16:43
Now, I being an older guy already had seen these patterns. But almost every there was about half my age and this was 15 years ago. So they were like 22, 23 years old just out of college. The oldest manager was 32 years old. Is anyone younger than 32 years old here? I'm not an ageist, but yeah.
17:01
I mean, you can't have made very many mistakes by that time, right? You gotta make a lot of mistakes. That's part of the rule, okay? And at 22 or 23, those kids had never made mistakes. They're just their first job, some of them. So we worked hard to get better at these things
17:22
and we charged off to do the work. I don't even have to tell you where this went. On the next, I'll just bring it in real quickly. So this is what I call a pattern. This is a pattern. What we have is something that's going over and over and over. And it's just like that.
17:41
It's a cycle. You guys know Agile software development? Any of you do something like Agile? Show of hands maybe? Okay, almost everybody. Every Agile training is just full of these cycle kind of drawings. This was a cycle. It's sort of an anti-pattern. And I reviewed this for quite a while. I did not bring up that we were not getting better
18:01
at this until the third iteration. And when I brought it up, I was ostracized. I didn't know I was ostracized at first. I would walk down the hall and these kids would just scatter in front of me. And then one day I cornered a guy. And because he was young, he couldn't get away. He didn't know what to do. And so I cornered him. I said, what's going on? He said, they told us not to talk with you.
18:22
So I thought, that's a hint to me that somebody knows this is a real problem but they just wanna keep charging ahead with the project. That's why I don't mention any names of the company and stuff. This is what I've come to call the cycle of continuous snow improvement. And if we just keep doing this blindly,
18:42
we are hiding from the real problems. And so this is something I thought we needed to discuss. I started bringing it up at different places I went to. So I learned something and I guess we'll show a slide of it first. This is about questions. This is about questions. I started wondering, what are the questions
19:01
that we need to be asking? It took me a long time to get to where I could find some reasonable questions. Because usually I would say, geez, aren't these estimates really a mess and things like that? And this is not helping us. And those questions just would lead to nowhere. So I once found this book,
19:21
The Answer to How is Yes from Peter Block. And this is just a beautiful saying. Transformation comes more from pursuing profound questions than seeking practical answers. That's a really deep kind of a thing. It's not getting answers to our profound questions.
19:41
It's pursuing the profound questions. They give us the right things to think about. So I really started thinking, what do we need to be talking about? So first of all, I really like to imagine what wonderful would be if I'm in a workplace, at home, whatever. What would make this even better?
20:02
And I really like that we can take baby steps to get from wherever we are to better. We don't need to know all about it. We can just start moving in what seems like a good direction and then steer and adjust on our way there. So I wanna start with this kind of an idea. It's important to question the status quo even if we think everything is great
20:22
because we can always imagine things to be better. So how can we make it better? So I question the typical approach to planning that requires that we know what we want upfront so we can figure out how to control and manage it as we go. I really like this drawing, by the way.
20:42
You know what this story is, right? Somebody knows. Who's the character? This is the Mad Hatter. I like this drawing because it's got that nice question mark coming out of the teacup. And actually, so my wife is the artist of all the work in my talk, pretty much.
21:01
And I don't think she even intended that to be a question mark. But when I saw it, I asked her if I could use it. She said, sure. And here it is. All the work that you see in here, she did for somebody else. And whenever I see something I think will fit, I ask for it. And she usually, if she has the rights to do this, so she'll let me use it. I think that what we want
21:22
is contrary to what is wonderful. If we're deciding up front what we want, this can be a big problem. Okay, so it's about control and certainty, but control and certainty of what? Because I think control and certainty could be okay. I left my phone, I thought, out here earlier. So I got into a talk
21:41
and I had to run out to go and try and find my phone. And then I thought about every, you know, retrace your steps thing. And I thought, it's either here or in the lost and found or where I was sitting in that talk. Guess where it was? It was where I was sitting in that talk. It had fallen under my seat. Well, I went back, I knew from that that I could go back and get it.
22:02
I need to have control of my phone. If I leave it somewhere, I'm doomed. There's good to have control and certainty about some things. But I think that the control and certainty can block us from those wonderful things. That's what I'm kind of exploring here today. When we focus on just getting that predictability
22:21
and that control, and that control of a cost and control of our time, when we focus on that, we will often have blinders on to the really good things that are around us that could be happening. But we're just saying we gotta drive to our goal to the end. And we don't get to do the discovery that we need to do.
22:40
Okay, so can we improve our chance at wonderful? Now that's sort of a yes or no question. Profound question shouldn't be yes or no. But I'm not perfect. Close to perfect. Here's the thing. I think that perhaps if we loosen our desire
23:02
to have control and certainty, we get a better chance at wonderful. That's what I'm trying to explore here today. A little bit. What if we could find ways to work that lessen our need to have that control and certainty and predictability? Just a little bit. What if we could just do away with it altogether?
23:22
What if we could work in such a way that we never know what the future will be? Guess what? Of course, that's the world we're living in. So let's go on. So what does this have to do with software development? What does this have to do with estimates? The problem is not estimates themselves. So no estimates isn't about not estimating.
23:42
The estimates are a signal to me because over and over again, I've seen trouble in software projects and also estimates. So is it, are these somehow connected? Is there a correlation there?
24:00
Is it causation there? What's going on? I think it's sort of the reverse. I think there's a hidden problem up above that leads to us having the estimates. So estimates act like a code smell, but it's a project smell or a management smell. When I go into a place and I see lots of estimates and estimates are really important and we're tracking our velocity
24:20
and we're doing all these kinds of things, then I start thinking there might be some reason we're doing that that we need to address. And let's find out, do we really need these things? So that's the hidden problem. The estimates are visible to me because everybody's doing them. I should have asked at the beginning, how many of you here have done estimates? Show of hands.
24:41
Almost every single person. I don't see anybody not raising their hand. That's a overwhelming majority, I would say, if it's 100%. Close, right, to overwhelming. Okay, so the estimates hint to me that there's a problem upstream. Let's go find out what that problem is.
25:02
Okay, so everybody brings this up to me. It's obvious you need to do estimates. You know, we need them, our bosses need them. That was like the overwhelming thing here. Our bosses need them, so we need to do them. Well, hopefully there's some bosses here who can be thinking about these things too.
25:23
Okay, this is kind of a weird thing. When estimates are completely right, I think that's a bigger problem than when they're generally wrong. Because when they're completely right, I think we've given up all chance of wonderfulness. And we've moved down to a level of mediocrity that makes it easy for us
25:41
to come up with reasonably good estimates. It means we're doing something that is so routine that we can do the estimates. Or that we've padded them so much that we don't have a chance of not getting done. Or at least having enough time to polish our resume and be ready for another job, right? So always be ready to move on to the next job.
26:03
I really like this picture a lot. I don't know if you can make out the smoke coming out of the chimney. It's very faint in here because of the light, but it's a skull and crossbones. So it's a beautiful free candy offer that has a hidden agenda.
26:21
I love this picture too, but the picture has very little enough to do with it. So how much discovery do we need to do? How long does it take before we have enough estimates, enough understanding to make reasonable estimates? Have we used up most of the time of our project? I worked at a place once where it took them about a year to get something into where they could start writing code for it.
26:41
A lot of work was done so they could determine how much it would cost so they wouldn't overrun their budgets or overrun their time. We spent a lot of time and a lot of effort trying to figure out everything up front and by the end we find out maybe a lot of those things we didn't need. Is the estimate still of use by the time we've really figured out
27:01
how long something will take? That's another question I like to ask. But this is sort of the bottom line of it. A lot of people say, well, we do estimates because it makes it easy to make decisions. But I'd like to know how do you prove that it was a good decision? If you decided to do this over that,
27:22
how do you know that this was better than what you would have got from that? By whatever you judged up front because you only did the one, you didn't do the other. What if we could find a way to do both somehow? Is there a way? And I'm going to propose a few things later. I'm not here to answer questions. I'm here to get us thinking about things.
27:41
I don't think that I know everything. I think that I do know we've got a problem we've got to investigate. So, oh, I'm going to share this drawing a little bit more. My wife did this for a very different reason. This drawing was about her getting an inoculation for something and then she felt invincible. And then her doctor told her, well, no, it doesn't take effect for about two weeks.
28:02
So she felt like, I'm just going to go home. I'm going to lock the door. I'm not going to let anybody in the house until this thing takes effect. And so I love this picture because it's like, really like about software development, decision-making. Like once you've made a decision, our dog represents the boss. You got the boss on your side, so he'll help protect you.
28:22
You're ready to protect yourself with the shotgun. And as the weeks go by, you're becoming more and more irrational. Every time you defend a bad decision, it gets, you get more, a little bit, it becomes a little bit more difficult to keep defending it. And yet you still have to keep doing that because you know pretty soon
28:41
they're going to catch up with you. But I love the drawing. Okay, so I think this stuff is a trap. We are trapped by what we want. And when we decide on what we want, we're now inside that trap. Everything we do has to go for the what we want. When we've declared to the customer, we're going to have it done at this time.
29:02
I've talked to several people at this conference. I try to do that quite a bit, who've expressed that exact same problem. Once we've committed to a time, everything else kind of goes away. And the quality is going to be worse. The amount of stuff we can get into the project is going to be worse. And the good things that we thought we could discover along the way, we can't get in
29:20
because we got to do what we originally committed to do. Okay, so I love this quote from Russell Acoff. Managers who don't know how to measure what they want settle for wanting what they can measure. I think it's a brilliant quote because this is what kind of happens. How do you measure goodness and greatness and wonderfulness?
29:42
We can't. Can you measure things like friendship? If you have a method for measuring friendship, you probably don't have very many friends. You know, it's some of these things we can't measure, we just have to sense them. We have to know what our boundaries are and things like that.
30:02
This is what I think happens. I think we become inflexible. I think even further, there's this hardening agent that things like estimates and upfront planning do to us. It hardens us about the thing that we are setting out to do and it keeps us from doing the things that could be wonderful.
30:22
It's those things we think we want. So, whoops, is there a better way? Is getting better the only way? Is getting better at estimates? You know, like eating junk food. How good can you get at eating junk food to help you not get the bad effects of junk food?
30:43
There isn't a way to eat it better. You can eat it less, maybe not eat it at all. I have kind of that problem where it's like garbage in, garbage stays. You know, as soon as I eat something like candy or whatever or soda pop, I gain weight. And then after a week I go, oh no, I gotta lose weight again. It doesn't take me too long.
31:02
This is sort of what I'm talking about here. Maybe there's something other than estimates that we can be doing. And again, I'll propose a few things, but that's not the main purpose of why I'm here. Maybe there are alternatives. So I'm not suggesting there's alternatives to estimates. If we want to know how much to tell a customer,
31:22
so we can tell a customer how much something's gonna cost, unless we already have done the work and know exactly what it will cost, then we need to have some way to do it. You know, when you go into the store and you're gonna buy some milk, you don't say, can you estimate for me how much this milk will cost? They'll just tell you the price. You know, and that's what customers want.
31:41
They want a price. But software doesn't lend itself well to this give them a price model, unless you're selling an off-the-shelf product. Nowadays, a lot of them are moving to a subscription kind of style where you pay monthly or yearly for something. So are there better ways? Well, I'll share that in a little bit, some of mine,
32:01
but a lot of people are doing better things already. If I were doing a workshop on this, this would be a good time for us to be discussing what some of the better ways that we think there might be. So you might think about that a little bit, because we really don't have time to cover a whole discussion about it, but I'm gonna cover that in a little bit. So this is the thing. What should we be certain about?
32:22
If we go back to my very first slide, what should we be certain about? Now, this is what I think. If we're certain that we have this environment where discovery and innovation can happen, then we're gonna do wonderful things. Let's see about becoming certain about that, becoming really good at having that in place.
32:42
This is where these great solutions are gonna be inevitable. They're just gonna happen for us. That means a different working relationship with our clients or a different working relationship within our company. We gotta find a way to do these things. So these are the alternatives I'm suggesting. I'm not suggesting we have an alternative to estimates.
33:01
Matter of fact, there are estimates that I can do very easily that work well for me. One is I was managing a team for several years. They need to know for the budget next year how much do we need to set aside for this team or have available to us. You know, their salaries, their vacation time, their desk space, all those things. I can estimate that. That's very straightforward.
33:21
There's some things we can't estimate. If they were to ask me, well, how much work will they get done? I don't know. I don't know if I'm gonna lose a primary key player on the team. I don't know if the kinds of work that's coming is something they can do yet, and maybe there's gonna be some new regulations we need to follow, and who knows? I don't know. So what should we control?
33:41
What must we control? I like this. Let's learn how to control our urge to control things, because that's part of the problem, is we want control when maybe letting things go is a better thing. I'm not really 100% clear on how to explain this yet,
34:01
but I've noticed it in several organizations where I've worked. When we've let go of that and just let people become excellent at what they do, we got a lot of benefit out of it. I think we gotta learn how to do that. Let's learn how to take advantage of what a humanity is instead of trying to control it and put it in little boxes and make it operate in very specific ways
34:20
that it's not really set to do. But this is some kind of a caveat you gotta watch out for. You probably all know who Bjarke Bugesnes is from the Beyond Budgeting movement. He works for Statoil. He's a very prominent speaker on this topic, and he's a big wig there at Statoil. Fear of losing control is a big barrier for change.
34:41
Although much control is only an illusion of control. The fear is real. Can't be ignored. And I think that's why in the earlier years it was really difficult for me to talk about this because everybody's afraid of what happens when we no longer estimating things.
35:02
If estimates were really, really precise or that's really not accurate and really useful for us, we wouldn't be calling them estimates. We'd be calling them facts. I stole that from somebody else. I like that. So part fourth, a word from recognized industry people.
35:23
I wanted to put this in just because I don't look like a lone lunatic. I'm just a group of lunatics. No, it's just some other industry recognized people who I've been able to find quotes from that make it seem like what I'm talking about makes sense.
35:40
So the first one is Kent Beck. I hope everybody here knows who Kent Beck is. Let's see that show of hands again. Almost everybody does. If you don't have his books, you should get a few, at least the Extreme Promoting Explained and maybe the TDD book. He's a fundamental player in our industry. I think he is the original source of the idea of unit test frameworks. And if I'm wrong about that,
36:00
I would quickly, I would welcome a correction, but I'm pretty sure he wrote the small talk unit testing framework that grew into being J unit and all these other things that we use. Here's a great one from him. Please estimate. What percent of worldwide programming effort is burned in dysfunctional behavior driven by deadlines that are just guesses?
36:23
That's a great quote. I think I got most of these slides online somewhere and I might try and put this set online as well. This next one is really great from him. Alternative to estimates. Do the most important thing until either it ships or it is no longer the most important thing. That is like in a nutshell,
36:42
that's a tweetable sized thing. I've retweeted a few times. It's tweetable sized. It's like a condensed version of my methodology. And matter of fact, I don't really care about the most important thing. All I care about is something that's kind of important. Because we'll discover what the most important thing is
37:01
as we start doing stuff. I think it's a great quote and you could tweet it as well. You don't need to even say that you got it from me. Just pretend like you discovered it yourself. But actually he tweeted it out and that's how I found it. Martin Fowler, you probably all know of Martin Fowler as well. And actually I'll point out that the refactoring book, which was one of the very early books
37:21
on the subject of refactoring and maybe is where the term came from, was one of the things I studied a great deal and was very happy to see automated tools coming out for refactoring. But if you go through that book, you get a feel for what it was like just 15 or so years ago. But he's done a lot of great stuff for the software industry.
37:41
I'm not sure he agrees with me on these things. But I got a couple of quotes that I think worked pretty good. As teams progress, they first struggle with estimation. You can see where this is going. Then they can get quite good at it. And then they reach a point where they often don't need it. I wanna skip to the end.
38:02
Let's start down here. I've worked with several teams where we went in and we started not knowing how to do estimates and never did them. Why do we do them? It's because wherever we went to work, that's what they required. What if we could just not do them?
38:21
This is another one from Martin. Beware of anyone who tells you estimates are always needed or never needed. I think this might have been directed to people like me. I don't say estimates are never needed. No estimates isn't never estimate. The reason I use the term no estimates, by the way, is because Ron Jeffries
38:42
and I had been exchanging tweets back and forth about a project I was on where we didn't use estimates of the type I'm talking about based on our earlier definition. And he said, why don't you write a blog post about it? And I said, I will. Here's a blog post about where I didn't use estimates. I used no estimates to do some work
39:01
and exactly how I went about it and I'm gonna share that with you. And I used the hashtag no estimates and that just got a lot of attention, much of it very negative attention. But also, it was a call out to people who'd also seen the same problems I had seen. So I've made literally hundreds of friends
39:21
and have had hundreds of conversations, mostly through Skype, all over the world with people who are trying to think out these same things. So this was a powerful thing. I never have said never estimate. As I shared already earlier, I estimate some things, just the kinds that we're talking about here. I don't think they're too helpful.
39:41
Michelle McCarthy, who's Jim McCarthy's wife, I believe. Jim McCarthy, does anybody know who Jim McCarthy is? He wrote a book called The Dynamics of Software Development in 1995. I got it when it first came out and it's an extremely interesting book that very much predates Agile, but it's got a very Agile mindset to it.
40:02
He was an important developer at Microsoft who worked on the, when Visual C++ was first coming out, he managed or ran that project that was the first version of Visual C++. Used to be Visual, I mean, it used to be C++5 or something like that at that time.
40:21
One of the problems with the schedule is that it gives you the idea that you can take that long. Now, I share this because when we get to the part where I talk about how I do things, this is really critical. Ron Jeffries, who I really love and this is a book well worth getting, takes about an evening to read and it gives a lot of the nature of software development
40:42
in a very concise and clear sense. And I love this. Estimating when we'll be done is wrong. Forcing the answer is worse. I found that to be a very good quote. Could have come from Twitter. It might be from one of his blog posts.
41:01
He's a wise man. Here's my former boss, Joshua Karayevsky. I worked with him for a while. He wrote this wonderful book, Refactoring to Patterns, which is a very important book on refactoring as well. He wrote a blog post in 2012 about an experience his team had in 2007. In 2007, a series of experiments led my colleagues and me
41:23
to increase our agility by dropping story point and velocity calculations. So this is other noted people. Oh, I'm gonna show you one more. Fred Brooks. I wish I could smile like that. You just couldn't say you're wrong to this guy.
41:42
But everybody's read Mythical Man-Month and these other essays that he's written. So this is peripheral, but I think it's pretty good. It is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitative method supported by little data and certified chiefly by the hunches of managers.
42:03
And we'd like to say we do our estimates based on a quantitative method supported by a lot of data and it's not certified chiefly by the hunches of managers, but I don't think we can say that. If anybody has a method for doing that, I'd like to hear about it. I'd love to hear about, if you have a really good method for estimating,
42:21
I'd love to hear about it. And then I could squelch it. No, I'm kidding. I really want to know if there's a good way to do estimates, if they're meaningful. Also, I'm gonna share just Vasco Doherty. You can find him in Twitter. He's written a book about the topic and he was one of the early people who joined the conversation.
42:40
I sort of joined the conversation he was in in 2012 and we met via Twitter. And also Neil Kilik from Australia. Vasco's from up in Finland. And Vasco's actually I think from Portugal, but Neil's from Australia. So these are people all over the world. So I just leave them in here because they'll be in the slides and people can look them up.
43:01
Great folks who are part of the discussion. So we moved along pretty good. I think we have enough time to finish out nicely. Part fifth. So practical stuff, but first a warning. Another thing from Peter Block. I love the guy. The value of another's experience is to give us hope,
43:24
not to tell us how or whether to proceed. This last part of the talk, almost last part, I never used to share because I don't want to bias or anchor people on what I think works. I want to have the discussion about
43:41
what do we need to deal with not how are we going to deal with it. But people kind of insist they want to know how to do it. Vasco's got his own way. Neil's got his own way and I've got my own way. Everybody's different. My way's very different than theirs. I think predicting the future is pretty much not worth trying to do.
44:01
It's like, can you predict how long you're going to be married? You know, a lot of people think that's going to be for their entire life and then they find out it wasn't. Okay, now I've been married 32 or three years now and we've decided to make it permanent, but you know, like how long will you love me?
44:22
We want to know from somebody, so let's put it in a contract. We've learned really quickly what love is after that, right? It means we're going to change ourselves an awful lot. Let's hope we get good at that. So I'm not telling you how to do something. I'm so much as giving you the hope that you can figure out your own path
44:42
that will work for you and your company and you might not be able to. I think there's a lot of organizations where you can't do it, but I've visited some big government offices here in London a few days ago and they're working without estimates for their software development. Don't tell anyone.
45:02
So I use this piece of art to demonstrate what we think of as our project definition. We've got this document that's very clearly laid out, all the parts, how they go together. I love this because it shows some really odd things, like we would put together certain things
45:20
because they happen to fit in the same kind of container. You know, that's an interesting one in software where we think that everything's nice and neat and we can easily explain it to someone and when we close up the box, we can go deliver it to the people who are going to write the software and they can just open it up and do it. This isn't the project itself, this is a definition of the project and I think our definition of the project
45:40
is more like this. Now you all know who Jackson Pollock is probably, he was a well-known artist back in the 40s. Jack the Dripper, some people called him, I really loved his artwork. When I was a kid, maybe 12 or 15, and I first saw one of his pieces, it's like 15 feet tall and 30 feet wide and you walk along and you're just overwhelmed
46:01
by the nuances of this thing. But this isn't really how our project is, this is how our projects are. We have these very fuzzy edges and fuzzy areas in the middle and when you get to the edge, it extends out and you go, oh no, there's more stuff on the other side of this foggy area
46:20
and when you're in a fuzzy part in the middle, you can look up or maybe look down and you'll see more of the same stuff. It's all interconnected and we don't know how to pull it apart. This is how I think our projects really are. If it was so neat and easy as this, then yeah, we can estimate this. It's rare that we get projects like that. And if we do, there's probably a reason
46:41
we should stop doing projects like that. Why don't we just turn this thing into a library that our other code can use? Why are we writing it over and over? Alrighty. So, this is one of my sayings. It's in the doing of the work that we discover the work that we must do because the doing exposes reality. I've talked, I specifically, when I come to a conference,
47:03
I talk to as many people as I can. I've had a conversation with at least 20 or 30 people here throughout the conference. And this basic idea is recited by people in every conversation I've had. Sooner or later, they'll bring up the idea that until we actually start writing the code,
47:21
we don't know what we're up against. And if that's really true, which is kind of seeming to me like it is, it certainly has been for me, that we need to figure something out because we can't know ahead of time. There are those unknown unknowns. And it's usually the things that, those are the things we can't estimate, we can never estimate. And those are the things that are gonna extend our project out.
47:41
When we come to something that we don't know and we can't get an answer, we're blocked. How long is it gonna take to get unblocked? We don't know. We have no way of knowing. Can you estimate how many unknowns you will get in a project? Can you estimate how long it will take for any specific one to get cleared?
48:02
If you can tell me how to do that, then you also know how to use a null in the database in a calculation, like null times five. How much is that, five nulls? You guys know what that means. Okay, so this is what I think. I really love this drawing.
48:21
This is what I think. If I can find something that's recognizable, understandable, distinct, cohesive, which means it belongs together or it's drawn together, potentially valuable, doesn't have to be valuable. If I can find that chunk of stuff, then I've got something I can work on. The understanding is one of the main things.
48:43
Because if you can't understand it, it's not yet cohesive, it's not yet distinct. We have to get it to a size that we can understand. That doesn't require an estimate. If you take some stories and you estimate this one to be 12 and that one to be five and so on, you're not changing the size of what you're looking at.
49:03
But if you can understand it, it's very simple. If I have, I'm gonna do an example. I'm gonna just take a piece of paper. If I have this piece of paper, it's of a size. Anything that I bring off of it is smaller than this. And this becomes smaller.
49:22
I don't need to estimate anything. That is now two smaller bits. I just know they are, right? Do you see what I'm saying? It's when I can say this part I can understand, then I've got something I can work on. If this was too much to understand, then I don't have something I can work on yet. That's how simple this is.
49:43
I wanna be able to decouple it so I can work on it. It has to be cohesive. If it's not cohesive, that means these things don't really belong together, then there's too many different edges to it to work on. I want something that belongs together. It has to be distinct from the rest of the requirements,
50:01
but not from the project work that's already been done, the code that's already been done. I wanna work on it, deploy it, and that's when I get to learn about the thing. And hopefully we're learning along the way as well. Let's go on a little bit further. So if we have that, and then we do this, it becomes one of those cycle things
50:21
we talked about earlier. I can just do this over and over, because once I think I understand something, I might not understand it. My mom used to always say that to me. I often would misunderstand what she told me, and she accused me of doing that on purpose, but it's just because I didn't understand.
50:41
I'm not sure I ever did it on purpose. She probably knows better than me. She was my mom. But you get the picture here. If I can do this over and over, I can deliver a large, complex, confusing project. This is what I'm after, this little cycle. So I'm gonna share an actual example.
51:00
I'm gonna call this one 12 calculations, but I literally have dozens of these. So pretend this is a requirements document that came to me, 80 pages or 100 pages. And in this real project, this particular one, they came to me with a long requirements document, all the things they figured out about that project. And me with my little team,
51:21
we only had a little bit of time to work on their stuff every week because we had some other bigger projects we were working on. So I asked them, what in here is the most painful thing to you? Now, it doesn't matter if it actually is the most painful thing, just that it's what they perceive as being the most painful. And I think it was probably,
51:40
I think it was the one with the polka dots holding up the little one over there. So they put that out, and I said, help me understand it. So how can I understand it? I can't understand it in its fullness, but I can understand it in a little part. So they started explaining it to me. This is exactly what happened.
52:01
Let's just calculations, so I'll tell you a little bit more about the project. The project basically is about a manufacturing business has to figure out what work to do this week of different types to keep the flow going through the factory. It's that simple. And they had a bunch of calculations they had to do about how all this stuff fed together.
52:20
Some of these were chained together, that's why we got it like this. But some of them kind of were inserted in the middle and so on. So you had to do this calculation first, then that one, they're each fed with different stuff and from stuff that's earlier in the process. So we took that big one, it was a big pain point. I can't do all that in the time we have because I don't even understand it yet.
52:42
Help me understand something. So they started explaining it to me, and we understood this. Soon as we got to something we understood, I said, I think I can work on that. I think I can work on that. But this chunk here doesn't seem cohesive with the rest of this. So now we've got something that's understandable, it's cohesive, I've made no estimates to get to this.
53:03
Do I understand it was what I'm trying to judge. Is it cohesive and is it distinct? Can I do it without the rest of the stuff? Then we wrote it. And then we delivered it. Then we took the next one. Oh, something happened at that time after we finished that. Somebody thought about this for a while
53:20
and they said, this early one is really critical because when we mess this one up, we have to start all over again back to here. A lot of these we can fix it later on, but with this one we can't fix it later on. So they had been gaining knowledge now. They were starting to get experience with that bit, we did the same thing. As soon as they got part of it that was understandable to me,
53:40
and I said, yeah, I think we get this, we can work on this. This part is not cohesive, this part is. All we've done so far in the project when we're done with that one is these two little bits. How many of these do you think we did? We ended up doing about three of them. I'll share a little bit more about that in a second.
54:01
That's the big win. We got rid of two big pain points already. We did one more. But look at how much we did of them comparatively. Here's the thing. This is what I call the, oops, I went the wrong direction completely. I'm very sorry. The editors for this show are gonna really have a pain now.
54:25
I clicked on the wrong clicker. It's all right, you get to have a review. Hopefully that was useful. I call this the 80-20-80-20. Now this isn't really a rule, but in general you get about 20% of the features in a project give us most of what people use.
54:44
And I was thinking if we could discover what that was and just do that, wouldn't that be wonderful? But you can't really do that. You can get close to it. You can do the potentially 20% stuff. Let's try and focus on that. However, what if about 20% of the implementing
55:01
of any particular feature, the implementation we do gives us most of what people want out of it. Let's discover that little bit. That's what I'm kind of demonstrating here. That's what I'm demonstrating with these little pieces of paper. Here's what happens. You take that little one thing you think might have value, whoops, you do 20% of it, and deliver it.
55:23
And then we can discover do we need to do any more of it. And this is what I call deliver features until bored. As soon as they get bored with it, they don't need any more, and they tell you that. So after the third one of these on this particular project,
55:40
we went back and said, now what's the next thing you want to work on? This is exactly what they said. Well, we still want to work on that, but we got this other project that's more important to us. And they got the little bits they need. How much more of this project do you think we ever did? Zero. They got just enough. It's like if you cut your hand or something,
56:01
and you get it all bandaged up, but it still has a lot of pain, and they say, well, we can give you some shots so you don't feel any pain at all, or we can give you an ibuprofen or something, so it numbs the pain just enough and you can keep on with your daily life. That's sort of what we were doing there. They got just enough. It was their decision. They can have more of this project
56:21
or pick something else. This works pretty good for me. So here's the thing. Why don't we just crank this up? Let's see how many attempts at delivering a little bit of value that might teach us something that we can do. Well, there's basically a philosophy of software development that gives us this, and that's of course agile.
56:41
That's what agile is. We get an idea. We turn it into a story. I don't know why they call it a story. We design and code it to pull it into real use. We get some feedback. We evaluate it, and we go on. Where within this process can we do discovery? Where's it gonna happen?
57:01
What? All the way through it, everywhere. As soon as we express an idea, when we start sharing an idea with someone else, that gives us a chance for feedback. As long as we keep it hidden, we don't get a chance for feedback. It has to be shared with others. And then the idea will grow.
57:21
Things will get better. Okay, so agile does this, and we get these tons of little shots at bringing something of value. This is what I'm after. I wanna get to that deliver until board thing really quickly. I can give you example after example of doing that. And I think Google and other firms
57:41
seem to follow that same idea as well. When I first started using Google Maps years ago, I thought, oh, this is pretty good. This works well. And then like three days later, I go, hey, I didn't notice this feature. That's really good. And then like three days later, what does this thing do? It wasn't there before. And pretty soon I'm clicking on stuff that wasn't there a week ago. It finally dawned on me. They're just changing this thing all the time.
58:02
I thought that was pretty cool. So here's the thing. I haven't done estimates of this sort in work for over six years now, doing literally dozens and dozens of projects. This is real stuff. This isn't faking it. So let's finish up. I hope I've given you some hope.
58:22
That's about the best I can do here. So my part six is just a couple minor observations. First of all, I took Russell Acoff's quote from earlier and I expanded out a little bit. Most of the things that really matter cannot be measured.
58:41
So instead we allow the things that can be measured to become what matters to us. So this maybe isn't as clear as what he said, but this is the way I kind of take it. I'm really worried usually when somebody starts saying we can't make improvements unless we know how we can measure,
59:00
because I think we can sense the improvements. Most of the stuff that's really worked well for me over the last seven, eight years has been because we have sensed how good things were becoming, how we sensed that the things we were doing were helping us. And after a while, we can gather enough, evidence isn't necessarily the right word,
59:22
but when these people get goodness delivered to them regularly, frequently, they stop asking for estimates. The whole process flips over. And now they're trying to catch up to what's the next good thing we want instead of wondering why you haven't finished
59:41
the thing they asked you to work on. It really works well. So I think my last slide is just the same first slide we started with. I hope this was helpful to you. And I didn't give you any answers, but if you feel that I have, come and tell me where I made my mistake.
01:00:00
So we're done. Thank you. We have a few minutes left, but I Could answer questions. I don't know if that's useful. Yes Six years a little more than that really. What's that? I
01:00:23
Can't convince anybody of anything he's asking how I can convince organizations to do this To let me do this. Actually, there's a microphone there if we if we want to do questions that way But I can just reiterate them. I can't do that. So what I what I usually do is Look for organizations that are already ready for this and I don't mention it at other places
01:00:46
Was there another question? Fixed price projects we need to estimate somehow and I'm saying I just don't see how we can do it So if you think if you find a way that you can do it
01:01:01
I'm all for it if you have a way to do it do it But I'm just saying I after all of this, you know I'm saying I don't see how that can work unless we're doing so mediocre of things or We're really good at convincing somebody once we've given them a low price So they'll hire us To keep on paying us more for all the changes they're gonna need because we know up front that they're gonna change a lot of
01:01:22
Stuff that's sort of what most of the industry does. I wish I could solve that Right, and that's what I'm saying I think is broken that we need to tell a price initially and I think that we got to find better ways to work There's kind of the idea of drip funding There's the idea of let me let's do a little bit of work over the next two weeks and see if we can work
01:01:42
Well together, you know, like you go in the doctor and he says, oh, yeah, I got a pain here. You tell him He says oh, yeah, we better investigate that Well, how much I don't want even start unless you tell me how much it's gonna cost, you know Well, I don't know. What are we gonna find in there could be cancerous. It could be you just have some gas, you know So we're not gonna do the work until he tells us the final price and then he says
01:02:04
It's gonna take three weeks and it turns out you're dead in three weeks. Are you happy? You know, I'm not sure I don't think there's an answer to that that I can give Now I have a couple bonus slides. I could quickly go through. Do you want to see some bonus slides? Okay, first of all anybody ever hear of I call this the park encore. I
01:02:23
Force it on you. You are too kind Okay, this is a causal loop diagram, I think that's what it's called I Took this off the internet somewhere. This is about I Think this is about weight loss or something. I'm not sure but if so
01:02:45
And our projects are like way beyond this So here's the thing. Have you ever seen this book from John Gall the systems Bible well worth reading I'm gonna share some things real quick. We got like one minute to be done the systems Bible a complex system that works is invariably found to have evolved from a simple system that worked
01:03:06
That is all working complex systems started out as working simple systems a Simple system may or may not work a Few simple systems are working. So that's what we need to get good at look to figure out
01:03:23
What does it look like to have a simple working system? Some complex systems actually work We're an example of that right? We essentially work all these things that are put together in a somehow function We've got a few bits in there that don't do anything anymore, but pretty much we work. I
01:03:42
Just love this big systems either work on their own or they don't if they don't you can't make them work These are laws or he kind of poses them as potential laws a complex system designed from scratch never works It cannot be patched up to make it work How many projects we've been on that that's what we're what we're doing in our organization. This isn't about the software
01:04:06
Although it all fits for software, too I'm talking about the organization how we do our work a working complex system that is no longer useful Cannot be changed to make it work. It will keep doing what it will evolve to do initially That means that we're going to be working within a broken system
01:04:21
That isn't serving us and it's just gonna keep doing what it does If you have one of those you either have to start over with a working you have to start over with working simple system And I think we can devolve our system. So I'm not really sure of that yet Some complex systems actually work. I left that in one last little bit and we'll be out of time, right?
01:04:42
What can we do? I don't know You know if I knew what I'd be here at a conference Perhaps we can figure out how to provide an environment where simple systems are given a chance to work Have lots of them and find ways to get them to evolve figure out how to grow them in their petri dishes or whatever That's kind of where it's at last one last side that I stole from Dave Farley
01:05:07
And you all know who Richard Feynman is and if you haven't read his books he's worth reading But this is sort of what it's all about We trick ourselves So, I guess we're done so no need to clap again because I won't do another encore. Yeah
01:05:24
So thank you very much