The art thing is the secret all of us who've been doing this long enough have learned to accept silently: you can't tell management that there's simply no quantifying metrics that will indicate a piece of software is good, because it's inherently qualitative, you can't measure a good bit of code with numbers any more than you can measure Picasso's works numerically to identify it as good.

Just like art, sadly it's all lagging indicators: good art is recognized only after its creation, and it's the artist you must recognize made it good - not some specific reproducible technique. It's that artist. Management never of course wishes to hear that, they want everything to be good by direct reproducible application of approaches. They can get part way there, but the real stinker they refuse to accept?

Good software is only recognizable by lagging indicators after it's made. That's just the fact that so much of our industry fights not to accept, wanting predictive indicators but sorry. The predictive indicator is the quality of your artists, the lagging indicators need to be watched more:

• Defect rates
• Functioning software
• Time to recover
• Time to repair
• Time to enhance

Tons of garbage software with all the latest greatest approaches used in their creation are garbage art, they work and have no defects but take a year to repair or enhance because the artist didn't have the qualitative vision.

Are more developers burning out? Or am I just seeing things.

The core structural problem with the Agile industrial complex, is that it doesn't explain that Agile is actually hard to do. It requires a ton of trust and power be granted to the development team. Most companies are not prepared to do that, they want control over the team, and most devs are only used to being told what to do and when. Having the whole team own the product, being involved in working with the PO to define and refine stories, then implement stories from start to QA to deployment, is a lot of engagement and collaboration many teams are not used to. From the other direction, many other people in companies want deadlines, not best estimates from the Agile team when something will be done.

It is not surprising that there are more failed Agile teams than successful ones.

"Agile" company that is (really) not agile.

Separating money from politics. Make politicians become public servants, unable to invest in stock markets, receive donations or legalized bribes(lobbying). They would have no salary, the government would pay for everything they need, and whatever they request has to be reasonable, justifiable, and necessary. The whole idea is to make them less corruptible, these are just general suggestions. I’m sure there are more qualified, competent and smarter people that can find more ways to make this a possibility. They should represent the people, not corporations. Separating capitalism from democracy is essential, because capitalism will always corrupt democracy on any level.

how do you think that Government corruption will be eradicated in future?

Thank you for sharing your experience. It's informative to read an actual experience of someone who made the step, for a question/desire we coaches and scrum masters encounter a lot, at least I do: Should we change the tool-stack.

I have been in many large multinational organisations and some smaller but still larger than 50 people. It's always a hassle whatever tool you are using, be it the Atlassian Stack or Microsoft Azure DevOps or any other.

Organisations are messy and we hope tools bring structure to that. ...While it can help a bit. If the tool doesn't follow the way of working as much as people would like it to be, or brings the feelings of overhead. People will work around it and then the tool becomes another bottleneck in the system.

We expect more and more from the tools, be it Incident Management, Time Tracking, Kansan, Scrum, SAFe, Portfolio Management, Priority Management, Reporting and more, all while processes(and people) constantly change.

Maybe we could focus on reducing the complexity of the organisation, instead of making overly complexing tools try to solve the difficulty we create? Just a thought.

Migrated from Jira to ClickUp: The Grass Wasn't Greener on the Other Side 🌱➡️🔥

The answer comes from The Time Machine.

They see themselves as Eloy and we are the Morlocks. They live in sunshine and just consume and we live underground and produce. The occassional sacrifice of an Eloy to keep the status quo is ofc needed.

Thats my own little conspiracy hypothesis anyway.

Survey reveals almost half of all managers aim to replace workers with AI, could use it to lower wages

Same as most of these guys: born to privilege (Sam's mom is a dermatologist), went to a reasonably exclusive prep school (Burroughs in St. Louis, IIRC), goes to a university where investors hang around the STEM departments and hand 20-year-olds cheques and tell them they're Jesus Christ (Stanford, of course) which then plugs them into the tech and VC ecosystem that means they rarely have to consider the downsides of what they're doing or face a consequence.

Meet OpenAI CEO Sam Altman, who learned to code at 8 and is a doomsday prepper with a stash of gold, guns, and gas masks

Scrum isn't a cult. Management is a cult. And they will ruin whatever clever process engineers construct as an alternative to their because-I-say-so bullshit. There is no process they cannot abuse in this way, because the nature of bad faith is that there is no right answer.

As you put so clearly: new rituals, same old structures.

Scrum Teams are often Coached to Death, while the Problems are With Management

Self organizing is the key. Scrum was successful only when it emerged from the workers, never (in my experience) when imposed from management. Plus when directed from the top they would usually make a few “improvements”, a few small changes that effectively made it, at it’s core, the same as waterfall.

Scrum Teams are often Coached to Death, while the Problems are With Management

Right. But... if someone is making delivery estimates, it's because they feel delivery estimates are needed. There's a good chance delivery timelines are important to the business.

It's great that we as devs can run on sprints that deliver abstract unitless points of complexity. But the rest of the company has to make actual deliveries on actual days.

Sales can't sell "75 abstract unitless complexity points" to customers. Marketing can't design and buy campaigns enticing you to buy "75 abstract unitless complexity points". God forbid you're working with a physical product, because manufacturing definitely can't build a widget that runs on 75 abstract unitless complexity points of firmware.

But experience also shows that companies are rarely willing or able to do what is needed to deliver software on time, on spec, and on budget.

So what do you do when others need to know delivery timelines for actual specific features for good reasons, but you don't want to give delivery timelines for good reasons?

What are everyone's thoughts on moving away from the concept of Story Points?

Sadly, this is a side effect of "promotion-driven development". The performance theater mandates that to advance, you demonstrate impact, preferably measurable as something which is not trivial. As there is only so much "organic" impact you can make in a business doing "business things", there is an entire side quest of developing stuff which is not strictly necessary but can be used as casework for a performance review. When the promotion is achieved, the "stuff" which was often a solution looking for a problem, is abandoned, deprecated and then just dies a slow death.

Artifacts of those developments might linger in an organization for a while and sometimes be actually detrimental to core "business things" as the "not trivial" clause slides over to "proven in production". Then a few months or years later, the person who initially wrote it, got their promotion and is nowhere to be found. Now it's your problem.

Obsession with impact