Maximize value, not quantity
agileotter.blogspot.com
agileotter.blogspot.com
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!
"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.
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).
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.
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".
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?
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."
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.
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.
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.
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.
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!?”
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.
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.
Fast feedback loops were never part of the core stated values.
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.
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.
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.
> 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.
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").
[0]: product manager who likes to make stuff, in my case
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.
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.
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.
Edit: Oh, might be Product Owner (kinda like product manager) which occurs halfway through the post.
I had similar thoughts on 'work better' vs 'work more' in the past, and how it relates to Boyle's law :)
As a reference: https://jamesclear.com/repetitions