this post was submitted on 01 Aug 2023
221 points (98.7% liked)
Programming
17313 readers
242 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I've seen this play out many times, but only once was it good. BUT ONCE I did see it be good. It was interesting enough that I took the mental notes of why it worked. Huge asterisk because there are still pitfalls around the team having a single point of failure, but that's an issue with many other modes with mixed skill.
Anyhow:
-The whole team was bought into it as a working mode
-There was a QA embedded directly into the team
-The bulldozer was forced, but willing, to routinely re-communicate plans and issues
-The bulldozer became good at proactively communicating "hotspots"
-The bulldozer was not allowed to do estimation, the surrounding team did that.
-The bulldozer agreed to be obligated to prioritize helping the team if they had questions (I think this is what helped him to be so proactive... He was incentivized to avoid this scenario of confusion entirely)
Anyways... I still don't recommend it. But, assuming people are into it, I think there are ways to arrange the right individuals into teams in a way that minimizes the major pitfalls. I'm a pretty big fan of letting/helping teams self-organize into whatever their efficiency maximum is.