> Figuring out if the plan is still the right one?
15% every week is the problem here. If you spend 10% of your annual budget on upfront planning and 5% monthly on checkins, that's maybe ok. Putting the whole team in a room every week is just going to churn the plan constantly - inputs likely aren't changing with that frequency, and you aren't going to be able to pull in all the other stakeholders that often anyway
> Putting the whole team in a room every week is just going to churn the plan constantly
Yes, that's the point, that after each week (or two) of work, we've learned more and the plan already is outdated and needs to change.
> inputs likely aren't changing with that frequency
In my experience, they absolutely are unless you're building the simplest CRUD app that's identical to one you've built before. The inputs are less often changes from external stakeholders, and more often tasks that are turning out to be more difficult than hoped.
> and you aren't going to be able to pull in all the other stakeholders that often anyway
Of course you are. It's the PM's job to gather the new inputs, go check in with relevant stakeholders (takes a day or two at most), update or re-confirm their priorities, and then make the updated decisions for the next sprint.
In my experience, 15% of time spent each week on planning is about right. It doesn't maximize the productivity of each person coding, but it hugely maximizes the productivity of the whole team in delivering a valuable end result.
My experience with weekly ticket grooming is that most of the time we spent 1-2 hours talking about the exact same tickets we talked about last week and left everything in the exact same order as it was when we started. When working on quarter+ long projects there just wasn't anything that changed week-to-week, and when things did change the actual planning to adapt to that was done immediately, not in the weekly meetings.
What was great with my ticket grooming bi-weeklies was that despite having 20 engineers in a room, we were strongly admonished from going into technical details of implementation in the room. "Take those offline. But please put a size on the ticket, thank you."
What else do you want us to do for 4-6 hours/week? Write poetry?
Eventually every ticket just gets sized "medium-big", and people keep their heads down with mouths closed.
So, in my example, we were having 2-3x/week 2-hour, full dev staff meetings.. without product in the room. He was a very busy man and could only grace us with his presence for 30 min every 2 weeks to basically sort the tickets we had spent 12 hours putting together and decide which he actually cared about.
Much could be accomplished more efficiently by getting product, management, and 1-2 seniors in a room for 30min to actually decide what/if plans have changed & cascade the changes accordingly.
99 times out of 100, the plan didn't change because something raised from the bottom, but because management has changed direction or users have asked for something new. Why subject 95% of the team to hour long monologues?
I don't think that's the case for most of the substantial software projects. The plan for the Linux kernel doesn't change each week (do they have "PMs"?).
15% seems very excessive. Almost a whole day a week and two days lost of deep work. Try to aim for 1.5%. Do as much of the planning as possible without a meeting.
I don’t know how you can get a team of developers to productively spend 39 hours and 24 minutes of keyboard time productively coding in the same direction with only 36 minutes of discussion.
That works great in FAANG companies, you might have 1-3 hours of meetings in total a week. That is how your typical PhD program works too, meet with your supervisor once a week. And low meeting culture seems to work just fine for the Linux kernel developers too. You're always free to engage in extracurricular activities, but it's not mandatory.
It's the lesser tier, often non-tech companies doing this kind of micromanagement.
> isn't interacting with customers frequently enough to upend their plans every 1-2 weeks.
As I said, re-planning is more often than not needed because of technical challenges developers are running into. If one person is going to take 4 weeks to deliver something instead of the expected 2 days, lots of things may have to be rejiggered.
But also, yes even "real product driven company with a mature products" are changing plans every 1-2 weeks. Because each new incremental feature is a little project of its own. I never said plans get "upended" but they absolutely need to get re-adjusted ever 1-2 weeks based on both dev input and product/user reaction.
If you want to talk about the iPhone, just look up the history of how the software keyboard was developed. Talk about rapid prototyping and upending plans!
They absolutely plan where they want to be in 3-6 months -- they're generally quarterly OKR's -- but the only way they consistently achieve their targets is with weekly or biweekly readjustments.
They do, and if you need to adjust a project you don't need 10 hours of weekly planning meetings (the Linux kernel developers don't need it, so your CRUD app developers don't either).
The higher you go, the less agile it gets, because that's a horrible way to develop software, or any high-skill professional service or product.
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.
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.
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.
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.
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.
15% every week is the problem here. If you spend 10% of your annual budget on upfront planning and 5% monthly on checkins, that's maybe ok. Putting the whole team in a room every week is just going to churn the plan constantly - inputs likely aren't changing with that frequency, and you aren't going to be able to pull in all the other stakeholders that often anyway