Classic. And when you tell incompetent management that 9 women can't deliver a baby in a month, they'll proceed to try with 10 women.

That analogy understates it. Starting a big fresh project with an idling “team” is really inefficient because the TL needs to figure out how to keep everyone busy.

The better way is to have a smaller number of people work on requirements and figuring stuff out before a whole team lets rip. Some tasks just don’t parallelise well so a 9 person team isn’t good for everything.

I like this idea of a smaller team feeding work to the bigger team. What does such a smaller team look like? What kind of roles, etc?

Just take 30 in another country, ideally with 12 hours timezone difference.

Mandatory 10pm phone calls too.

You have done this? That sounds bad.

Yeah, when I worked for Microsoft it was pretty common.

This is so common it hurts.

I wonder where this comes from. Is it just hubris mixed with incompetence?

This happens when managers think of themselves as the engineering division and the sole isolated source of value while viewing engineers as cost associated with delivery. The proposal PowerPoint is the product and the actual product is a Proof-of-Work that could retroactively nullify pre-realized values.

Wow! This is truly the best explanation of this I’ve ever heard. It explains a lot that I’ve seen.

Mixed with desperation and ignorance. Managers only have so many levers they can push to course correct a situation.

But, it take hubris and incompetence to get there.

So explain it properly.

"9 WOMEN CAN'T DELIVER A BABY IN A MONTH"

So how many women do we need, like 15? Maybe a Scrum master who knows the Lamaze method?

We should setup three day workshop about it. And of course invite no women to it.

only pregnant men, we are dedicated to diversity at this company

If you hire enough women, one of them will produce a baby within a month.

See, we just need that 9x dev.

Once they've shown they can do it once it's perfectly reasonable to bet the entire business on them doing it the next month.

Oh, and also, the diversity team have noticed we have hired a lot of young people so we're only hiring over-50s this year.

> Once they've shown they can do it once it's perfectly reasonable to bet the entire business on them doing it the next month.

That's true. A team of 20 women can easily produce one baby a month.

Nine women can't, but the people who like to say "nine women can't produce a baby in a month" are almost never trying to tell you that you can fix your problem by expanding your team to the appropriate size.

Acquiring the competitor is a valid strategy but you need both money and a competitor.

There is no doubt Scrum is the answer here. We should also use story points. Then it can't fail.

Fred Brooks encountered a similar problem as a project manager at IBM in the early 1960s, working on the software for the System/360. In 1975 he wrote The Mythical Man Month about the experience. He said "adding manpower to a late software project makes it later". The increased communication needed was one reason. About half a century later, most businesses have still not learned these lessons.

I once on a company where a CEO did that 3 times in a row to an engineering team, and mentioned wanting that team to be 4x its current size in two years. In an interview, he mentioned The Mythical Man Month as one of his favourite books.

Everyone perceives things through their perspective. Dopey CEO guy sees himself as the surgeon leading the software “surgical” team described by Brooks.

Just like there's a bunch of politicians complaining about 1984 who clearly have never opened "1984" too.

Those hundreds of millions of VC money have to be put to use. So it either advertising or more head count.

so they just hope company suffer

I find myself quoting the mythical man month to various poeple at least 2-3 times a week. Unfortunately no one is familiar with it (obviously) or seems to understand the point.

The other day I had PM complaining how they were going to keep their team (which has somehow grown to 10 devs!) busy after the highly sequential work was blocked by a dependency on another team...

...and who was it that failed at the outset to factor out that dependency into a clean,well-defined interface ?

That would have allowed modules/components to operate independently ,reved on different schedules, and more, but evidently too much thought at the outset ,so they just didn't even bring it up ,or passed on the opportunity if it was brought up.

They think they can't spend the resources to get it right, but they'll magically have more resources to fix the problems.

Now everyone pays.

The micro service hype appeals to managers precisely because it is a technical implementation of an organizatoral solution.

I guess I should have been more clear, as I'm not talking about microservices, but an architecture I implemented before that hype.

It was to partition the app into at least the primary segments that did different functions and had different behaviors, system resource load profiles, etc., and then mandate that those all run on separate machines (this was before everything was cloud-based), and that the relationship to entities was not 1:1. Defined clean interfaces up front. The primary goal was to be able to scale very rapidly for any big customer and/or upon discovering a scalability issue by temporarily throwing hardware at the problem, and secondarily to allow teams to rev different portions of the system on different schedules.

Both worked great, and it wasn't long before we were taking major customers away from competitors because they had scalability issues and we didn't. I'm in R&D and manufacturing now, but see no reason that this approach of fundamental modularity should not be relevant. Heck, I find high modularity to be a good approach relevant to designing industrial processes, or just setting up a shop... just keep everybody's fingers in their own pies, make the organization implement the best architecture, not make your architecture implement your org chart.

I'll be the one who gets blamed for that, but not how to do so without well defined and properly verified requirements.

(see point about about the not understanding what is being built and constantly changing the scope)

but why learn anything when you can hire a kanban/PMP/Kanzai/6 sigma/SaF or whatever is the latest BOTD (not forgetting CMMI and ITIL - the masters of vapid BS that goes nowhere)

I've tried and failed many times to get my boss to understand this.

"start throwing bodies at the problem."

and to save money they hire some newbies instead of experienced people. I have had it multiple times where the project got looded with people who had no experience or they were in India 12 hours away so onboarding was really hard. the result was always that the added people slowed the project down.

It's funny how the Mythical Man-Month is nearly 50 years old and yet its lessons go unlearned so often.

>8hr "planning" sessions

One place I was at had quarterly 3 day planning sessions. That was something else.

Wait that actually sounds awesome. What we’re your issues with this practice? A 3 day code freeze while everyone works to solidify a “meeting of the minds” followed by 87 days of heads down progress sounds like fucking heaven to me compared to the weekly planning meetings on top of daily stands up I live with now.

pros and cons, will depend on the type of thing a team/company is working on. I've been on the receiving end of this with some negative experiences as well.

Team1: "Hey, we've launched a new initiative a few weeks back. Important for us to be able to add one field to the response of your internal billing API. Can we discuss what that would take?"

Team2: "Hey, probably a few hours of work. But, we just had our quarterly planning last week. In 12 weeks you can submit for Q2, and _maybe_ we will plan it somewhere in May or June."

This 87/3 split sounds suspiciously like what Agile with frequent checkpoints was supposed to mitigate.

… and it mostly failed by burning out everyone with the daily routine.

But if you prefer the 87/3 split to Agile with frequent checkpoints is it really a mitigation?

SAFe (as I've seen it) has a two day planning event every 10 weeks.

Plus a planning every sprint and daily stand ups.

sigh

We had weekly planning and "triage" meetings too. This was on top of the normal stuff. It wasn't all heads down either. If you finished your tickets before the next planning meeting you could relax, edit the wiki, look for stuff to write new tickets for etc.

I worked on one team that had a one week planning period every two weeks. The planning week, for us regular devs, was “do whatever you want” and it was epic. There were basically no bugs because a few of us liked tackling bugs for fun. Other people worked on optimization problems and code hygiene.

For the people doing planning, they were always busy playing ticket shuffle, asking random devs random questions all the time. But those two weeks was cray and anything not done by the end of the sprint had to be done by the end of the planning period, and you better have a good reason.

SAFe?

Scaled Agile Framework.