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!
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".
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?
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.
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.
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.
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."
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.
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.
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.
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.
> 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.
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.
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.
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).
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.
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.
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.
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!?”
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.
> "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.
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.
I do appreciate that your interpretation is one possible interpretation of the above but it isnt the only one.
You can also interpret it as develop as fast as possible, avoiding any kind of development guardrails, keeping no docs and being ok with 150 page requirements word documents that will become outdated tomorrow.
I wish this were me being disingenuous in interpretation but IME it's not all that uncommon.
Sustainably, yes. Ive seen it mean cut corners and a rapid build up in technical debt just as if not more often. The agile principles now stick in my craw as a result.
I kind of wish agile DID emphasize feedback loops but it doesnt. A set of principles that waggle their eyes and hints suggestively at feedback loops isnt good enough IMHO.
Yes, that does happen, but the agile manifesto addresses sustainability too:
> Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Agile development is massively misinterpreted, but this is on purpose. Actual agile development promotes bottom-up structure and rejects the types of process that generate metrics that corporate types can use to maintain control. Thus it will never appear in its real form in enterprise companies. Cybernetic organisation is inherently anti-authoritarian, and corporations are inherently authoritarian, so this is an inevitable and largely insurmountable conflict. I'm honestly surprised that Toyota was willing and able to implement lean manufacturing, agile development's predecessor, given it places trust and authority in the hands of factory workers.
>Agile development is massively misinterpreted, but this is on purpose
I dont believe it is. It's just a result of its intrinsic vagueness and everybody integrating it into their belief systems.
Furthermore, I think it was left deliberately vague enough to allow people from the CEO down to the lowliest programmer project their (potentially conflicting) desires on to it because thats how you drum up consulting business.
>Actual agile development promotes bottom-up structure and rejects the types of process that generate metrics that corporate types can use to maintain control.
You could argue that people over process means that but as with all agile principles it's not the only valid interpretation.
It's also the opposite of what scrum does but...apparently most people agree thats agile?
Dont get me wrong i think your view of what agile "should be" and mine are closely aligned I just think it needs its own name "x" to avoid all the baggage (e.g. it should not be possible to consider scrum "x").
Changing the name of things will not prevent the process of recuperation, which is what I'm saying happened to the concept of agile. Any idea can be "reinterpreted" to remove its more radical parts. I mean hell, cybernetics itself has been recuperated into management consulting since the 80s, hence all the references to synergy and portmanteau words like imaginnovation or whatever - and cybernetics are at the core of the type of "agile" we both approve of. There is no convincing CEOs with words to hand power over to employees, regardless of whether it improves productivity or not.
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.
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.
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
> 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.
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.
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.
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?
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.
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.
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.
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).
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!