- There’s always money in the banana stand
- Linked to purpose
- Why it’s so important
- Shared vision unifies the team
- Decision making is easier with vision
- Vision plus implementation is magic
- Cost of misalignment
- What is an interruption?
- Culture of interruptions
- How does it effect prioritization?
- Planning impossibilities
- It has to be on fire to get done
- It kills teams
- Poor decision making
- It’s contagious
- Loss of innovation
- Balloons for everyone
- Individual, Team, Organization
- Human Resource priorities
- Rate of change
- Performance reviews
- Emotional response
- Personnel turnover
Clayton: Welcome to another episode of the Scrumcast. I am Clayton [?]
Ray Van Norter: I’m Ray Van Norter.
Jade Meskill: Jade Meskill.
Derek Neighbors: I’m Derek Neighbors.
Mike Finnister: I am Mike Finnister.
Jade Meskill: We have Derek and Mike on Skype with us.
Clayton: Today we are going to be talking about the cost of change, when I hear that I think of certain things and I am sure you guys think of other things. I am just curious Derek, from your perspective what is the general definition of that so we can get started.
Derek: Change or the cost of it?
Clayton: What do you mean when you say the cost of change? Who are you talking about and who is involved?
Derek: When I am thinking of this, I think of it both on an individual level, I’m thinking at a team level and an organization level, so I think that a lot of times developers or managers might say, “Hey I really want my team to do Scrum because we’re going to get all these benefits,” and they don’t think about the ramifications that’d happen when they do that. A number of things change whether you implement para‑programming, whether you have a wide open work‑space.
I remember one of the first things to change at Integrum when we really started going full bore is, we went away from personal desks and went to paring station, and just the ramifications of people not having somewhere to put some their personal things, and some of their emotional baggage that came out of that that we had to deal with, was certainly something we never even considered as being one of the byproducts or the problems with that.
Derek: What happens to HR when you have totally cross‑functional teams and they’re completely dependent on a job title to determine how to pay somebody or to determine how much square footage they get as an employee. I’m a CEO and now I’ve got an actual team that’s doing an implementation that is starting to expose problems with maybe the way I incentivize my sales people, is actually damaging the organization and now I have to think about how I compensate sales people to be different so that they can be a better part of the whole organization. To me it’s what are those elements of change and what can one really start to expect and how you cope with that.
Clayton: Mike is someone whose maybe experienced some more of this stuff in a large organization. Kind of like what Derek was talking about, where you maybe have a group of people that are cross‑functional and it’s hard, murky water to determine pay scales and bonus programs and those kind of things. What are some patterns you’ve seen, or some things where people get it wrong?
Mike: A lot of times they don’t involve HR right away. Remember HR in a lot of large enterprise organizations have very different priorities than this little scrum team. Maybe that’s starting to take hold.
You really have to start to get on their radar early, and often, and understand that any kind of changes are going to be maybe years away. Being able to get HR on board is especially important. Especially when you’re talking about the matrixed organizations where you have scrum teams working in large waterfall projects.
Clayton: You mentioned getting HR involved. There are a lot of times where I think a lot of companies have slow moving HR departments. Or just in general there’s some red tape and bureaucracy. How does that contrast with the way that we think of Agile and the way we think of making change, and implementing things quickly and iterating and those things when the typical life cycle of doing almost anything is usually much longer than, say, a sprint?
Mike: Part of that involves really, again, getting people on board. Normally when I start teams in large organizations I’ll let them know that they’re probably going to take a hit on their performance evaluations. Like, one in the first year. Because now they’re not being specialized working as cross functional team members, and all of a sudden as a tester, let’s say as a role, they’re being compared to other testers within the functional organization.
With the traditional, “Do you play well with other teams, do you have your nice power point presentations, do you do your executive exposure, do you play nice with others, do you have work on 20 projects at once?” You don’t rank that high against other testers that you’re being evaluated against. So being open and honest about this is really important.
Clayton: Jade and Derek, as far as the Integrum we have maybe more feedback than a lot of organizations from the management to the employee level just because we’re so flat, but when you have a traditional organization that wants to do performance reviews like Mike mentioned, and they have a very set way of doing those things and mentioning that stuff, I think one of maybe the benefits of Agile you could get into is you could say there’s extra feedback. You know where you are a lot of the time and those kind of things. What’s the reconciliation between those? The traditional personnel review and that kind of constant feedback and being part of a team, not necessarily an individual anymore?
Derek: So I think there’s a multiple problem. So one is, is the content of the actual performance review relevant anymore? Meaning usually HR has a fairly good amount of weight that they’re allowed to put into how you structure your performance review, and it’s fairly standard to‑the‑book type of format. When you start to talk about being on an Agile team, it’s really more about values, principles, and goals and a lot less about individual duties and what your job is specifically. So a lot of times you don’t have an actual performance review that matches what you’re doing.
Two other problems I really see with the performance reviews are that they incentivize the individual instead of incentivize the team, which is obviously fairly contradictory to Agile methodologies where it’s really about the team instead of the individual. Then lastly is I think a lot of things that go along with performance evaluations deal with ranking employees and pitting this person against that person. They actually create mistrust within a team.
Derek: So the best I would do if I’m in a situation would be to try to hold reviews or have the discussions that are much more honest, much more true, outside of the performance review and then fill out whatever performance review is necessary to turn into HR to placate them and congruently be trying to get HR to change their practice so that they’re more in line with being an Agile organization as opposed to being the dinosaur organization.
Clayton: I agree with what you’re saying, Derek, but I also think that we do need to have some mechanism of dealing with the individual as well. There are a lot of ramifications that a poorly performing or a bad fit can have on the whole team. So creating those mechanisms that can deal with the individual behavior and I think tailoring the reviews and the feedback to the very specific individual person at that level is good as long as you are also dealing with, like you said, more of the team context as well.
I think somewhere is a balance between those two aspects. You can’t completely forsake the individual for the team or vice versa.
Derek: So I think to me where the problem comes in is that most performance reviews are structured towards the skill that you do, and I think that’s a bad way to do it. So if you’re monitoring me for how good of a software developer I am and it has to do with the amount of code I’m producing or the number of commits and, I don’t want to say necessary metrics but, things related specifically to code, I don’t know if that’s a good representation of whether I’m a good individual for this team.
I think it’s Tom Lister. One of the things that they did when they looked at a number of teams in writing their book “PeopleWare” is they asked, “Who do you want to be on your team, and why did you want that person to be on your team?” In almost every organization there was at least one person that was on every single successful project and that, when asked, they were deemed one of the most valuable people on each one of those projects.
Derek: But when they asked the people why, nobody could put their finger on it. I think what starts to happen is if you have a review that is simply a skill set, are you good binary at this task, yes or no?
Sometimes, you rule out the best people because the best people that make teams successful, are key people that make teams successful, are the people that enable other people to do their best work. I think that, yes, you do need to take things at an individual level and review somebody individually.
But, I think, we need to get to the point where we’re evaluating people individually on how they adhere to the team’s values and how they adhere to the team’s principles, not to specific skills or tasks. Meaning that most people that want somebody off the team do not want somebody off the team because they think they do a bad job. They want them off the team because they think they are a bad fit for the team.
Jade: I agree.
Roy: Because, when they are fit for the team, they’ll figure out ways to help that person become confident in the area that they need to be.
Jade: I totally agree. I guess I was going under the assumption that you were measuring and judging the individual on the proper things. I think that’s a good point to point that out specifically.
Clayton: Roy is someone who has been helping another team kind of adopt some of these Agile principles and things. What are some of the things that you’ve experienced in terms of the cost of changing, people that have been affected and what’s kind of happening there?
Roy: What I’ve been kind of seeing is more of the social costs of change or the emotional costs of change is that when you’re restructuring and trying to adopt the Agile process, there are times when you’re going to have to have conversations in which two people are going to go into the conversation and either one person is going to have to change their way of doing things completely or one of the two has to leave.
I think that’s a very difficult conversation to go into and that’s a significant cost of change that I don’t think a lot of people necessarily think about when they are going in to doing an adoption like this. They are going in to it thinking it’s going to be great, but then, there’s going to be heads bumping and people are going to have to make a decision on if they want to adapt or leave the company or whatever they want to do.
Mike: We actually do find that there is, and I’m not sure where this statistic came from, between 15 and 25 percent turnover when you start to actually implement any kind of change like Scrum.
Clayton: Is that because Scrum doesn’t leave a lot of room to avoid the fierce conversations that need to be had?
Mike: Yeah, you’ve got to have those difficult conversations and some people do not want to do that. It is a significant cost of change.
Clayton: That’s not even on an individual employee level or the developer level, there are managers that don’t want to deal with that either or that get totally freaked out by having to deal with this conflict.
Clayton: That’s something I hear, “Oh, we’re fighting all the time. It’s horrible. We used to get along. Why is all this happening?” It’s really that you weren’t really getting along, but everything was so shallow and surface level, that there was really no room for conflict. Now that you’re digging in and really trying to work together and get better, that’s where you’re starting to uncover a lot of this conflict.
Mike: Yeah, like when they’re going through that whole Bruce Tuckman model of forming, storming, norming and performing.
Mike: A lot of times, organizations are stuck in storming and it’s just normal.
Jade: They shy away from the storming and they don’t just push through to get to the norming part of it.
Clayton: I think a lot of times, they don’t even realize that they are in the storming.
Clayton: One thing, Jade, that you’ve mentioned before is that, you kind of gave an anecdote about, the company wanted to adopt some Agile principle, but they couldn’t get their risk management software to work with the new way of doing things. I would imagine that there are a lot of companies out there, big and small, that have invested a significant amount of time and money and resources into getting some third party tools or processes or anything like that.
How do we deal with, when we say, “Well, we’re going to get this new process. This new Agile process,” and that makes, maybe it invalidates or makes this other thing you’ve already spent a bunch of time and money on not effective or useless?
Is that something that you think would be a total barrier? A no go?
Jade: I think that’s pretty scary for a lot of people, not even just in the software and the tools, but there might be entire departments that need to completely change. So if you have the QA department and the PMO and risk assessment and all of these people that are in these gigantic silos and now, you’re telling me that they all need to be cross‑functional and I need to completely change the structure of our organization to deal with that. That’s a terrifying thing to deal with. Especially, to not know what the outcome of that will be.
Mike: On of the ways to really help get around this is to make sure you have some executive fire cover that is able to say, “OK, you know what, it’s a sunk cost. Let’s just do it and move on.” Because, you can’t really have that at like, especially the large companies, the director levels that are really competing against each other versus the vice presidents who have more of the strategic look. You need somebody high enough to go and say, “Let’s do it,” and make the call.
Clayton: In your experience, Mike, how often are you seeing that happen where somebody is bold enough to really give the teams enough runway and enough cover to at least attempt a successful change or implementation of Agile?
Mike: Very few. A lot of is really that at the highest level, they don’t really buy into it. So that could be a whole other conversation.
Clayton: That’s a good segue into the next podcast. I say thanks to everyone. I’m going to stop now.
Jade: Thank you.
Mike: Thank you.
Clayton: Thank you.
- Is it necessary (to have a single product owner)
- Problems with multiple product owners
- Who determines done
- Proxy product owners
- Accountability issues
- Delegation of authority
- Dealing with multiple products and a single development team
Derek Neighbors: Welcome to another episode of “The Scrumcast.” I’m Derek Neighbors.
Roy van de Water: I’m Roy van de Water.
Drew LeSueur: I’m Drew LeSueur.
Clayton Lengel‑Zigich: And I’m Clayton Lengel‑Zigich.
Derek: What you are talking about today guys?
Roy: We are talking about the benefit and also the necessity of having a single product owner.
Derek: Is a single product owner really necessary?
Roy: I supposed it isn’t really necessary, but I certainly think it helps things a ton. A lot of times when you have multiple product owners on the scene, you get a lot of conflict of interest. You have one guy, who thinks his entire priority queue is the most important thing in the world and another guy, who thinks his priority queue is most important thing in the world.
And you have to have somebody that ends up reconciling those two queues. Often times that ends up falling to the developer which really shouldn’t be his responsibility.
Derek: So is the number one reason that multiple product owners is a problem is one of priority? Meaning that four product owners, all four think their thing is the most important thing. They all have a number one thing in determining which one of the four number ones is really number one is the problem? Or are there other problems with having multiple product owners?
Roy: I think there’s a lot of other problems with it. I find that in my recent experience this has been the specific symptom that’s hurt me the most, but another huge issue to it is you don’t know who to go to for a particular issue. If something comes up, who do you talk to? Do you start tagging every story with one product owner or the other, and who decides when a certain piece of functionality is done?
Derek: Have you guys had any instance where a proxy product owner has been deemed for sub‑product owners? So maybe there are four product owners, and everybody agrees that that’s unilaterally a bad idea. So neutral product owners put in place to prioritize or speak on the behalf of the four other product owners. Have you seen that? If so, have you seen it work or what are some of the problems with it?
Drew: I think one of the problems with that is if you’re not talking to the source, then you don’t really get the same power or authority that the source will give you. So if I’m talking to a proxy, he might not understand it the same way that the actual real product owner understands it.
So I’ve seen that, and I’ve seen it where when we are talking to the source, everything’s a whole lot clearer. You feel like you can really have the communication that’s needed to figure out what you need to do.
Clayton: When you think of the roles that are required for the product owner on the scrum team, when there’s a proxy product owner or more than one product owner, it gets really easy to skirt the responsibility that they have. So, maybe, the development team needs the product owner to do some interfacing with some stakeholders and prioritize the backlog, or do some backlog grooming, or whatever.
But when there’s a proxy, it’s easy for them to say, “Well, I would love to do that for you, but I need to go talk to these three people and I can’t really do it.” Or if you have more than one product owner, then it’s like, “Well, that can be Joe’s job, I have more important things to do.” So, the responsibilities of the product owner get wishy‑washy, and some of that gets avoided.
Roy: I think, too, one to the defined responsibilities, for both product owners and scrum masters is to protect the development team from the stakeholders and all the people outside of the scrum team. I think that when you start making the stakeholders the product owners themselves, technically they’re not outside the scrum team. Now you’re having all of this outside interaction coming in and interfering with the development team as well.
Derek: Do you think that one of the problems, I’m trying to think, what are some of the reasons why we end up with multiple product owners? Is it because stakeholders are unwilling to let somebody represent them?
Let’s start with that one. In the case where maybe there’s three stakeholders to a product, and none of the three are willing to give up control of determining priority or making sure the direction of the product is going their way. What are some ways that you could effectively potentially use either a proxy or get one of the three to speak on behalf of the others?
Clayton: I think if you have a strong product owner, even if they are a proxy, they can still treat the other people as stakeholders, do all the interfacing and prioritization that they need to do, and helping the team define done. They can still do all those things.
In my experience I’ve seen, maybe the flipside of what you’re asking, Derek, it’s not so much that the three people don’t want to give up the responsibility. It’s more often than not, where the proxy person doesn’t really want to take all that responsibility on, because they don’t want to stick their neck out and be the single wringable neck, so to speak.
They don’t want to take that responsibility and then be accountable to those three people. They would rather say, “Oh, sure. I’ll be the product owner.” And then, when push comes to shove they can say, “Well, I’d love to help you out, but I need to go talk to these guys.” And I don’t think they want to be accountable to the organization.
Derek: So could we say a certain smell when you’re using a proxy to try to eliminate multiple product owners is when they constantly defer back to, “Well, I’ve got to go talk to some group of stakeholders or even a single stakeholder. I don’t feel that I’ve got the authority to make that decision”?
Drew: Right, I think that’s definitely a smell when you recognize that the product owner needs to have equal parts authority, time, and knowledge about your project. If he’s got to refer to a bunch of other people, then he’s severely lacking in the authority, which doesn’t place him in an ideal position to be a product owner.
Clayton: Right. Especially if it’s over every single story. Having to do that, that’s a definite smell.
Derek: Now, let me maybe posit a slightly different scenario that I’ve seen in a number of companies, and maybe we can talk about what are some ways to handle this.
Maybe I’ve got a development team of five or six developers, and our company has eight different products. They’re all fairly mature products. So the six developers are responsible for all eight products. But each one of those products has a different product manager.
It doesn’t make a whole lot of sense to…Each product manager is willing to take responsibility and be a product owner for their product. But how would you go about dealing with creating a unified backlog so to speak between eight products where you didn’t have to interface with all eight product owners? What are some ways you could go around that?
Clayton: I think, in general, when you have a bunch of product owners and you want to delegate the responsibility of the product owner and bring it down into one person, it’s generally easier to go up because responsibilities tend to converge when you go up, and also authority tends to be higher when you go up and sometimes knowledge as well.
In that example, we have a bunch of different project managers. I would say, “Who’s the person in charge of all of them?” Is there a C level officer who can be the product owner? Although, a lot of times an issue you run into in that situation is that that person doesn’t have the time to prioritize the backlog and do the other responsibilities.
Derek: Say that there was a product manager that was over all eight products. Then there was a product owner defined for each one of the particular products or a project manager or whatever you want to call it.
If that product manager was willing to say, “I’ll prioritize the queue for you. I’ll make sure that I’ll be responsible for the queue.” They’re probably still not the best person to probably be in the planning meeting because they don’t know all the specifics about the stories.
I guess what I’m saying is how would you go about a situation where you had multiple subject matter experts or product owners? Even if you didn’t have an issue of prioritization but you had one of specialization, what would be some potential recommendations that you could do to combat that?
Roy: To me, the prioritization in that scenario sounds like the biggest problem, but if we are saying that the prioritization thing is taken care of by the overall, overarching project…
- Precision vs. accuracy
- Hard conversations
- How to get better at estimates
- Hours vs points
- Story estimates vs estimated velocity
Derek Neighbors: Welcome to another episode of the ScrumCast. I am Derek Neighbors.
Clayton Lengel‑Zigich: I am Clayton Lengel‑Zigich.
Roy van de Water: I am Roy van de Water.
Jade Meskill: I am Jade Meskill. Today I wanted to talk about estimates.
Derek: How long do you think it’ll take to talk about estimates?
Jade: It depends.
Clayton: Have you ever done this before?
Jade: I thought the answer was, “It depends” [laughs] . Seriously, we want to talk about what are the challenges with estimates for your teams, for yourself? What are some of the things that we struggle with? To kick it off, let’s start with padding estimates. How do we feel about that?
Derek: Pad them, definitely. All the time. As much as you can. As much as they’ll let you.
Derek: Unless I’m paying for the work, then padding’s not allowed.
Clayton: Padding is something that is ultimately unnecessary inside of an agile framework. For scrum, for instance, if I say I’m going to do this many points this week. I commit to something for this iteration, and then my estimates are wrong, and I get half of it done or whatever. Assuming that everything else went right, then, it’s just instant feedback where I can say, “OK. Now, I know I can only commit to…” It helps you modify things. Ultimately, it’s a moot point.
Jade: Why do you think it’s so prevalent that there’s certified scrum trainers out there teaching people to pad their estimates? Why do you think that they feel that’s necessary?
Derek: It’s because they don’t understand the point of an estimate. What I mean by that is still today, even in a lot of scrum implementations I see we’re really talking about wanting to be precise, instead of wanting to be accurate. There’s this big, “Our estimates have to be perfect, because we’re telling somebody that this is the estimate. When we tell them that this is the estimate, then they’re going to go allocate a certain amount of budget.”
When we tell them what that budget is and what that time is, they also expect to get every single feature that we told them as part of that estimate. As Clayton says ‑‑ when we go in and we get an iteration or two, we realize that maybe our velocity is not 20 it’s 15, we have a choice to make. We either have to spend more money, or we have to reduce the scope, or negotiate what it means to be done on the scope that we’ve already defined.
People do not like to have those conversations, because it requires being personable. It requires all parties coming to the table and having a discussion between people. I think as practitioners we like to hide behind tools, we like to hide behind code. We like to hide behind every technology known to man, short of having real conversation.
I think that product owners and business owners have a very similar problem. Because they don’t understand technology, they say, “You told me X, therefore X had to be true, just make it work. Work twice as hard, or work twice as fast, or do whatever and make those estimates right.”
I think it’s because we do a really poor job at the beginning of a project, or at the beginning of working with somebody, defining what it really means to do an estimate using Agile methodologies. What we were trying to is be accurate and be able to do some moderate planning, but we are going to have to inspect and adapt not only the way we’re doing things, but the length and the cost that it’s going to do those things as well.
Jade: Let’s say that I am a product owner and I have a project that I would like you guys to do, and I need to know how much this is going to cost me? How long it is going to take? Here is my requirements, or my stories, or whatever it is that I have gathered for you. How are you guys going to give me any assurance at all that I can plan for this?
Derek: My two questions to you would be, how quickly do you need the estimate? How precise do you need the estimate to be?
Jade: What’s the risk in getting an inaccurate estimate?
Derek: The more precise you want to be, the longer and more expensive it is going to be, to get you an estimate. If you changed your mind on anything, or we discover anything new, we’re going to have to not do those things, or we’re going to have to go out and do all new estimates.
Jade: I’ve got a $30,000 budget, and I needed it done in four weeks. Can Scrum do that?
Derek: I think Scrum can give you a moderate picture of what the team believes they can do in four weeks on your particular budget, or I guess they could give you one or two things. They can either tell you four weeks what you will get for that budget, or they would tell you with your budget, how many features you can get done.
One of the two and I think that you can negotiate a fair amount of that feature set, and then have somewhat a good idea in every week. You will be able to potentially get feedback on how accurate those estimates were.
Jade: I want it all.
Derek: You should probably go to waterfall methodology then.
Jade: Estimation is one of the most difficult parts, I believe of being a good scrum team, is being good estimators. What are some tips and tricks that we can offer people to help make their estimates more accurate, help deal with these questions that come up from products owners?
Clayton: I’d say that as far as becoming, say better at estimation. I would say really take the inspect and adapt concept, and apply that to your estimations too. I think a lot of times people do the padding thing, because they just pad everything. They don’t ever go back, and they don’t ever try and see, “Was I write?” Or “How far off was I?” Or anything like that.
It’s always just, “I’m just going to take, whatever I think it’s going to take, and I’m going to add 50 percent.” That’s their general rule. They don’t ever go back. I did that here with this team, and went into a sprints worth of tasks from every single project I think, and they were 300 or so.
Maybe it was two weeks of task, but we were off by an average of like half an hour I think. We were so close to our estimates, but at the time, everyone was saying that we are so bad at estimating, we did everything wrong. In reality, we were actually pretty close. We were way better than I think anyone would have thought.
I would say that if we can go back, and come up with some way to look back at your estimates and see either you are right, you went over or you went under, and why. Apply that next time.
Derek: I think one of the things that I see most teams do when they estimate, that really hurts them, is they are still way too tied to thinking in terms of hours. I’m trying to map what does a three point story look like in terms of hours? What does a five point story look like in terms of hours? Instead of thinking about them in terms of difficulty.
What I always like to say, is when somebody says that they are a bad estimator, usually what they mean is someone, either myself or somebody on the team, or somehow we derived a velocity that we thought was acceptable. We didn’t hit that velocity, and therefore our estimates were wrong.
What I like to say is, “Well, perhaps your velocity estimate was wrong, but were your story estimates really wrong?” If I say something is an eight, and something else is a three, and something else is a one. If that three is three times harder than the one, and the eight is eight times harder than the one or a little over almost three times harder as a three, I would argue that your estimates were spot on. Even if your velocity was off by half, or double.
That’s really where I see developers really getting hung up. Is that they get way too hang up on the velocity side, instead of how they are seeing stories and relative size. I think if they can nail relative size, you start to learn how to do velocity as you start to work as a team longer, and more together. You start to see what’s common.
I think we get way too hang up on that, that’s because we do fixed bid price kind of work, even we do internal work usually as scrum teams. We put a dollar figure on something that relies on the velocity never changing. I think that’s bad.
Roy: I think something we run into a lot as well is that, we had this mentality a lot of times going into doing estimates, where we’ve done a lot of reals application, specifically for us in the past. We start off going in to estimates with this notion that a cred operation is automatically a three. Then everything is based off of that. The thing is not every single project that you come into is exactly the same.
The skills are going to move all around, because what’s important is that, each story within that set of estimates is relative to other stories within that estimate. Not relative to any story outside of that.
Clayton: Yeah, I think the first time that became really abundantly clear to me is, I was working with an embedded engineer, and every single estimate was under a three. There were some things and I was like, “Dude, there’s no way. That’s going to take at least a week worth of work to do that, and you put a three on it.”
Then we went through an exercise to estimate the initial velocity, and the initial velocity for a week was five. It’s like, “OK.” You get used to working with a team who the numbers are probably more in the threes and the fives, or the eights, but the velocities are 25 to 30. Velocity really has a big impact to where your sizing story is as well.
Jade: What advice do we have for trainers who are out there telling people to pad their estimates and use some multiplication factors? Things like that?
Roy: I think, ultimately, as a trainer, you’re hurting the team. If you’re doing something like that where they are padding their estimates, then they’re going to think of their estimates in terms of that multiplication factor.
If I estimate this as a two, and I multiply that times whatever figure, then when I go back and reflect on my estimates, I’m going to think about it in terms of the multiplied amount. I’ll be comparing the accuracy of my estimates against the wrong actual estimate.
Clayton: Yeah. I think it’s to the detriment of the people that are doing the estimations, and also to the people that are paying for the work. What I found is, when someone goes under on a task, let’s say that they thought it was going to take an hour and it only takes 15 minutes. When that happens, there’s never a revelation of, “Hey, I got this done so much earlier than I thought.” But when they go over, it’s always a huge justification of, “Oh, I told you that. This is why our estimates are always wrong, blah, blah, blah.”
It’s always like a one‑way street, and they don’t ever cancel each other out. When in reality, I think that’s what happens. It’s to the detriment of the people that are doing the estimations, because they don’t ever find out that they were right some of the time, and even though they were wrong some of the time, it was OK.
Jade: Yeah. I think that’s really good. I think that wraps up the podcast for this week. Thank you and we will talk to you again later.