3 ms·
Posts like this usually have good points, but I feel like they should always come with a massive caveat: Every team is different, and you should tailor your pr
by munchbunny 8y ago
Posts like this usually have good points, but I feel like they should always come with a massive caveat:
Every team is different, and you should tailor your processes to fit the team.
And because of this, I think posts like this one should spend time answering:
What conditions were needed for your decision to be a good idea? And when would your decision be a bad idea?
The author seems aware of this, because he tries to generalize to just not over-complicating things. But his post is pretty much just arguments for removing meetings entirely without really considering when that might not be a good idea. And there are definitely teams and circumstances where that might not be a good idea.
- antris 8y agoIsn't pretty much that caveat right under the title? "Notice: Below represents my PERSONAL beliefs about agile and team organization. Your results may vary."
- munchbunny 8y agoNot quite. I think there's an important distinction. That caveat says: "I think you should do things this way, it might work for you." But what I'm asking for is: "I think, under these conditions, you should do things this way." But you're right to point this out. I think I phrased my post badly. The caveat isn't the important part. The second point is the really important one. The decision framework for when to take any specific piece of advice is more important than the advice itself. In general (and this is definitely true with development process advice), advice is plentiful and often conflicting, and most of it gives you ideas of what to do, but doesn't tell you when it's applicable. The really good books, courses, and blog posts I've found do exactly that.