[cmrdporcupine]

JIRA has always been terrible though :-)

I miss buganizer at Google. It didn't try to hoist a process. It was... "here's a ticket. go do it. or not. whatever" low clutter. right to signal to noise ratio. The bug tracker in Google's ill faited github competitor was similar. Really decent.

The problem with JIRA is it becomes a little fantasy code writing exercise for people who've stopped coding (managers). You get to pretend you're dispatching program for your robots^H^H^H^Hteam to execute. And write out a little maze for your rats to run through.

Also was just talking to a friend about this. The original agile folks, the XP people... were explicitly against using software to track tasks. It was yellow sticky notes on a whiteboard. ON PURPOSE.

[nobodyandproud]

Which in today’s days of remote work, management may actually like.

You may have hit on a carrot.

[cmrdporcupine]

Mentally making the move from writing code to management needs to be a shift in mentality from "I'm making software systems that solve problems" to "I'm building teams that solve problems".

Team building is people skills, and it's about finding well springs of motivation, soft skills, getting people talking to each other, making sure people aren't forgetting things.

Unfortunately people coming from an engineering/programming mindset can go the other way: management is about making lists, and getting people's names on those lists. Management is about making processes, and making people conform to those processes.

I'm not saying those aren't useful tools, but they need to be seen as that. Tools. Means to an end, not ends in themselves.

Most software developers want to do good work. They want to write code to make things happen, because that's what they were trained to do. Original agile was about trying to liberate that instinct from the crushing weight of corporate processes so that teams of developers could self-organize to do the things they generally naturally want to do.

I don't recognize that in SCRUM based teams today.

And as for your point, I do think that remote work makes things harder, and I've yet to see a remote team that fires on all cylinders. But for years I worked on hobby projects with people who I never met face to face and it was fine. So I dunno.

[bluefirebrand]

> I do think that remote work makes things harder, and I've yet to see a remote team that fires on all cylinders

The way I see it is businesses can have it one of two ways:

They can acknowledge that remote work is fine and allow their teams to work from wherever and figure out timezone differences and async collaboration workflows

Or

They can decide that remote work doesn't work. Then they must stop hiring expensive remote consulting firms and cheap offshore remote teams. They also must stop spreading teams out across multiple regional offices across North America

It is absurd to make people commute to an office building only to have people dialing in to meetings from other office buildings in other countries anyways, and then say remote work doesn't work

[cmrdporcupine]

Maybe? Co-locating teams that work on a singular thing physically clearly has advantage for some organizations.

But yes, mixing remote and on-premise and expecting it to produce improvements is broken. Or being done for the wrong reasons.

I seem to have landed myself at a job like that just recently, in hopes of sparking joy with in-person collaboration again. I am not happy about it.

[convolvatron]

sorry to hear that you're struggling in today's world, but it makes me feel a little better :(

no process that consumes more than 5% of your developer's time can be called an effective process

[nobodyandproud]

Right.

A lightweight process works well when you have engineers that are all of the following: - experienced - competent - understand their problem domain - actually care

In other words, a team of strong engineers (and a great, accessible product owner).

What I’ve found is that lightweight agile fails without a lot of oversight and frequent checkins, for anything else.

So SCRUM is SE training wheels because it forces a cadence, gets engineers to start breaking down work, and estimate; but the cost is that it holds-back great engineers with all of the (stifling) ceremonies.

I’ve gently nudged my risk adverse tech-lead to consider moving to Kanban now that his team is pretty strong now.