[JackOfCrows]

For people who worship capitalism as much as folks here do, a lot of you sure don't get business processes. Yes, you wind up having to plan things, because the rest of the business world runs on deadlines and contracts and milestones and deliverables. Agile is, God forbid, almost like being an artist or low, disgusted whisper liberal arts major...when done correctly, in that you're iterating and tinkering and shipping and ideally you eventually get to good software sometime.

Only the business world runs on quarterly results and shareholder value and being able to say "yes, we are shipping 10 great new features next quarter, we have a $20 million marketing campaign, new user acquisition campaign, outreach to lapsed users, and PR campaign all ready to go" gets you bonuses and increased stock prices and new investment rounds.

Saying a bunch of Agile gobbledygook gets you...a job as a product manager or lead but you still gotta hit those milestones

[SideburnsOfDoom]

The question that you're missing is: Which works better? Which delivers more better software, more reliably?

Granted, the business world does run on quarterly results and shareholder value and being able to say ..., but you can say any damn thing that you like, only promising it doesn't guarantee that it will happen. Software development is always uncertain, the question is how best to tame that - ignore it or lean into it.

All things being equal, of course the the business world would prefer the most detailed predictable plan. But, they just aren't equal. Software development benefits greatly from short feedback loops. In all phases - from debugging to finding out what the users really need. That is antithetical to big upfront plans.

[AnimalMuppet]

Let's say agile can deliver better software, and maybe even more reliably. The issue is, somewhere up the org chart, there's someone who operates in terms of yearly plans and quarterly results, and there's an impedance mismatch between that layer of the org chart and the agile process below them.

Even if you can really do agile (instead of "Agile"), that mismatch can ruin you. In the long run, it probably will, unless you have someone on the agile side able to talk in terms that the other side can understand. The agile side has to actively manage that connection; the business side isn't going to do it for you.

I have seen the best agile environment I have ever seen destroyed by this mismatch. Upper management killed it because it couldn't understand how to measure and predict the agile development process.

[goodlinks]

There needs to be a stable narrative to shareholders, anything within your control should be managed.

Moving all software development into some kind of skunkworks part of the business with 0 expected returns and only ever discussing roll outs may be one way to do it. (Shrug)

Its why i think innovation is maybe a bit easier at a privately held or government owned org. They can look at the value more directly rather than through share value impact.

This response is just about how big a deal the shareholder perspectove is, if you can fly under that radar then you stillneed to convince everyone else that you can be trusted to deliver eventually.

[SideburnsOfDoom]

> There needs to be a stable narrative to shareholders

I don't disagree with that. In fact, knowing the end goal is even more important when actions are "skunkworks".

> Moving all software development into part of the business with 0 expected returns

Agile's focus on "Working software is the primary measure of progress. ... early and continuous delivery of valuable software." is IMHO the opposite of that characterisation; as it demonstrates value and solicits feedback as soon as feasible. Note that this has very little to do with "is it following a pre-agreed plan or not?".

The issue is more that too many businesses believe that software development is best done as top-down detailed micromanagement, and the tools at hand (i.e. Jira) lean into this delusion.

[goodlinks]

Agreed. Software development and basically all efficiency / process improvements are not really top down at all.

I just think that anything not top down doesnt play nice with shareholders. Also doesnt play nice with management that want to say they are the ones that got something delivired.

Seeing projects get rejected as they delivier too much of an improvement (e.g. we only predicted 5% savings this is likely to give 40%) really opened my eyes to how important it is to appear like you are more in control than you are.

On the skunkworks suggestion, i was meaning dont put anything from that team into any forecasts until you have a better measure of the impact.that way you controlthe narative better.

[ozim]

I don’t believe there is something a dev is coding right now that will affect current quarter results.

I just don’t see it.

But I see bunch of middle managers who think it will affect their bonus if they push little guys to deliver sooner.

[datadrivenangel]

The software shipped this quarter affects the results next year, and potentially for the rest of the life of the software.

The middle managers definitely win more if they ship more.

[bratbag]

That just means you have a shit management culture that values lies about deadlines over the type of honesty that builds profitable products.