The promise of "agile" is, IIRC, faster turnaround and iterative development. Yes, the 'wrong' thing is expensive. Getting something basic in someone's hands in 2-3 days to get some feedback is usually more productive than days of figma then 'sign off' then work work work then putting it in hands and getting back "this is wrong" (missing data, etc). Sometimes those things can be found in 'design-only' sessions, but I've rarely seen it happen where lots is found there, then things are implemented perfectly afterwards not requiring any further changes.
Much depends on the size/scope of the work, and I don't think there's one-size that fits all, but the ticketization of work process as teams grow pushes towards "one true way", which then seems to paper over a lot of cracks that don't easily show up in burndown charts.
That 15 or 30% might be the time ultimately taken on thinking/planning/etc of a specific issue, but too often it seems there's an idea of doing more up front "gets it done" and the notion of fast feedback/iteration cycles is glossed over, and you're expected to "get it done" - "all the planning was already done".
When doing dev-type work, I always end up needing to iterate with endusers/stakeholders, and there's little 'up front' that could have been planned to avoid some of that. It may be the nature of the people/teams I've worked with, though.
The more people in the room, the fewer participate, the fewer decisions get made, the more gets punted to the next time 20 people are in the room again in 3 days.
The promise of agile is working software.
Iterative development is a how, not a what.
i understand your point, but also think 'agile' is at least as much of a 'how' as much as a 'what', especially over the last 5 years or so.
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
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.
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.
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?
15% seems very excessive. Almost a whole day a week and two days lost of deep work. Try to aim for 1.5%.
How do people think Apple develops completely new product lines like the iPhone, iPad, watch, etc.
There's a lot more up front planning (and yes .. of course, course corrections) than a lot of agile advocates want to admit.
Most agile hyped up senior management I've met just use it as an excuse to be derelict in their ability to plan anything.
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.
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.
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.
It's the lesser tier, often non-tech companies doing this kind of micromanagement.
It’s an option, I guess… let us know how it works out for you.
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.
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.
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.
How much value do you get from putting 20 engineers in a conference room for 2 hours, 2-3 times per week? What if this is mostly just a head strong manager who enjoy monologuing his captive audience team?
Note I said "spent 30% of our time talking at high level management view about doing work rather than just technically planning & doing it" This doesn't really help prevent building things that don't fit together at all. It barely allows you to surface technical dependencies and order of operations.
Keep in mind that in most "jira-oriented" places (or probably all of them), that task isn't attributed to developers at all.
If you are doing this and development, like a healthy place, yes, 30% of the time evaluating your work sounds sane. But that evaluation time must not be interleaved with development time at all. Any interleaving will destroy the value of both tasks.
But in companies that are good at engineering management, you will often find:
- weekly planning sessions
- daily standups
- work ticketing and backlog systems (sometimes Atlassian ones!)
- prioritization discussions
So I would suggest that anyone who assumes that those activities correlate with bad engineering management, is falling into a base rate fallacy.
P(is badly managed | Jira) is high, but that’s because P(is badly managed | tech company) is high.
But.
How much time should a team be spending figuring out what the right thing to do is? Figuring out if the plan is still the right one?
15% honestly doesn’t sound like a number I would automatically assume is ‘too much’ for such activity. I’m not sure even 30% sounds like a crazy high number. Building the wrong thing is expensive. Building pieces that don’t fit together is expensive. Avoiding those mistakes requires investing time in some sort of planning activity.
It doesn’t have to be Jira backlog grooming, sure. But it has to happen.
If the developers aren’t spending their time doing this, who is?