Hacker News Reader

Comment by bracketslash | Hacker News Reader

What would you recommend as a better alternative?

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.

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".

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.

> 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?"

As little middle management as possible.

Flat hierarchy is an other kind of bullshit, clearly established leadership is important.

When you absolutely need middle management, force them to also do some real work, if they can’t, don’t hire them.

Most of the bureaucracy problems are magically going away when middle management is gone.

That's one of the reasons I work for a small company. There's just one boss, and he's also what in the US would probably be called VP, both formally and informally (there's a difference between the formal and informal hierarchy). He knows his limits, is technically adept although he doesn't know much about programming, and just cares about usability. As a consequence, there's no politics, no endless meetings (yes, I've done Agile too elsewhere, with those retrospectives, planning meetings and pointless burndown charts). There's no other team blocking me or forcing me to do something differently (because of course teams are self-organizing, but heaven forbid if you do something that touches the domain of another team). The salary is somewhat lower, but I actually enjoy my job.

Middle management is just nepotism, where incompetent/not-caring managers hire from their network to gain power.

>> When you absolutely need middle management, force them to also do some real work, if they can’t, don’t hire them.

That ia a mjor difference between Amazon and most other places I worked at. Amazon management actually did things beyond managing. There are some of the managers in places as well, they are a minority so.

Reply on news.ycombinator.com