[HN Gopher] Maximize value, not quantity
___________________________________________________________________
Maximize value, not quantity
Author : iron_coder
Score : 118 points
Date : 2022-02-18 22:06 UTC (2 days ago)
(HTM) web link (agileotter.blogspot.com)
(TXT) w3m dump (agileotter.blogspot.com)
| tpoacher wrote:
| Nice article.
|
| I had similar thoughts on 'work better' vs 'work more' in the
| past, and how it relates to Boyle's law :)
|
| https://news.ycombinator.com/item?id=30000296
| kqr wrote:
| Since it's a common misconception: Value =/= cost.
|
| Instead of asking your developers "how long would this take to
| do?", ask the business people, "how long can we spend on this
| without losing money on it?"
|
| This changes discussions to become much more productive and
| informative for all parties. Often easier too!
| thomasahle wrote:
| > ask the business people, "how long can we spend on this
| without losing money on it?"
|
| Presumably you'd want the developers "How much value can you
| create in time `t`", v(t), and the business people "how much
| money will we lose in time `t`", l(t).
|
| And then you'll find the maximum of `v(t)-l(t)`.
|
| The problem of course is how much communication it takes
| between the two groups to optimize this. And how well they can
| actually estimate.
| e1g wrote:
| Asking that would signal a profound miscalibration in your
| understanding of how businesses work (unless the only thing
| your company does is sell your billable hours).
|
| For example, nearly every startup is losing money until they
| become a unicorn (and often, well after) - this doesn't imply
| that what their developers/ops people do all day is worth
| either "nothing" or "billions".
| kqr wrote:
| But someone in the business ought to have estimated the
| impact of a task, and it's very useful for developers to be
| in on that discussion because then they can suggest
| alternatives that are way cheaper but still worth just as
| much, or that cost slightly more but would also be worth so
| much more.
|
| And that's just the immediate benefit. It goes beyond that to
| organisational learning and being able to calibrate past
| estimates and get better at picking high value fruit rather
| than just the low-hanging ones or the ones someone has a good
| gut feeling about.
|
| But in my experience from organisations both small and large,
| new and old, is that it's actually a huge mental shift
| required to go from "this sounds neat let's do this" to
|
| - How exactly do we actually think doing this will help us in
| the long run?
|
| - How would we express that in dollars to be able to compare
| it with other things?
|
| - How soon will we be able to tell that we were wrong?
| e1g wrote:
| Say you're building an enterprise SaaS, and several of your
| VIP customers ask for a button to "Export this table into
| Excel for offline analysis". These customers are paying
| >$100k p.a., and not threatening to leave or anything, but
| it's a feature you think would be valuable for the core
| product. You ask a developer to build this, and they ask,
| "How long can I spend on this before we're losing money?".
| There are several ways to answer, but few are polite. While
| every business has some prioritization matrix/process,
| rigorously estimating the "marginal revenue" for each
| movement in the dance would add friction and internal
| transaction costs that make the business not viable.
| kqr wrote:
| The nice thing about estimates is that you can make them
| at whatever confidence level is sensible.
|
| If a precise estimation (which is what it seems like you
| think of) adds too much friction and internal transaction
| costs, make it at a different confidence level.
|
| So in your specific example, you might go, "I can't give
| you the exact tipping point right now, but I'm 98 %
| certain it's worth more than five days. So if you end up
| spending four days on it and it's still not done, come
| back to me for a more precise estimate."
| e1g wrote:
| As a thought experiment: even though it's impossible to
| meaningfully answer "how long can we spend on this
| without losing money on it?", imagine some omniscient
| Business Analyst does the math and confidently declares,
| "I expect this button to increase our profit margin by
| $300k p.a.". Presumably, the developer now has the
| commercial guidance to announce, "My salary is $200k, so
| yes, I will create this button in the next 12 months, and
| it will be my only job to oversee The Button as long as
| it exists, and the business still gets to keep $100k p.a.
| Great planning session."
|
| Estimations and prioritization systems are entire complex
| fields we could debate. I'm not trying to do that; I'm
| saying that asking "how long can we spend on this without
| losing money on it?" will not be a productive addition to
| most (all?) discussions with developers/product
| owners/executives/clients.
| kqr wrote:
| How do you define "meaningfully answer" to arrive at the
| conclusion that it's impossible? To me, meaningfully
| answering that is just as possible as meaningfully
| answering "when will Tobias die" which is something life
| insurance companies have done for a very long time.
| e1g wrote:
| We're getting quite off topic here, but the "duration of
| a human life" follows a narrow, predictable, bell-curve-
| shaped distribution. "Impact of this feature" does not -
| it follows the power-law distribution. Life insurance
| companies can meaningfully estimate when you'll die, but
| they cannot meaningfully estimate the value of attending
| any given party/meeting/trip/conversation. Most of those
| will be meaningless by comparison to the few that cause
| an inflection point and make your life worth living,
| often by accident.
| kqr wrote:
| The neat thing about these power law numbers is that you
| don't need to estimate whether we're talking 83 or 91.
| You just need to do enough work to tell apart 1000 from
| 10, which is often considerably easier.
|
| And note that I'm not saying you'll always know down to
| the cent, or even closest hundred dollar bill. Sometimes
| your best estimation is going to be "between zero and
| 999999" and that's fine. If you've determined that, you
| also know which of your inputs have the most uncertainly,
| and that might represent a blind spot of yours at an
| important aspect of the business.
|
| Or it represents a fundamentally unknowable thing. But
| then at least you know you're staking this part of the
| development on a fundamentally unknowable thing. That's
| more than many other know.
| hgomersall wrote:
| It's also likely a made up number. I find many people
| think business is about careful planning and optimising
| what you do for the best outcome. In practice, it's the
| opposite - you do what hope will add the highest value in
| the long term, then you scrabble about trying to realise
| that value or change tack in response to feedback. Some
| win, some lose, and all with varying degrees of severity.
| dageshi wrote:
| I mean yeah, essentially this is uno reverse carding the
| business people with a question that's as difficult for
| them to answer as their question is for the dev.
|
| They probably don't know. They're waiting for the dev to
| throw a number out so they can gut feel whether it'll
| work or not.
| yakshaving_jgt wrote:
| Oh, but isn't that exactly what they deserve?
| dageshi wrote:
| yes
| mettamage wrote:
| Don't you always lose money on it though, since at least one
| dev should be working on it?
| kqr wrote:
| Not if it makes you more money in revenue than it costs in
| developer time.
|
| "But isn't that obvious and the case for all developer time?"
| Try running the numbers some time in your organisation.
| You'll be surprised at how often things are produced at a
| loss.
| thunkshift1 wrote:
| No you dont..Paying a dev is not losing money.. why hire the
| dev in the first place in that case?
| Juliate wrote:
| Accounting-wise, it's very common that R&D and developers
| are counted as cost centers, not profit centers.
|
| This is not necessarily a problem, unless the management
| (and shareholders) only understands costs as an impediment
| to be pressured and reduced (which is sadly also quite
| common - and not necessarily false either).
| chrisweekly wrote:
| This varies so much across companies, let alone
| industries. It was gratifying a few years back to realize
| that annual revenue per engineer north of $4m put our
| team in rarified company. I wonder how common it is to
| examine that metric. While I'm happier (and earning much
| more) consulting for a deep-pocketed enterprise where
| enginering and R&D are treated as cost centers, I kind of
| doubt it's something my current clients have ever even
| considered.
| judge2020 wrote:
| But adding or removing developers doesn't add or remove
| that revenue. If some exec wants to make a show by
| increasing (short-term) profit, cutting developers is a
| quick and dirty to do that.
| VBprogrammer wrote:
| I think the conversation is what is the expected return vs
| the cost. Honestly, I'm not sure I'd really like to have that
| conversation with the business people too often. Once a
| product is complete I doubt many feature enhancement have a
| decent business case.
| kavunr wrote:
| https://basecamp.com/shapeup seems to understand this at a core
| level in a better way than scrum.
| [deleted]
| rgbrgb wrote:
| Maybe dumb question, but what does PO mean?
|
| Edit: Oh, might be Product Owner (kinda like product manager)
| which occurs halfway through the post.
| blurker wrote:
| I love this message. I think that most of the time it's best to
| have an optimistic mindset about your team and trust that they
| are doing their best, or at least want to. In my experience, more
| times than not, unproductive teams aren't the result of people
| working on the team being "lazy." It's usually externalities like
| unrealistic estimates, poorly scoped tasks and various company-
| driven disruptions to the team's focus. And if people are "being
| lazy", it's usually still an indicator of other problems that
| have destroyed their morale and a leader should look to fix those
| things. Otherwise you are trying to treat the symptom, not the
| problem.
| [deleted]
| [deleted]
| egman_ekki wrote:
| That is kind of evident. I wonder, though, when you get the most
| value by increasing quantity (e.g. of iterations on a feature)
| and how far you should push (even yourself, not just others).
|
| As a reference: https://jamesclear.com/repetitions
| kqr wrote:
| I think that viewing it as "quantity" focuses on the wrong
| thing. What you want to maximise is opportunities for feedback.
| Ozzie_osman wrote:
| This is great and in line with how the best teams I've seen
| operate.
|
| The only gotcha is that this only works if you have the right
| people on the team and the right culture at the company, because
| it assumes that people will do their best work without needing to
| be pushed. Now, if you have a breakdown (have free riders on the
| team, or a shitty company culture) this breaks down and things
| deteriorate into the "push people hard and hold them accountable"
| mode).
|
| Basically, operating in this mode requires a high degree of trust
| from all sides. Trust can be self-fulfilling and easy to disrupt.
| By pushing for efficiency you can easily turn your team into one
| where you HAVE to push for efficiency.
| juancn wrote:
| This applies to every role you can have in an organization. The
| better you get at working on the right thing, the less stressful
| your job will be.
| lumost wrote:
| I always grow tired reading scrum guidelines. Everyone seems to
| boil down to "people are overly emotional spherical cows", simply
| trust the process and do your this small problem the sorting hat
| of scrum has chosen for you.
|
| Anyone who's ever been on a scrum team can tell you that
| engineers are not fungible unless you simplify the work to the
| point that you are left with awful engineers doing awful work.
|
| Of course a Product owner will sometimes think about velocity,
| they might be the CTO! Or a PM struggling with a team which can't
| deliver at the pace the market needs. When does a PO ever live in
| a world where they have oracle knowledge of value? Half the time
| they are fresh bschool grads working with engineers and managers
| with years in the company.
| Swizec wrote:
| The funny thing about emotional spherical cows and trusting the
| process is that the first rule of agile is "People and
| [delivered] software over process". You can and should do
| anything to get working software over the line. Even if it
| means breaking process when it isn't working.
|
| And you should always prioritize people over working software,
| if needed.
|
| Working on a team that groks that part is quite nice actually.
| You can go to your manager and say "Hey this thing is getting
| in my way" and they'll say "Good god man why are you doing it
| then!?"
| beaconstudios wrote:
| This is why I don't believe SCRUM is meaningfully agile at
| all, and only exists so that companies can signal agility and
| management consultancies can sell agility. When agile
| development is fundamentally about fast feedback loops and
| not letting bureaucracy get in the way of delivering, a
| process laden model like SCRUM cannot be said to meet that
| definition.
| pydry wrote:
| Nothing is really meaningfully agile because "agile" isnt
| really a meaningful thing. It's something everyone projects
| their desires onto.
|
| Fast feedback loops were never part of the core stated
| values.
| beaconstudios wrote:
| That's just not true. See here:
| https://agilemanifesto.org/principles.html
|
| All of these statements are about optimising the
| development feedback loop:
|
| > early and continuous delivery of valuable software.
|
| > Welcome changing requirements, even late in
|
| > Agile processes harness change for the customer's
| competitive advantage.
|
| > Deliver working software frequently, from a couple of
| weeks to a couple of months, with a preference to the
| shorter timescale.
|
| > The most efficient and effective method of conveying
| information to and within a development team is face-to-
| face conversation.
|
| > At regular intervals, the team reflects on how to
| become more effective, then tunes and adjusts its
| behavior accordingly.
| [deleted]
| clairity wrote:
| > "SCRUM... only exists so that companies can signal
| agility and management consultancies can sell agility."
|
| many companies employ scrum that way, but it's not
| instrinsic to scrum. it really depends on where the locus
| of control is. if it's firmly outside the team, it doesn't
| matter which methodology you use, you're looked at as cogs
| in the machine, as order takers. the locus needs to be in,
| or at the very least, right next to, the team for any kind
| of agile development to work. it's usually top-down
| hierarchy that causes that kind of friction and expectation
| mismatch.
| beaconstudios wrote:
| But if the team has the impetus to change the processes,
| they can get rid of the SCRUM rituals that don't work for
| them. Given that it comes with quite a few, bottom up
| SCRUM will inevitably change into an actual agile system
| suited to the team.
|
| I've never worked in a team (or run a team) where SCRUM
| was kept wholesale by the team or anything other than
| SCRUM sprints were chosen by management.
| rileymat2 wrote:
| I am sure they are out there, but I have never met a "balanced"
| full stack engineer, unless they were equally bad at all
| levels.
| meesterdude wrote:
| As a full stack engineer, I too am surprised at how hard it
| is for people to straddle both. I think that only came about
| for me, from building my own projects end to end.
| clairity wrote:
| people have different strengths and perspectives (the non-
| sphericalness of real people) so it's not surprising that
| folks gravitate towards an area of strength/interest even
| if they can functionally work on the 'full stack'. as a
| 'full stack' dabbler[0], i enjoy the view layer stuff the
| most, but not so much with the js-dominant frontends of
| current fashion. for that reason, i'm really digging
| hotwire as a retro-futurist take on server-side-rendered-
| but-reactive web dev (along with cousins like livewire &
| htmx).
|
| [0]: product manager who likes to make stuff, in my case
| rileymat2 wrote:
| Yeah, I would consider myself full stack, but when it comes
| to css I definitely tweak and pray like a hobbyist, not a
| professional. I can change and implement front end as
| maintenance or evolution, but God help me if I start in
| greenfield front ends.
| [deleted]
| Mc91 wrote:
| > Everyone seems to boil down to...simply trust the process
|
| In older days business would say what they wanted, engineering
| would give a time estimate, and then we get to work with a
| deadline both commit to - the waterfall method.
|
| With scrum, business says what they want when they want
| (although preferably at the beginning of a quarter), but no
| real estimates are done and thus no deadlines, work comes in
| and is prioritized. This entails the micromanagement of daily
| standups, stories needing to be broken into bite-sized sprint
| length segments etc.
|
| Except we still wind up with deadlines, sometimes not even
| communicated until the team is into the work already. So it is
| the worst of all worlds - engineering gives no estimates,
| micromanagement of daily standups and features needing to be
| broken into small sprint length problems, plus, what was
| supposed to go away but has not - deadlines - not estimated by
| engineering, but handed down as fiat from somewhere in
| management. This might not be "real scrum", but it is how it
| works in more than one company that is supposedly working in
| the agile/scrum method.
| sodapopcan wrote:
| Right, that's not scrum. That's picking aspects of it, doing
| them wrong, and calling it scrum. Just because that's what
| many business chose to do doesn't mean that it has no value
| of done "right". For example, standup is not a "prove that
| you got something done yesterday" meeting, it's about making
| a plan for the day. Many businesses treat as such, but that's
| just wrong. And toxic.
| gedy wrote:
| Agreed. The issue I've frequently run into is business side
| thinking "we need all this, and by this date". Then trying
| to apply "agile" on top of this assumption. It never works
| out with that mindset.
| boffinism wrote:
| Am I the only one who would have preferred this idea to be
| expressed as an idea rather than an anecdote that features the
| author changing the life of a grateful acolyte with their
| incredible wisdom?
| cateye wrote:
| Thought exactly the same.
|
| I was once walking on the street and someone asked me: -"Do you
| know which direction I need to walk to get to a metro station?"
|
| I answered: -"Don't search for direction, accept the presence
| to live a happy life."
|
| The person looked me in the eyes suddenly extremely happy. All
| his fears were gone. He turned around walked away knowing he
| was now a totally different human with a clear mind.
|
| He probably lived happily ever after.
___________________________________________________________________
(page generated 2022-02-20 23:00 UTC)