Soft Skills Engineering - Episode 247: Estimates and hotdesking

Episode Date: February 8, 2021

In this episode, Dave and Jamison answer these questions: Questions What is your opinion about estimates. Is it a good practice? Are they helpful or just a guess? Should we estimate in story points or hours? How can we improve our estimation skills to be more accurate? I really don’t like estimating. I don’t think it is a good practice because we almost never get it right. The teams that I have worked also almost always made wrong estimates, causing us to miss our sprints commitments frequently. Is it a problem with this practice, or there is a way to improve it? I heard about the Kanban method, that don’t use estimations, but metrics, to give predictability. What do you think? Hello Soft Skills Audio :) Love the show and the great advice, I look forward to the show every week. I just joined a company that embraces hotdesking and I’m having trouble feeling like I am part of the team. All the engineers report into the head of engineering but we work on different projects. I work with one other engineer who works remotely from another state, and take direction from the product owner who works from another. The culture of hotdesking across five floors of a multistory building means each morning I end up circling around hunting for a place to sit. Because anyone can sit anywhere, I could be sitting next to someone new from sales, marketing, finance, or engineering everyday. Everyone always looks hard at work with headphones on and our organization chart doesn’t feature profile photos. I’ve tried introducing myself to the people I find myself next to but it’s just small talk and I never see them again as everyone shuffles around. I’m sick of sitting alone at lunch and missing out on “watercooler” conversations. How do I make friends and figure out how I fit in with an office environment like this?

it takes more than sending an email saying i wish to retract my previous message to be a great software engineer this is episode 247 of the soft skills engineering podcast i'm your host jameson dance i'm your host dave smith soft skills engineering is a weekly advice show where we answer your non-technical questions about the technical field of software development i guess this is like a big company only problem i've never seen this at a startup where the person the one person in the office with you sends you an email saying i wish to retract my previous message they just turn around tap you on the shoulder and say can i hold your keyboard for a minute press the delete key yeah i feel like this this violates the strisand effect or it

doesn't violate it it illustrates it because every time i get one of these i just frantically search my email to find out what was the message that they want to retract yeah me too that's exactly right if they sent another message that was like hey did you get a chance to check on the q4 tps reports it would instantly go to my garbage can but they made it interesting dave do you want to thank our patrons i do thank you so much to those that are supporting on patreon we have a one-time shout out for eve ben ezra and we have weekly shout outs for nick cantire the agile ventures Charity, Chris Hogan, Brayden Cain, Stephen Armand-Lee, Philip John Basile, John Grant,

Dennis Bogdanoff, Travis Sanders, Nick Hathaway, Oladabo Fadi, Kiaran Sveinsen, Ragnar Hardison, Christian Polanko, Roman Denisov, Fizzbuzz, Influencer, Adrian Bording, and testingisdocumenting.org. If you'd like to join this group and join our Slack community, you can go to

softskills.audio and click support us on Patreon. Any dollar amount greater than zero will get you access to our Slack community, and certain levels will get you access to hearing your name or whatever word you type into our text box said in one of our voices every week we promise i oh no you you have a follow-up that's right we do have a we have a nice we got a nice comment from someone with a great idea that i thought i'd share this comes from a listener named art who has an idea of what to do for the question asker from last week's episode which is

episode 246 who discovered that one of their co-workers was severely underpaid art says the manager can lobby for another senior developer role to position to be opened because of increasing number of junior developers and work planned then open the position and offer it to the underpaid junior engineer promote them into a senior engineer and then give them a raise hr should be happy about the short interview process and reduced onboarding costs and the underpaid employee can show that not only did he get a raise but also got promoted everyone wins it's foolproof it's a good idea i'm actually surprised i didn't think of it you closed the position to hire a junior developer that you opened up once this person switched after not being able to find

anyone that will accept such a low rate that's right i can't backfill at this at this salary sorry which frees up even more budget for the raise yep cool i'm gonna read our first question i'm not even going to wait this is a question from a listener named bruno who asks what is your opinion about estimates is it a good practice are they helpful or just a guess should we estimate in story points or hours how can we improve our estimation skills to be more accurate i really don't like estimating i don't think it is a good practice because we almost never get it right the teams that i worked with also almost always made wrong estimates causing us to miss our sprint commitments frequently is it a problem with this practice or is there a way to improve it

i have heard about the kanban method which doesn't use estimation but metrics to give predictability what do you think i love how this question answered itself bruno says should we do this i don't think we should yeah they're almost never accurate we miss our sprint commitments sprint commitments more frequently this isn't a joke at all but i read a thing saying that some official Agile guide moved from commitments to, was it forecasts? Because they wanted to de-emphasize this idea that at the beginning of the sprint, you say, I solemnly swear I will get this done. And if I do not, I will accept my punishment of public shame. And I found that that doesn't motivate me to do better work in general. The threat of death doesn't motivate

you? No. I think maybe you've never had a real threat of death, Jameson. Well, it wasn't death. they put us in stocks and threw expired coconut waters at us this is at a startup not threatening enough i guess yep that's funny huh i estimate that my estimates are right 50 of the time that's your estimation yeah what is the chance that that estimate i just made is correct uh that's like since you're chaining estimates to each other it's like when you have like when you add more parts to a system that each have a mean time to failure the mean time to failure of the system is you find by multiplying all the mean time to failures with each other and it just plummets saying it's less than 50 oh yeah definitely

shoot yeah do you do you estimate as part of your well i guess there's a difference here this sounds like specifically scrummy estimation where you have regular sprints and at the beginning of the sprint you estimate this is how long these tasks will take so this is roughly how much we can do in this short time period it seems focused on that not just like hey when will this project be done yeah i mean the the promise of scrum and if you read the scrum book and read all the website stuff from like 10 15 years ago the promise was why would i ever do that i read the scrum book When I can just, when I can just spit nonsense about something I've never read. You've read it?

I read, yeah, the book titled Scrum by Sutherland. Okay. To save me time, summarize it in two words, please. Scrum. The two word summary is scrum good. All right. Thanks for all that time you saved me. Scrum really is good.

but the great promise was that as a team you could put story points on every task and then you could monitor a team's output in terms of those points by counting up all the stories that were delivered in a certain time period and you could establish a velocity and then going forward anytime a team put points on things you knew exactly when they were going to be done if you stacked them up in a certain order and that sounds pretty good how often does it go that way uh zero percent of the time i would say yeah i've literally never seen it work i think it's helpful to bite off chunks of work and say this is roughly how much we can bite off but i've never seen the full intent process of we've just nailed our estimation process we got

our velocity down and by the way we've broken down this upcoming project into tasks that all have estimates on them and the tasks are right and there's nothing missing and nothing's going to change. Right. That last part is very important. Yeah. I've found it helpful to estimate vaguely how much we can do in a sprint, but by the time you know what is involved in a project, that's usually when it's done. That's right. Building is scoping, I think is the way I put that. Yeah. Have you heard that phrase, I have a map of the world, actual size? that's kind of like what it is oh my gosh i love that go off and get me an estimate and you say all right it will take i'll tell you when i have the estimate and then you hand the product back

the visual the visual from that quote just totally stimulated my brain i love that oh i had a professor who used to say it all the time it's probably from something i have a map of the world actual size oh i love the imagery that sometimes sometimes language can really move me and that That was one of them. Thank you, Jameson. Thank you for sharing that. You're welcome. Thank Dr. Goodrich.

I'll have to remember who it was. We'll put it in the show notes. Thanks, one of my professors. Yep. So I have done estimation every way you can imagine over the last 10 years. I mean, just every which way. I've done, what's it called? The poker, story point poker.

Is that what they call it? Planning poker. Planning poker. That's what it is. Planning poker, yeah. I've done planning poker. I've done digital planning poker, analog planning poker. i've done put story points on everything i've done break it all down did you do

texas hold'em planning poker or was it what's the other one five card draw or something five card stud no poker wizard planning poker stud no i did everyone hold up their card and put it on your forehead poker ah with the story points you think it is okay i've managed teams where i said look i want you to break this down and your your estimate needs to come to me with a list of all the source files you'll need to touch to do this project this task you know like that level of detail and then i've also done the opposite where i say don't estimate anything just go as fast as you can because we're going to cut out all the estimation time and get our get our eight hours a week back you know and see if we go faster oh i've done no estimates i've done no points i've

done some points i've done let's just work to a deadline where you say i'm going to give you a deadline you get as much as you can here's the problem you're trying to tackle tackle it as much as it can be tackled and shipped by this date and just everything in between and there's no and jameson you're just just bragging about all the different stuff you've done the you know here's the end here's the end you want to know what works best what of all those things the one thing that works the best is changing the system but that wasn't one of the things it wasn't it was in everything which means i'm telling you i've seen this and i believe there may have even been studies that show this that introducing a little bit of change to processes doled out at the

appropriate time increases productivity huh i've never heard that interesting second hand heard about a study from the early 1900s studying manufacturing facilities where the these motion efficiency people would come in and adjust the assembly line process a little bit and tell people okay do this with your hands a little bit differently and productivity would go up and And then they would observe that for a month, measure it, capture the increase. Then they'd go and say, all right, now we're going to make this tweak. And then productivity would go up. And then they'd measure that for a month, capture it, and they'd make another tweak.

And they even saw that if they went back to the original process, that productivity would go up again. And they concluded that the act of introducing some change increases productivity. so i have my own data of half remembered secondhand studies which is that deliberate practice increases performance on a logarithmic scale okay which means there are diminishing returns basically so you get much better faster at the beginning and then eventually it kind of levels off so i wonder how much of that was just practice and how much of it was the process getting better or the fact that they've been doing the job longer yeah i mean they had been exactly they'd been doing the job longer each time yeah exactly that because you

can't erase that variable right and the same thing goes with software not yet yes it's it's like you find your stuff in the last place you looked like whichever the last process you tried was the best because that's when your team was the most experienced performing the best right yeah like they've you now have a team that's been building widgets for six months instead of four months oh but i'm sure it was the process to change not the team's level of skill yeah but seriously like in software that that's huge right like let's say you come onto a code base and it's your first time working in it and then you make note of your performance and then you know six months later you've been now still working in the same code base you're way more productive

yeah yeah i mean the the desire for estimates is never going to go away because it turns out it's helpful to know when things are going to happen yeah so i've heard there's this no estimates crowd that tries to pitch the idea that we shouldn't ever have any estimates we should just work on stuff and I think that would make developers really happy and everybody else in the company very anxious and confused because if you have like a board meeting you go up and say well I don't know we don't have estimates so but I need 50 million dollars yeah our next quarterly plans are whatever we get done in the next quarter yeah it sounds I laugh at that but I think when I was a younger developer I would have been like yeah that's right yeah you just let me work tie me

down yeah this is art you can't rush art no i am a professional artist yeah i'm a craftsman and if turns out if you are a professional artist that means you can crank out art that's right in fact you've got you have you have in fact you have cranked out tons of art probably yeah it's fascinating i don't think i ever really appreciated it why estimates and schedules were so necessary and i used to really push for that like no it'll be done when it's done and the quality is good enough you know and that's yeah that used to be we would make a hero out of whoever pushed that pushed back on that yes the the loudest we nominate that person to represent us yes you you go talk to management yeah exactly you tell them to leave us alone

and you know what's funny is for years i would listen to i would hear companies like amazon and i would i would hold them up as an example from the outside where i would say amazon never gives dates they never promise that a product's going to be shipped at a certain time they just launch the product when it's ready and so i would go to my management and say we're going to be like amazon we're not going to tell you the date we're going to ship it when it's ready and then i went and worked for amazon and i realized that internally it's nothing but dates and commitments tons i mean it's non-stop dates they they hire armies of people whose only job is to track dates and deliverables so you go back and apologize to your previous management i know i'm so sorry

did they say we'll be like amazon when our revenue is in the billions of dollars exactly exactly that's what they should have said yeah but i was just so intense they were dumbfounded speechless so nihilism that's the strategy i really when it comes right now okay let me tell a couple let me tell one anecdote from my own life the only time i've ever seen accurate estimates is when i was on a one person project and that one person was me and I had a very concrete list of objectives to accomplish in a pretty short amount of time, like eight to 10 weeks. And I, I estimated how long I thought these things would take upfront. And I said, I'm going to need eight to 10. I'm going to need eight weeks. Let's just

say to finish it. And the tasks were so fine grained and so specific that I could, I could estimate down to the half day. I could say that's going to take me one and a half days to finish. And I got to the point where I was right most of the time. But what's really important is what's missing from this project. First of all, other engineers that need to be communicated with. Second of all, QA. There was no QA to sign off. I signed off whenever I thought the quality was good.

You know, and so that was another variable. There was no customer in the mix at that point. And there was no one representing the customer either. It was just me interpreting the requirements and then going off in a cave and implementing them for eight weeks. There was no product manager to check up on status and ask me questions and challenge me. You know, there was no manager. It was literally this case where there was extra research money to be burned in the calendar year. And so my job was just to burn that on schedule, but also ship a product at the end, which I did.

And it was fine. And then it got shelved and no one ever touched it. So it's like in that extremely rare scenario, you know, it's like the it's like the perfectly sphere shaped cow in a vacuum. then you can produce accurate software estimates i think so that just changes the problem into how do you turn every project into the perfectly spherical cow that's right yep all right have we answered the question not even close i don't know i mean internal question the fact is you do need to estimate and it is a skill and there are people that are very bad at it, which is most of us, I think. And I think it is wrong

for software engineers to push back on this concept of dates and commitments. I think forecasting is a great way to say it, but at the end of the day, you're being paid by someone who wants you to build something and you need to be able to deliver what they've paid for. And yeah, our industry is hard to estimate. It's not like remodeling a house. It's a little like remodeling a house but not very much where yeah there's in a house there can be unexpected things but there's kind of an upper bound right it's like well at some point you run out of unexpected things and you could rebuild the whole house and you know that's the upper bound but you know in software it's like everything's unknown it feels like a lot of times i lean towards that idea you said

earlier of you pick deadlines and then you you cut scope to hit them but that doesn't work for every project there are some projects that have uncuttable scope and if you cut the scope then you cut the whole project so i don't know what the universal answer is like if you i don't know if you're if you're deploying a new database you can't just say actually we didn't deploy it we cut the scope so we hit our deadline or we cut the scope to no database required yeah yeah we cut the scope to read only yeah some minimum requirement that you can't cut There's almost always a chance to cut scope. But I know, Jameson, you've worked in an industry where you had very rigid deadlines in the ed tech industry, right?

And the deadline was driven by matriculation dates for a dozen universities. And it's like they're not going to push back the matriculation dates. You have to ship it and it has to be ready on time. Actually, I've worked in two industries now because now I work in retail and e-commerce. And there are drop-dead doomsday deadlines of, yeah, holidays come whether your software is done or not. yeah and and so what do you do we got scope yeah i'm saying you can't you can't have it both ways they can't both be rigid yeah yeah i mean we we've walked away from things that felt like

it would be hard to walk away from but the other alternative is you you put in a ton of effort to try to sprint faster for some time period and that has a whole different set of trade-offs yeah but yeah what have i learned about this i think you learned to cut scope always estimates are always better in january not better they're always more optimistic in january than in september as you're closer to the holidays yeah september is when you realize like oh this is what will actually get done by the holidays yeah yeah yeah so so temporal proximity brings clarity on your uh on your estimates um i mean that's sort of the that's sort of the sprint model right is

you you estimate in smaller chunks and hopefully that makes them more accurate overall but you still have to break it down into those small chunks at some point that's right yeah iteration is a is maybe a sneaky workaround for this if you can yeah i love that i think there's a scene uh i think it's from it's a star wars parody there's a cartoon of a star wars parody where at the end of episode four a new hope where they're all planning to to go blow up the death star and all the pilots are sitting around and the commander reveals the target and it's this like tiny porthole vent hole on the death star that they have to shoot these missiles into one of the pilots stands up and says that's too small of a target to hit we can't hit that and then of

course luke skywalker stands up and says oh i used to shoot womp rats back on my home planet that size all the time you know and then in this parody version the guy after the meeting pulls luke aside and he's like what are you doing over there man you're making me look really bad out there i just thought it was so funny like you're sandbagging me and uh looks like oh sorry man it was funny because i thought it's like it's kind of like software estimates like you have the one engineer who's like oh no it's going to take a lot longer than that and the other estimate the other engineer on the team saying oh no i i did a prototype like that over the weekend and i could definitely do that in a couple of hours yeah that's true you can always get somebody to say

I think we can go faster. And then it turns out, usually management will agree with that person. That's right. Whoever says the lowest number is what they take away. That's right. That's right. It goes to the lowest bidder. I don't care the cost. Yeah. We have the inverse. We do the highest bidder. That's right. That's right. So the other thing I'll say about this topic is that as an engineering leader, I think one of the most valuable skills you can develop is all about judgment of when to give a team a deadline and what to require to be done by that deadline and understanding when

the team is raising concerns and which concerns are valid and by valid i mean a very specific definition of valid which is with threaten the deadline to deliver a product that is unacceptable to the customer um or which ones are concerns that don't threaten the deadline you know it's hard it's hard to know like when do we actually back off on the deadline or back off on the scope yeah i just think it takes practice and i wish i wish i could write down what actually goes on inside the neural network in my head when i'm seeing a situation and deciding whether to you know what to do with the date yeah but i can't it's uninspectable like neural networks that's right it's a gray box of juicy fluids should we read our next question yeah i think

so i will read this this comes from an anonymous listener who says hello soft skills audio love the show and the great advice. I look forward to the show every week. Thank you very much. They go on to say, I just joined a company that embraces hot desking, and I'm having trouble feeling like I am part of the team. All the engineers report into the head of engineering, but we work on different projects. I work with one other engineer who works remotely from another state, and I take direction from the product manager, product owner who works from another state. The culture of hot desking across five floors of a multi-story building means that each morning, I end up circling around hunting for a place to sit because anyone can sit anywhere.

I could be sitting next to someone new from sales, someone from marketing, finance, or engineering every day. Everyone always looks hard at work with headphones on and our org chart doesn't feature profile photos. I've tried introducing myself to the people I find myself next to, but it's just small talk and I never see them again as everyone shuffles around. I'm sick of sitting alone at lunch and missing out on water cooler conversations. How do I make friends and figure out how I fit in with an office environment like this? so we got to define hot desking this sounds like from the before times anyways hot desking are you googling the definition yeah can't find it

question answered doesn't mean anything oh i spelled it wrong found it turns out hot desking is not a thing what is it hot desking is an office organization system which involves multiple workers using a single physical workstation or surface during different time periods the desk in the name refers to an office desk being shared by multiple office workers on different shifts as opposed to each staff member having their own personal desk a primary motivation for hot desking is just guess jameson saving money that's right cost reduction through space savings up to 30 in some cases

but you better darn well believe that most people will pitch this as a productivity win yeah so i'm just thinking about all the benefits you get from hot desking one is that if you are a messy eater you now get to crop dust cheeto remnants across the whole office instead of just to yours every day you come to a clean desk right oh that's beautiful you never have to live in your own filth yeah the tragedy of the commons is only a tragedy for the people that don't let their sheep phrase there the tragedy of the commons is only a party of the commons for non-psychopaths yeah the party of the commons is that what you said yeah the joy of the commons i don't know i have so many thoughts about this they talk about small talk how they have a hard time

getting past those sort of initial conversations so there was this article in the new york times about 36 questions to fall in love and i think your problem is you're asking too small talk of questions you need to ask some deeper questions starting with given the choice of anywhere in the world where would you want to be a dinner guest okay in the middle we have what do you value most in friendship at the end we have share a personal problem and ask your partner's advice on how they might handle it oh perfect and then at the very end you stare in silence into each other's eyes for five minutes so i think you should start with that just yeah just go through those the weather heck no no make three we statements each for instance we both in this

room are feeling there you go we're both what like make three we statements each for instance we are both in this room feeling something something so got it like yeah okay how was the sports game the other week nope complete this sentence i wish i had someone with whom i could share deep awkward hot desking yeah that's what if you were to die this evening with no opportunity to communicate with anyone what would you regret not having told someone just walk up introduce yourself hi i'm dave if you were to die this evening and you could you can actually combine these things you can look deeply into their eyes while you're saying this to get that five minute clock started yeah well no it's got to be silence because

there is something about so my wife and i did this we've been married how many years 12 i don't know some number more than 10 and it was really awkward for us still to stare into each other's eyes for five minutes without talking how many times did you break into laughter a lot of times okay but i had a better poker face than my wife she broke out more yeah she felt more uncomfortable feeling deeply uncomfortable being alone with me i guess is a that's something your wife and i share to me encourages yeah oh my gosh oh man well at least we've solved the awkward how to yeah awkward small talk is no more now you have life-changing relationship building talk yeah i mean just go straight to deep yep okay right oh hot desking it just sounds awful i mean i feel like i'm

imagining what this would look like in a high school and it would turn into groups forming right yeah first everyone would pick a new spot but eventually the hierarchy would be established okay and i think you need to take advantage of that by just claiming the top floor for yourself and then invite people into your crew like you can be the hierarchy if you get in on the ground floor figuratively but top floor literally in establishing the hierarchy you get to put yourself at the top it's brilliant that's great i mean i guess could you work out some system to where your desk is not hot your desk is cold and you you lock in maybe you raise it a little maybe put some bricks under it so it's up off the floor a little taller than the other desks get that

hierarchy going and lock it in and then start inviting lieutenants to surround you to challenge other you know would-be hot desk usurpers you need a small army ah like you have to do you have to take over all the desks nearer to you first yeah okay yeah i like that i mean i'm trying to think of something that would make your desk unattractive to someone else that would not make it also really bad for you to use there's a bunch of stuff you could do to make no one use it but Right. I mean, I guess if you do that to all the desks, then someone will have to address the hot desking problem. All the desks in the perimeter around your desk, right?

Like build a barrier? Yeah, that's what you need. So there's this book called High Rise. Have you heard of it? No. It's about an apartment complex that becomes cut off from the outside world. And it sort of becomes like surreal and slightly spooky. And the apartment complex rapidly descends into chaos with these like warring tribes.

and they they become uncivilized they devolve okay and i feel like this is a recipe for that like what if we took away this structure that is important to people then it turns out what replaces it is chaos and some people thrive in chaos sometimes the people that thrive in chaos like thrones of skulls yeah this is not the first time thrones of skulls have come up in the show no that's a theme quit your job is the first thrones of skulls is the second theme of the show yeah hmm i don't know i i wonder if you couldn't just like rebel and say hey friend let's sit in the same spot tomorrow and then you meet and then slowly build that out yeah i mean i think that'd be great then it's a then it's a game of musical chairs because you have you don't have enough

desks for 30 of the people to do that right right so the last 30 just sits on the floor They can sit in a hot hallway. We call this hot ground. Hot grounding. Yeah. Just root yourself right there. Feel connected with the earth on that cold corporate tile. What if you made it really guilt-inducing to take your desk?

Just filled it with pictures of loved ones and very customized knickknacks and needy plants that require extensive care. if i sit here this plant will die yeah if you i mean they have office dogs sometimes if you could find an office pet that annoys other people oh yeah that's a winner like this is my office fox i guess or something he's shackled to the desk i'm just thinking how that would uh but i'm don't call animal control on me i guess yeah yeah this sucks hot desking sounds horrible yeah it's so funny like desk location and moving desks feels like such a small deal but back in the before times when there were offices i felt like that caused quite a bit of stir among employees they attach a bunch of a lot of importance to it yeah so this stinks i would

just say pay spend 30 more money please this sucks yeah not gonna happen 30 more money yeah yeah you're right i don't know what to do i don't either i mean i it's just it's such a bad situation i even feel i feel weird offering real solutions but one idea would be to start organizing an impromptu lunch group kind of put up some posters or something and say hey we're going out to lunch every day at this time meet at this point if you want to have lunch together because chances are you're not the only one who hates it and would love to go to lunch with that's a good point yeah if you are sitting next to someone new every day like a lot of other people have to be they can't all know each other and be good friends except for you right you could start

a you could start a little chess club lunchtime chess meet me at hot desk 47a and no matter who's sitting there we'll play chess on it oh that's how you do it you got to attach a like an a rating system to it yellow and chess or whatever that's how you you you rank up and as your rank goes up in chess you also move to different spots on the floor yeah all right i'm out of ideas okay problem solved anyway good thing sorry it's a good thing you're running out of ideas coincided exactly with the moment that the problem was solved that's true what can people do if they want to have this amazing coincidence happen to their own questions. Go to softskills.audio and click ask a question where you can fill out our form to leave a question for us. And we just

want to say thank you to everyone who has done that. We get a lot of questions and we love every single one of them and every single one of you who listens every week. We will catch you next week.