Comment by duncan-donuts | Hacker News Reader

Comment by duncan-donuts | Hacker News Reader

Parent Full thread

Not op but I’ve worked in Agile™ shops, places that are agile, and waterfall-y enterprise stuff. The biggest difference I’ve noticed between Agile and agile shops is that ceremonies or lack thereof make no difference. Pointing doesn’t matter, extensive grooming doesn’t matter, extensive planning doesn’t matter, sprints don’t matter, etc. Grooming your work does matter but 30 minutes is enough for a high performing team to hash out a week’s worth of work. Planning does matter but it should be kept to high level product goals and nothing more. Sprints should only be used if you have something you’re actually sprinting towards. Most of the time that’s not the case. Points straight up don’t matter.

All of this being said this puts a lot of pressure on product managers because it’s hard for them to express how long something will take. The key here is that even if you do all the ceremonies you don’t really know how long it’ll take anyway.

The only way you can work like this is if you have built up trust from your PM. If you can throw all of the shit away and give the PM what they want they’ll go to bat for you. For agile to work there has to be an incredible amount of trust that every team member is going to do what they say. And the lack of trust is when you get Agile™

> The biggest difference I’ve noticed between Agile and agile shops is that ceremonies or lack thereof make no difference.

The best project I ever worked on: one developer (me), one project manager on our side, one QA/test person at the client, and one manager at the client who was what we'd call a product owner on a scrum team.

No ceremonies, no pointing, very little backlog grooming. Shared Bitbucket repo for issue tracking. Deployments scheduled every Tuesday when their QA person signed off on the feature working as expected (this was in the days before CI/CD became common).

Worked great. Low friction, they got features and bug fixes, we didn't get hassled, and we could set up a call (or usually just a couple of emails) if we needed clarification or needed to explain why something was more complex to do than we or they originally thought. One of the best six month periods in my career, and I've been doing this stuff for almost 25 years.

I don't mind some aspects of scrum, but the things I don't mind (mostly around team autonomy and self-organization) seem to be the same things that are quickest to get thrown out when someone gets impatient.

Have you read Team Topologies? This sounds like a stream aligned team, albeit a small one, and sounds like you had great success.

I have not, but thanks for the recommendation - I just put it on my to-read list.

Who knew coordinating development work could be easy with one developer?

That definitely simplified it. :) That said, we could (and for a few weeks, did) bring in a second developer with no issues.

My last job had me on a ten person developer team and I would not try to use that process there - although I'd consider splitting that into a couple of smaller groups focused on a specific product/system and using a very lightweight process for those groups.

So much easier with small teams. Scaling to say 1500 people is hard. Then you need some kind of hierarchy and explicitly architecture. My biggest problem with agile is that people think it replaces architecture with ad-hoc decisions. Threading in design work as spikes and regular stories needs about the same discipline as "processes".

> one developer

Someone once said to me "the advantage of a team of one is that there's only one clique and everyone's in it". I think about that from time to time 20 years on.

The worst thing about Agile is the commercialisation that came with agile training coaches and certifications. It always boggles my mind when realising how many people think “agile” means sprints, backlog grooming, Fibonacci sizing or planning poker and not what’s in the manifesto.

When you take it back to its roots and cut out all the Scrum or SAFe nonsense and adapt it to your team it can really work.

Note, I’m not saying estimates are bad per se and can imagine teams for whom it does work, but it would have to be something that the team is happy with not an impose-from-above methodology…

The ceremonies and pointing are often a big waste of time. I worked at a place that really drank the Agile koolaid, and dreaded every "planning" and "retrospective" because it was so incredibly tedious. "Is it this 2 points or 3?" "What did you learn this sprint? What went badly?"

Reply on news.ycombinator.com