Hacker News Reader

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.

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

You may have hit on a carrot.

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.

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.

> 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

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.

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

> This is how things like SAFe are born, that try to make "agile safe for the corporation" and of course they're nothing more than corporate BS under an agile name

SAFe was truly one of the worst things I encountered with consulting clients. Planning days were an unbelievable exercise in futility. Waterfall masquerading as agile, the absolute worst of both worlds.

> SAFe was truly one of the worst things I encountered with consulting clients.

we've been using SAFe for a few years, I despise every minute of the planning process. Feel like a mix between using a crystal ball and forcing square pegs in round holes... Of course the additional disfunctionality at my company between sales, PO/PM/BO and engineering doesn't help, though it seems that I've avoided the worst SAFe train of the company.

My last job was SAFe. When I started I was given Staff level title and had dreams of maybe moving into lead or management at some level. Once I saw the process I became completely unmotivated to go in that direction.

For them I understood some of the motivation. Hardware & equipment manufacturer, which involves scheduling complicated industrial processes for months/years out. So you need some semi-coherent vision of where things will be, so having a multiquarter waterfall-esque plan was going to be needed.

Not that any of that actually seemed to work.

I agree that some of the outputs of the SAFe process aren't useless, like expressing dependencies between teams and discussing objectives, but the process is way too costly for what it achieves. Maybe if the name was changed to something like SCRUM and Waterfall evil child...

The issue with scrum and agile is that it became a managerial and reporting process to force teams to hit a management imposed deadline instead of what it was intended to be: a tool for engineers to self-manage and self-evaluate their progress to provide a realistic completion date.

At the risk of taking this thread further OT, I am a product manager / consulting CPO but a whole heartedly agree with you. I like the way you phrase it. A tool to evaluate progress and provide realistic completion dates. That is how I always push companies to use agile pointing and estimating. Use it to identify unrealistic roadmap expectations as early as possible, force hard conversations on priorities and staff allocation... before committing on plans to customers or stakeholders. Or when taking a risk on a delivery date, be doing that knowingly from the beginning, with contingency plans and management owning that risk and consequences otherwise.