Comment by josephg | Hacker News Reader

Comment by josephg | Hacker News Reader

Parent Full thread

That would be great. On a client project a few years ago I effectively bullied the product owner into doing that.

We were a few weeks away from a launch. I had sat down with our designer and we made a list together of about 30 changes we needed to make (“this is the wrong blue. This is 2px too big. Etc). The product owner wanted me to put all the changes through our normal process - make a jira issue for each one and we can do task estimation as a team and assign them, and so on. But most of them were tasks that would take a few minutes at most. (Some of the problems I fixed live while working with the designer). Our launch deadline was fast approaching and it would have taken more time to write a good jira ticket than it would to fix most of the issues - let alone discussing them as a group to estimate. While arguing he ended up showing his cards by admitting that the main reason he wanted everything in jira was for reporting. How else would upper management know that we were making progress? I said that sounded like his job, not mine. And he begrudgingly agreed and took my plain text list and dutifully retyped everything one by one into jira tickets. And then marked them all complete a week later when I’d fixed them all.

I think that experience killed the last bit of respect I had for Agile as a methodology - at least as it’s practiced in the wild. If we were using something lighter - like trello - I don’t think I would have resisted so much.

Great story, but re the “killed respect for Agile” bit:

Agile done right is all about less process. It’s right there on the Agile Manifesto:

> Individuals and interactions over processes and tools

I’d also read https://agilemanifesto.org/principles.html for an illustration of what is considered valuable — especially the bit about simplicity which process heavy (aka fake-agile) agile consultants totally miss; also the bits about what constitutes project progress & how to most efficiently convey information.

You should be able to tailor your agile processes to what makes sense for you. Following the herd and insisting on agile ceremonies “because everyone else does it / someone told us to”, even to your team’s detriment, is cargo-culting.

In your case you clearly tailored your process to something that improved your efficiency and met your reporting requirements, so, as far as I’m concerned, you’re doing agile “right”.

Oh, I’ve read all that. But I feel like there’s two agile methodologies - one that the authors intended, a lightweight adaptive attitude where you ground out your process based on what works with your team. And then there’s Agile: The Process as prescribed by agile consultants who go to agile seminars. This agile insists on daily standup, point based estimation, velocity tracking, jira (for some reason), etc. Otherwise you are Doing Agile Wrong, and you will be cast off the holy mountain.

I get the sense the authors of agile used words like “scrum” because they imagine software development like a full contact sport; where everyone is fully engaged with all their senses to truly be aware of what’s happening, what’s needed and what is the most important thing to work on. The cargo culting agile consultant approach always feels like an attempt to make software into a repeatable assembly line, and make software engineers into factory workers.

Fair enough, but that's just really shitty consultants. These days practitioners (the ones I run into anyway) are quite conscious of process overhead. It helps that many are into Lean as well.

FWIW, shitty agile consultants have had plenty of pushback too, with comedy sites like https://www.halfarsedagilemanifesto.org/ being set up to point out their buffoonery. I do suggest laughing in their faces when they pull out tripe like that. Sometimes their excuse is, 'well, we don't work for a startup, we're a regulated business' -- well, it's still tripe, there are plenty of regulated businesses with lightweight agile processes.

My favourite piece of writing on this, in fact, comes from the US Defense Innovation Board, and is called "Detecting Agile BS"[1]. Their recommendations may not 100% work for your organization, and that's okay -- tailor it with an eye to outcomes for your team.

[1] https://media.defense.gov/2018/Oct/09/2002049591/-1/-1/0/DIB...

Playing the devil's advocate, maybe detailed reporting to the boss is useful and worth doing. Probably the product owner's job and not yours, but not necessarily a bad (or, specifically, not agile enough) way to work.

I'm familiar with using Jira for enough customer support requests to require a full time ticket wrangler position, and closing tickets timely with accurate reports is often more important than the requested fix or support intervention: looking good with the IT managers that are, for all practical purposes, our customers has a higher priority, for everybody, than helping a random end user with a noncritical problem.

I disagree. We were a product team. Our primary responsibility to the company was to ship working code, not open and close jira tickets. Would management have forgiven poor reporting in the scramble leading up to an on time / on budget launch? Yes. Would management have preferred a delayed release in exchange for more tickets visible in jira? No. I’m sure my manager could pass it off and say he did his job (look at the velocity graph!). But we would be failing our responsibility to the company.

That is such bad Agile. No wonder people have such bad feelings about it. :-(

Reply on news.ycombinator.com