Hacker News new | ask | show | jobs
by shade 1377 days ago
> 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.

4 comments

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.