3 ms·

Sorry, are you suggesting a better way to operate is to have the team go off for like a five week offsite to come up with a plan for the rest of the year? Then

Sorry, are you suggesting a better way to operate is to have the team go off for like a five week offsite to come up with a plan for the rest of the year? Then once a month, they get a day to figure out if the plan’s still working? It’s an option, I guess… let us know how it works out for you.

steveBK123 4y ago
That's a horrible idea for sure, but I'm not sure the current model being derided works for all team compositions either. In a 20+ person dev team with a lot of juniors, the team is not "coming up with a plan" or "deciding if its still working" so much as product/tech lead/a couple seniors who have zones of responsibility are handing one down. The two hours spent in the room is agile kayfabe. "Get everyone in a room and hash it out for 2 hours" is maybe a model that works at team size of 5, senior, empowered engineers, but it is not something that works at large scales.
swiftcoder 4y ago
I mean... yeah. That's kind of how a lot of big enterprise projects with VP-level visibility get managed (I participated in versions of this at both Amazon and Facebook) Obviously you don't need to pull all the junior eng offsite for a whole month, but the engineering leads + PMs + engineering management end up there. And obviously there's also ongoing prioritisation happening between leads/PM/management throughout the year - but that doesn't require pulling the whole team every week.
- steveBK123 4y ago
  Yeah, I think this level of planning has gotten lost in our recent fad of agileness. Senior management thinks they know where they want to be in 3 years, but there is no cascading multi-quarter, let alone multi-year planning of the projects & steps to get there. I've even been in orgs where someone senior is trying to make very very large org & tech changes, and really can't be bothered to put the big building block steps to get from here to there. As it turns out, they never get "there". Somehow they know enough to bring in project managers for big concrete things like "retire a datacenter" and go all out with MS Project, GANTT, etc. However when it comes to software changes like "split an on-prem Java monolith into a fleet of python micro services in the cloud" ... it's all iterative vibes the whole way.
  - jameshart 4y ago
    Agileness is many things but I really think we can stop thinking of it as a ‘recent fad’ by now. The manifesto was written 22 years ago. It’s been the dominant mode of engineering organization for over a decade.

steveBK123 4y ago

That's a horrible idea for sure, but I'm not sure the current model being derided works for all team compositions either. In a 20+ person dev team with a lot of juniors, the team is not "coming up with a plan" or "deciding if its still working" so much as product/tech lead/a couple seniors who have zones of responsibility are handing one down. The two hours spent in the room is agile kayfabe. "Get everyone in a room and hash it out for 2 hours" is maybe a model that works at team size of 5, senior, empowered engineers, but it is not something that works at large scales.

swiftcoder 4y ago

I mean... yeah. That's kind of how a lot of big enterprise projects with VP-level visibility get managed (I participated in versions of this at both Amazon and Facebook) Obviously you don't need to pull all the junior eng offsite for a whole month, but the engineering leads + PMs + engineering management end up there. And obviously there's also ongoing prioritisation happening between leads/PM/management throughout the year - but that doesn't require pulling the whole team every week.

steveBK123 4y ago
Yeah, I think this level of planning has gotten lost in our recent fad of agileness. Senior management thinks they know where they want to be in 3 years, but there is no cascading multi-quarter, let alone multi-year planning of the projects & steps to get there. I've even been in orgs where someone senior is trying to make very very large org & tech changes, and really can't be bothered to put the big building block steps to get from here to there. As it turns out, they never get "there". Somehow they know enough to bring in project managers for big concrete things like "retire a datacenter" and go all out with MS Project, GANTT, etc. However when it comes to software changes like "split an on-prem Java monolith into a fleet of python micro services in the cloud" ... it's all iterative vibes the whole way.
- jameshart 4y ago
  Agileness is many things but I really think we can stop thinking of it as a ‘recent fad’ by now. The manifesto was written 22 years ago. It’s been the dominant mode of engineering organization for over a decade.