Favorited How Big Tech Runs Tech Projects and the Curious Absence of Scrum by Gergely Orosz
I see scrum used at different levels of quality in different settings, and especially where the focus shifts from delivery to the rituals around enabling the delivery it becomes a drag quickly. Then there’s the ever increasing backlogs and the partial implementation where scrum delivery collides with the rest of an organisation not being ready to pick up on what’s delivered. (HT to Alper Çuğun for surfacing the link in his rss feed)
The success of companies and project management approaches is not always correlated and this story is a reminder of this…..the organizational structure of Big Tech greatly impacts how teams can – and do – execute. …. When talking to engineers at Facebook, Whatsapp, Google, Netflix and similar organizations, most of them have never used Scrum. Should companies dismiss Scrum and other methodologies just because most of Big Tech has done so? … There are many contexts in which switching to Scrum makes perfect sense
Gergely Orosz
Gergely Orosz’ How Big Tech Runs Tech Projects and the Curious Absence of Scrum (via Ton Zijlstra) poses some really interesting questions. He recently ran a survey asking 100 big and small tech companies how they run things—what their development/release method was like. Consultancy companies still (desperately?) cling onto Scrum as the Holy Grail, while the majority of Big Tech companies (Microsoft, Google, Facebook, etc) answer with “it varies”. What’s up with that?
They simply let the team decide.
Many of those Big Tech teams are portrayed like Dream Teams where everything moves at a staggering pace and product changes are rolled out of the door multiple times a day—sometimes hidden behind feature switches as not to set things on fire too soon. Gergely’s article does include a big but footnote, although it’s pushed into a corner: self-organization only works if teams already are well-oiled machines.
In my experience, 90% of the times, they’re not.
As for the reason not to choose for Scrum: because it’s a traditionally heavyweight champion to tackle big bald projects that knocked the waterfall method out of the park—and has become just as slow since. Many of the traditions that come with it (meeting 1, meeting 2, decision 3, artifact 4) bog down the team and the decision process, up to a point that apparently Big Tech talks about Product Managers instead of Project Managers now. Product Owners, a staple in the Scrum world, are shoved aside.
In-between all those exuberant and wordy job titles, it becomes hard to discern the forest for the trees. In all honesty, I can’t make out a difference between the PM and the PM—whether the P stands for Product or Project is simply beyond me. What we do know, according to Gergely’s survey, is this:
All right, so project managers suck, but product managers don’t? Most of the times? The managing part still troubles me, and ditching or keeping Scrum is beyond the point here. Of course we engineers don’t like to be micro-managed. But most scrum-oriented companies I’ve worked in applied several layers of managerial bullshit (see bullshit jobs) that likely won’t go away if Scrum is dropped. Most Big Tech teams still adhere to some kind of stand-up and still occasionally perform retrospectives. What a relief—without a synchronizing information and status update mechanic, a team will likely dissolve into a simple set of individuals.
So what does the absence of Scrum mean? I think it simply means the team has matured and adopted its own mechanics to cope with and produce rapid changes. Most teams I’ve been in had to be formed, meaning people didn’t know how to work together and how to split up big problems into small tasks. Then, Scrum is a handy tool to grab onto: it’s well-known and flexible enough to adapt to your own needs. Call it Scrum, Kanban, Scrumban, Kaizen, whatever—the essence is: if you don’t know how, you need a way to organize work.
Speaking of organizing things: large bug and feature tracking systems like JIRA seem to be universally hated:
While I love the fact that Gergely’s surveys reach quite a lot of people (consistently 50 to 100), note the all 13 here. This ain’t no quantitative science. Its results are interesting, can provide useful insights, but are not in any way significant.
Also, Gergely (or his interviewees) remain silent on the alternatives. We’ve used Redmine, Basecamp, Social Text, JIRA, Google’s whole suite, … And I hated every one of them. I did not hate the software: I hated what the software stood for. I’m curios to see how Big Tech handles that. The article mentions almost all teams still employ some form of backlog tracking.
You know what else is a waste of time? Time registration tools. Inhales deeply to counter gag reflexes. I’d gladly attend Scrum Planning meetings every two weeks just to get rid of that.
I am 100% convinced that the results of that survey would have been radically different if taken here in Belgium and surroundings. Many friends still work in the industry and every time I speak to them, they are again helping some governmental agency set up their Continuous Integration/Deployment system. They are again teaching people how to write a simple unit test. They are again showing teams how to work together. Again. I love complaining about weird and cryptic rituals I have to cope with nowadays in academia. But these conversations remind me that in industry, we’re still stuck in the same Here’s how to do things-loop. So, naturally, simply letting the team decide on how to organize would result in utter anarchy. Hence the persistent popularity of Scrum.
Few teams are as good and cool as many American popular blogging software engineers make us think. If only things were that simple.