How big tech runs tech projects and the curious absence of Scrum

The thing about Scrum is the observations and principles make sense, but then to sell it as a course they&#x27;ve turned it into very specific prescriptions.<p>I went on a scrum course and the takeaway was basically that feedback is a big deal, and you should try to get some repeatedly and quickly. It&#x27;s also common sense that you should have tasks written down somewhere, and that some of them are more important than others.<p>You certainly need to think about how long tasks will take, but there&#x27;s no reason why you need to do planning poker, that just seems to be one among many ways to think about how long something might take. Tracking velocity is another one of these things that seems replaceable.<p>If you have a team of people that more or less adheres to a few principles, there&#x27;s no reason you can&#x27;t get things done.

&gt; Engineers are encouraged to interact with the rest of the business and build relationships with non-engineers. In contrast, traditional companies often make it impossible for developers to interact with the rest of the business.<p>In my experience “traditional companies” will often have a bunch of people in cushy “gatekeeping“ jobs whose main function is basically forwarding emails back and forth between devs and the business. If you try to get direct access to the business usually the business is quite happy but the gatekeepers get very upset.

I really want to say this: SAFe is an awful process and a trend that will hopefully go the way of Unified Process&#x2F;RUP. I won&#x27;t go into it, but it&#x27;s largely created and popularized by a vendor to sell their software. It is poison and exists to keep its practitioners employed. It attracts the highest-ego PMs like moths.<p>I find it interesting that they author references Skype circa 2012. It sounds like classic &quot;uppercase A&quot; agile: they reframe success as shipping and hitting other invented agile milestones, while masking shipping lousy and incomplete product that is not succeeding in the market. That was right around the time Skype started being bad. It may succeed on some metrics because MSFT started bundling it, but anyone that actively used it at that time should know what I mean.<p>The idea of an &quot;agile enterprise&quot; is intrinsically absurd. Teams are agile, not companies, and teams and products should be loosely coupled. That&#x27;s why the big tech companies in this link have converged to similar answers to this problem (they are not &quot;agile enterprises&quot; but give teams some latitude to solve their own problems, and rather focus on results). Kanban is better in most ways for most teams.<p>Also, Tuckman is a silly model that is only popular because it rhymes.<p>PS: <i>Strawberry-Jam-O-Meter and a Wrong-Order-O-Meter</i> and their descriptions could hardly be more cringe inducing. Skype should be a part of the curriculum looking at less than ideal acquisitions and post-acquisition execution. <a href="https:&#x2F;&#x2F;www.wired.co.uk&#x2F;article&#x2F;skype-coronavirus-pandemic" rel="nofollow">https:&#x2F;&#x2F;www.wired.co.uk&#x2F;article&#x2F;skype-coronavirus-pandemic</a> has is a reasonable overview if you&#x27;re not familiar. They lost the consumer market and failed at enterprise (see Teams) and Teams in turn essentially failed in the general market- where most places that were free to do so went with Slack.

My sole experience in Big Tech consists of Facebook and the post more or less matches what I saw there. It seems to me, though, that the author views &quot;no process&quot; from a very positive lens, with no discussion of negatives. Like how at FB so many teams use spreadsheets to track their work (sometimes multiple spreadsheets per team, sometimes no tracking at all). There is some internal tooling, which is quite basic and at the time I was there it got deprecated without the replacement being finished yet. Whatever you say about JIRA, it can handle complex projects way better than a spreadsheet.<p>My biggest issue with the whole thing, however, boiled down to the set of incentives that centered around individual performance. You see, the teams weren&#x27;t _teams_ per se, but a collection of individuals working on their own projects, sometimes related to those of other teammates, sometimes not. A team-oriented process like Scrum or Kanban cannot survive in an environment where every person is optimizing every decision for their advancement&#x2F;bonus&#x2F;whatever. There&#x27;s some exaggeration here, but I definitely saw a lot of this at FB. Having come from a company with high-functioning Scrum and Kanban teams that worked together to achieve a common goal, I&#x27;d choose that any day, JIRA or not.<p>This is obviously a single example and many of the issues were Facebook-specific. But I bet there are other, not so positive, sides to the &quot;no process&quot; story at the rest of the companies.<p>Note I&#x27;m not claiming that the Agile processes are by definition good. I&#x27;ve seen plenty of bad implementations as well. At the end of the day, every group of humans is different and may require a different process (or no process at all) to maximize their success. What I&#x27;m suspicious of is the &quot;every team picks their own process&quot; claim, having seen company-set norms exerting enough force to make deviations from the common pattern rather painful and counter-cultural.

At Shopify, we tend to do whatever our engineers want in this regard. My team meets weekly and looks at a kanban project board. If we need to adjust, we have retros, etc and change the process. We have the autonomy.<p>In a past life you would be told Agile meant “self organizing teams”. But in practice that was only allowed in a narrow definition of change under the prescribed process being foisted on teams from above.<p>IMO while you need some consistency to get alignment on goals at a high level and coarse quarter-level goals, at the team level you can more or less let the team decide and then judge them on their effectiveness.<p>Odd how so many companies want to do “what [successful tech co] does”. Yet those companies innovate their own processes.

I was there when Agile was invented. In my opinion, Scrum has always been the worst embodiment of a good idea.<p>In terms of content, teams of experienced developers have always worked in the spirit of Agile (of course there are exceptions). This informal understanding was and is superior to a formal horizontal Scrum implementation. For example, it preserves seniority and true accountability - two things that Scrum pretty systematically destroys in my experience. Initially, I was hoping for additional solutions to problems in the vertical direction - management, customer relations, etc.... But that never materialized, at least in my environment. And since I&#x27;ve been in the industry for more than 20 years, that&#x27;s not too little.<p>These days, mandatory Scrum is a contra-indicator for any project that crosses my path as a freelancer.

Reading this, I&#x27;m struck by a thought: Are we the bad guys?<p>According to the article, what the big tech companies have in common is engineer-led products. It&#x27;s not the besuited MBA&#x27;s making product decisions, it&#x27;s us, the engineers.<p>And the big tech companies are also united in having evil products. With the possible exception of Shopify and Datadog, every company on that list of &quot;big tech&quot; is doing things that actively harm society.<p>Cue the &quot;are we the baddies?&quot; meme [0]. If engineers are left to build products by ourselves, do we build things because we can and not because we should?<p>[0] from <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=uK-kWRAVmRU" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=uK-kWRAVmRU</a>

From a management perspective, having everything reduced to a process and method is the ideal world, as no true knowledge about the actual work is needed. The weaker then understanding of the work, the stronger the desire to replace uncertainty with process.<p>However, no process can remove actual randomness (did anyone get the necessary ideas, for example) or uncertainty (is it even feasible, for instance).<p>That said, in larger - and I&#x27;d say mostly non-software companies - changing processes to things that are more inclusive, i.e. tech and the business talking directly to each other does help. And one way to sell that is under an agile&#x2F;Scrum kind of construct. To me, seeing Scrum then more in non-tech&#x2F;consultancy makes total sense.

If Skype is an example of Scrum done well, perhaps that explains why Skype has been very unreliable from and end user perspective for 5+ years... the kind of unreliable where more than half of the outgoing calls are met with instant &quot;So-and-so-contact is not available.&quot; responses [edit, added: failure responses so quick that you know the contact was never called, and the problem was within your client app or the Skype systems. Different computers in different locations behaved the same.]<p>Maybe they were missing what I noticed missing from my last Scrum-focused company: view and attention from the higher altitudes.<p>Scrum makes it easy to break down features and problems into nice little pieces which can be done within one sprint (often in one day). That is a win in many ways, but it doesn&#x27;t encourage higher level reviews, refactoring, etc. It&#x27;s the problem of not seeing the forest for the trees.<p>Of course you can intentionally create epics for these kinds of reviews, but those don&#x27;t have a good short-term return value for time spent. And so, they get inadvertently or intentionally postponed. Eventually the system is complex and messy, few people understand the system in entirety, and the easiest Scrummy solution is a re-write.<p>For me, Scrum was a straightjacket, a hundred NOs against my creativity and my attention to broader concerns. There are times when you are implementing a simple ticket, but you keep touching things that need attention... or you see how the entire system has become convoluted, and you see a better way. To do it the right way either means creating new epics and tickets, debating those with product owners who don&#x27;t understand the value, and generally NOT solving the real problem.

Minor side note: My current employer has been pushing SAFe hard (training for everyone, etc.) recently. As a result (and I do mean &quot;as a result&quot;) about 3&#x2F;4ths of the senior technical people have resigned in the last three months. This is at a &quot;Large, non-tech enterprise&quot; (sort of; it&#x27;s an engineery chunk of the federal government).<p>Now back to a personal opinion: Most &quot;software engineering&quot; &quot;methodologies&quot; are intended to appear productive without actually <i>requiring</i> productivity. Or, as I sometimes put it, &quot;software engineering is about making people who are fundamentally not very good at writing code look as if they were producing code.&quot; Look at the number of managers, leads, coaches, trainers, and consultants required for every methodology and compare that with the number of such &quot;overhead&quot; positions in, say, open-source projects. (Note: I&#x27;m not trying to start a &quot;which is better&quot; discussion; open-source is just a convenient example since their development techniques are transparent, unlike everyone else&#x27;s.)<p>Further, many medium- and large-scale initiatives in large, non-tech enterprises fail spectacularly, in spite of using the then-popular methodologies. I would go further and suggest that they <i>all</i> fail at some point, even if they eventually deliver a usable product.<p>The only solid generalization I can see is that good developers can develop good software with any (or no) methodology; poor developers cannot, and most formal methodologies are built around trying to get them to do so.

Usually in interviews I check if they use Jira in their day to day process. If they do, I don&#x27;t join that company.

One pet peeve of mine: people often say they run a &quot;lightweight&quot; version of some project management philosophy and end up paying the costs of it without the benefits. For example lightweight agile scrum meaning sprints, but no retros and work constantly coming into and out of a sprint.

As someone who currently works at a Big Tech company, but spent most of his career prior to that at smaller companies, I found this article very confusing.<p>First of all, I work at Amazon (and posting this under our social media policy, this is just my experience, and I don&#x27;t speak for the company), and Scrum is pervasive at Amazon. The article is right that many big projects start with a 6 pager, but once teams start executing, many teams run some form of Scrum (Kanban is also popular).<p>The second thing I found strange in this article was the idea of Scrum being heavy-weight. Early in my career I worked at a small company where our process guru was a big fan of the Unified Process. The point of Scrum is that it is lightweight (without being zero process). There really isn&#x27;t a lot to it. You sync with your teammates daily, to make sure you&#x27;re all focused on the most important thing today. You check in every 1-4 weeks by (a) demoing your software to figure out where you are, (b) you do a retrospective to look at what can be done better, (c) you figure out what is the most important thing to be doing the next N weeks. The teams that I&#x27;ve been on that have tried to <i>not</i> do these things either in actuality, did these things, but did them subconsciously, and therefore unintentionally. When I hear people say &quot;Oh, I don&#x27;t like Scrum because my old team did Scrum and I didn&#x27;t like how we...&quot; what follows is almost inevitably something that if you asked a professional scrum coach &quot;Should we do that?&quot; the answer would be no.<p>&gt; Competent, autonomous people need less structure to produce reliable, high-quality output. Big Tech is able to attract, afford and hire these people.<p>I don&#x27;t like this way of thinking. Start-ups have lots of competent, autonomous people. Big Tech companies have lots of people early in their careers that are still learning to be autonomous. In fact, when I was at start-ups I often heard the opposite (and equally untrue) claim: that start-ups required people with more autonomy, because the product is new and the team is involved in discovering the product, whereas in larger companies the products are more defined, so people needed less autonomy.<p>I appreciate the author surveying people and trying to make sense of the results, but in this case I think he just over-simplified a much more complex reality in a way that isn&#x27;t particularly helpful.

There’s this image that big tech teams build software where everything is automated and has 100% test coverage and all the infrastructure heals itself and all teams are hyper efficient. It’s not really true, the biggest shared practice between big tech is letting the team’s manager pick whatever methodology works best for them.<p>The big tech version of scrum is just sprints, stand ups and shipping often. There’s still a waterfall process, mounting technical debt, huge backlogs where everything is high priority, and over committing to slipping deadlines.<p>I think people should think twice before looking at big tech as the place to learn good management practices from.

Just to be the old grouchy guy, I can&#x27;t say that any of the modern processes sound like any fun. 90% of the time I&#x27;ve run into them it was basically a way for external consultants to make a pile of cash (and for an internal champion to work without doing work), the other 10% it slowed down development to a series of small changes.<p>Perhaps it&#x27;s just a difference in the scope and type of projects (boutique hardware vs. large scale online stuff).<p>Looking back at old codebases that I kept around, we managed to build quite complicated largish systems in a reasonable amount of time using straight waterfall&#x2F;ad hoc approaches. Simple source control. Simple spreadsheets for bug lists.<p>Admittedly it&#x27;s hard to avoid attaching particular people to particular blocks of a system, so perhaps making development capable of absorbing random Engineering Resource Units (humans) is the point of all this.<p>..or maybe it&#x27;s just that earlier generations of programmers were stupid. I can accept that.

&gt; Many teams work on main branches, get quick feedback from CI&#x2F;CD systems and can immediately share functionality which they are working on with other team members.<p>I occasionally see statements like this floating around - does he mean:<p>* Devs make their changes locally, commit and push directly to main, and then the CI&#x2F;CD either notifies them that tests failed or deploys to prod<p>or<p>* Devs make their changes locally, commit and push on a branch, and rapidly (ideally automatically) merge to main if tests pass. This happens on a cycle of minimum coherent set of code changes, not a whole feature at a time or anything like that.<p>The first seems like it would be very frustrating if code with failing tests if pushed with any frequency, but seems to be literally what the phase &quot;work on main&quot; means. I also don&#x27;t really see a drawback to the second one in comparison.

One of the bests parts about working at a faang is we don&#x27;t do scrum or stand ups. Everyone shares timelines ahead of a project, and they run with the execution, flag if there are any blockers or need help. Saves so much time without the extra overhead.

My theory is that in tech companies top management usually understands how tech development works and have respect for their workers.<p>At my company top management often comes from a sales or medical background and you can clearly see that in how they treat sales people and medical people. They get promoted more and receive way more attention from management because they understand each other.<p>IT and software are a big, scary mystery to management so they are prone to take advice from snake oil salespeople, consultants, or middle managers who tell them what they want to hear.<p>I think in general I think you are better off in companies where the output of your work is the product and top management understands and respects your work. Better to be viewed as someone who contributes to the profits of the company and not just as a cost center.

I don&#x27;t quite understand the &quot;lack of Scrum in large companies&quot; when they all seem to Plan-Ship-Build. That is pretty much the high level description of Scrum isn&#x27;t it?<p>Sure Scrum has some ceremonies, but these are basically planning and retrospective for improvements, so again, not really any different.<p>At the end of the day, most of the ways I have worked end up with Tickets&#x2F;PBIs&#x2F;Stories and you work through them. The only major difference is how much in-advance these are specified and to what detail.

Of the weekly &quot;Scrum sucks&quot; posts we see on HN, this was by far the most articulate and well-reasoned. I&#x27;ve spent most of my career in consulting or kitchen sink teams. Having Scrum or a Scrum-like process is simply mandatory because we are working with disparate stakeholders against constrained budgets with a team who are not dedicated to the domain we&#x27;re working in. Getting a high degree of specificity into requirements in the smallest increments is life-saving. Over reliance on rituals is typically only necessary for a really immature team (which I have been part of in the past) but the core elements of backlog management are really valuable. Not just for developer efficiency, but for visibility on progress and priorities.<p>All that being said, I can easily see how a dedicated team with a very clear product strategy iterating on a hugely successful business model can just roll along without a lot of oversight. I&#x27;d still be a bit surprised that anyone working on a customer-facing product isn&#x27;t running their design decisions through product experts. Idk what that world is like, but I&#x27;ve spent a lot of energy duking out product debates where nobody is really sure how a feature should work or it&#x27;s even beneficial and developers usually have the worst instincts.

So the key takeaway here is that the Plan, build(iterate), ship cycle works very well. Most successful teams stick to this. What is not clear to me is how an abrupt new feature with an urgent deadline fits into all this ? &quot;We&#x27;ll fit this into the next release cycle&quot; is not an option, let&#x27;s say.<p>So how do you fit in this new requirement ? You are already in the middle of a feature built on day 3 or 4. Devs are working on their forks and have uncommitted code. Now you have a new feature that has to be given priority, assuming there are no dependencies on the existing cycle. Do you just keep a copy of your old work, and start working on this new stuff ? Feels like a mess. Any better approaches ?

I think the core observation that teams are best allowed to adapt to their own situation is a good one. One thing I want to take on though is this:<p>&gt; “Kitchen sink teams” which have everything thrown at them, typically find that managing stakeholders with a heavyweight process like Scrum is a win. Stakeholders are educated to understand that an ongoing sprint cannot be interrupted and that new feature requests need to be groomed.<p>I have <i>repeatedly</i> see teams that run like this fail. They&#x27;re happy in their own right, they&#x27;ve got their process, they get what is in front of them done, but the process makes them entirely unable (actually more often just unwilling) to respond to urgent issues or adapt to a changing environment.<p>It&#x27;s absolutely great for a team that has a large number of external stakeholders with diverse needs to be able to point at some process and say &quot;Oh well here&#x27;s the process we follow, here&#x27;s what you need to do&quot;. But in reality what they&#x27;re saying is &quot;We&#x27;re entirely unable to respond to the actual requirements of our stakeholders, so instead we&#x27;ve decided there are only a subset of requirements we&#x27;re going to fulfill&quot; and anything outside those requirements you just have to work around the team. It very often also works to provide barriers between the stakeholder and the engineer, so by the time they tackle they&#x27;re either doing the wrong thing, or it&#x27;s no longer needed or they fail to actually deliver it <i>to</i> the stakeholder. It&#x27;s a great system to build a well functioning team that entirely fails to deliver what the larger organisation needs. &#x2F;rant over I guess

At our company, We believe that the way you get to the objectives and result is immaterial. Some teams that are very IC driven, will not care about the process and but will be jet focussed on result. Some teams need structure, some don&#x27;t. Enforcing same process on all the teams is kind of shackling, what ends up happening is that teams do process for the sake of it. Our teams have occasional alignment calls, team and individual OKRs, company objectives are the key indicators for the manager to see if the we are on track or not.

My tinfoil hat theory is that Scrum was invented by Big Tech to hobble potential future competitors.

I somehow feel something important is not being discussed, and that is competency. Perhaps in Silicon Valley it is normal that engineers take ownership and are smart enough to figure out what is valuable and what is not, but I can assure you that in an average Fortune 500 company this is not the case. In my experience a lot of engineers in these companies don&#x27;t care about engaging without customers, like to complain about a management and take little responsibility.<p>You need to have rules (however dumb you might find them), you even need babysitters. There&#x27;s no going around that. Someone making 1&#x2F;4h of what a SV engineer makes is highly likely to be less competent.

I worked at a big tech for many years and my team never managed to get Scrum working properly. Every year my team commits a delivering certain product&#x2F;features at a very specific date (some sort of launch event), so we have to know very early in the year what&#x27;s all the work required and report periodically whether project is on track. The deadlines are also always on the tighter end. The flexibility of Scrum becomes an issue in that case, because not everyone can deliver the same tasks at the same speed and without careful planning you can easily miss important deadlines.

This item stands out as one of the most important aspects that is either unknown or ignored in companies. The amount of information a person has access to drastically alters their ability to make informed decisions.<p>&quot;Exposure to the business and to business metrics. Engineers are encouraged to interact with the rest of the business and build relationships with non-engineers. In contrast, traditional companies often make it impossible for developers to interact with the rest of the business.&quot;

&gt; It measured a Net Promoter Score (NPS) of -83. This is staggeringly low, and means that 83% of engineers would advise against JIRA<p>No, that&#x27;s not at all what it means. Another person who does not understand the bullshit that is NPS. NPS treats people rating at the lowest of the scale just like people rating at the middle of the scale, which is patently ridiculous.

The way we do things at Gordian is similar in a lot of way to the Big Tech methods but it stands out in a pretty unique way IMO.<p>The approach is described here <a href="https:&#x2F;&#x2F;www.gordiansoftware.com&#x2F;news&#x2F;two-weeks-too-slow" rel="nofollow">https:&#x2F;&#x2F;www.gordiansoftware.com&#x2F;news&#x2F;two-weeks-too-slow</a> and in practice it’s even better than anything I was hoping for. I can legitimately say this is the most productive environment I’ve ever seen.

I don&#x27;t get Jira hate. It may be clunky, slow and overcomplicated but really it&#x27;s just system to document stuff. If you don&#x27;t document stuff on a sufficiently big project (I&#x27;d day &gt;10 engineers, and especially at &gt;100) then it&#x27;s a recipe for a disaster.<p>As for solutions to document stuff, specifically issues, then Jira seems to be ok and not lacking in any area, maybe not a leader but not a worst thing to use too.

Scrum is merely a batch oriented process. In (process) control theory there is over 100 years of study of batch, continuous flow (e.g. Kanban or Lean), and other types of processes.<p>Each has benefits and tradeoffs. Like all tools the proper process type for your project will be context sensitive.<p>For an industry so full of smart, supposedly logical, people ours is still quite immature and tribal in its management theory.

The initial comparison - WhatsApp (18 employees) vs Skype (hundreds? thousands) is not a comparison of Project Management systems but a great example of the Clay Christensen Innovators Dilemma - Skype got killed by a mobile only, E2E encrypted competitor.<p>I think the big takeaway is &quot;dont worry about your project managment system if you are playing the wrong game.&quot;

Not surprising that scrum works best for consultancies -- Scrum has just as much to say for how engineers should behave as it has to say about the people paying for the project should behave, and how to pretend to be that person when they seemingly abandon their duties.<p>The sprint is also a product of its time. A methodology for shipping new features on a monthly basis is great when your competitor is shipping Excel on an annual basis. But the shorter the turnaround time for a feature, the less use there is in planning timelines.<p>This is why the big tech companies don&#x27;t have a unified process -- the process that works best for shipping operating systems is different than the one that works for shipping a mobile app, is different than the one that works for shipping a webapp. Any program office that tries to smooth out these wrinkles is hazardous to their wealth.

Kudos to the author for gathering some data and sharing their conclusions. I encourage you all to take a look at the survey responses though. I know Scrum and Agile bashing is fun and all, but we&#x27;re drawing some pretty big conclusions from just over 100 responses. And while the focus of this seems to be pitting &quot;big tech&quot; against others.. with the assumption that we&#x27;re talking about FAANG.. there are 16 responses from public tech companies (if I&#x27;m understanding this spreadsheet correctly).<p>Data from article here: <a href="https:&#x2F;&#x2F;docs.google.com&#x2F;spreadsheets&#x2F;d&#x2F;1Cz7NqDblls_TBJVI4xwDeTStmVJ0Q75hch4qlwmARpc&#x2F;edit#gid=1786561341" rel="nofollow">https:&#x2F;&#x2F;docs.google.com&#x2F;spreadsheets&#x2F;d&#x2F;1Cz7NqDblls_TBJVI4xwD...</a>

&quot;We went from shipping the flagship Windows app once-a-quarter at best, to monthly shipping&quot;<p>Here&#x27;s some professional advice: The idea that releasing more often is a good idea is total rubbish. Eric S. Raymond said it originally (&quot;release early, release often&quot;) about open-source. People have applied it to software in general because of survivorship bias. Web devs tried it, and surprise, web dev can get away with shipping an update multiple times a day. Your users probably won&#x27;t even notice.<p>But what if your program isn&#x27;t a webapp? Updates aren&#x27;t so seamless. If you update Skype 3 times a day, your users will be prompted to update Skype app 3 times a day. Do you really think that&#x27;s a good idea?

The article mentions:<p><i>&gt; Scrum got in the way of shipping on a daily basis. The whole idea of Scrum revolves around Sprints, of committing to tasks at the beginning of the sprint, working on these during the sprint, and demoing what we did at the end.</i><p>What if each team member came up with a few tickets to work on during let&#x27;s say a 2 week sprint and then these tickets were shipped as they were finished resulting in releasing new code potentially every day or couple of days?<p>I&#x27;ve worked with a bunch of companies (contract work) and very rarely did they stick with 4-6 week sprints but only shipped everything at once in the end. That would be really dangerous. Almost always things were shipped as they were completed and reviewed.

s&#x2F;Scrum&#x2F;Kanban in most of these critical responses and it would still be pretty accurate of the state of most applications of it.<p>I can&#x27;t help but feel that people say Kanban because Scrum is so uncool. You can see that from the roasting Scrum&#x27;s getting here. With these visceral reactions, I can see why people are cautious about saying they do Scrum.<p>As for Kanban, most teams are no more doing Kanban than they are Scrum. That is, they&#x27;re probably just following Jira&#x27;s process. I&#x27;ve asked candidates in interviews what they mean by Kanban (e.g. if mentioned on their CV) and the common answer is, &quot;the process we use in Jira&quot;.

Scrum is one of the worst things ever to happen to Software Developers. The embodiment of metric rigging, and Developer disenfranchisement. A dream for a certain type of manager. I changed career not to have to use it.<p>Can you imagine Linus, John Cormack or Brian Kerningan having to stand up every morning, providing updates on what bug or feature they are working on? Which one would throw its mouse to the Scrum Master head first, when he would complain about their project &quot;velocity&quot;?<p>Use the &quot;One Hacker Way&quot; instead: <a href="https:&#x2F;&#x2F;youtu.be&#x2F;FvMuPtuvP5w" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;FvMuPtuvP5w</a>

I have come to the conclusion that is not about the methodology but the people. I worked in super productive teams that were not following any &quot;agile&quot; methodology, or really any particular methodology.<p>The goal was to get shit done and make customers happy.<p>On the other end of the spectrum, I have worked with teams that were pretending to embrace agile and scrum methodology though could keep standup quick and sharp.<p>It was an excruciating ritual that would take my most productive hours of the day: every day!<p>I always try to work with smart people. People who don&#x27;t need much direction and know how to get things done.

The article talks about big tech but it’s interesting to think of big tech in a couple ways. One is “Big Tech” (capital B and T) the other would be “big tech”. The destination is that the first is mainly the FANGs of the world that easily come to mind.<p>The second is other large companies that deploy huge amounts of tech but have different business models. Banks are an example. Apparently JP Morgan Chase’s annual tech budget is $12 billion!!! That’s a lot of money.

Name me one company that doesn&#x27;t profile a programmer using the points and velocities (etc, etc).The up-speak and dishonesty can be seen readily when they say &quot;All these metrics and data on your board will not be shared or used to decide your compensation or salary-revision.&quot;. The thing is that Agile, Scrum, Safe etc makes management happy that they have data which can infer devs productivity and return to the corporate. Thats all.

&quot;Teams struggling often had little to do with the methodologies. People mentioned lack of vision.&quot;<p>I would say &quot;lack of vision&quot; is one of the key features of SCRUM.

Startups implement Scrum or nothing, but the FAANGs each have an existing unique process with a cargo-cult veneer of Scrum on top.<p>All Scrum really means at a big co is an extra morning meeting that penalizes both people who like to work late and parents who need to get their kids to school. Plus you may occasionally hear the word &quot;sprint&quot; but it doesn&#x27;t mean anything as you can be given an urgent task or have a feature cancelled at any time.

The important distinction here is this is a set or principles for agile software development at scale. If you aren&#x27;t &quot;at scale&quot; and having trouble running basic Scrums, then you aren&#x27;t solving any problems by scraping Scrum necessarily. If you struggle organizationally to use Scrum principles then you&#x27;re going to struggle even more with this.

Ive worked in big tech and startups and the most effective planning ive seen is the TODO list we curated once a week.

Software engineers need more rigid structures and stop thinking they&#x27;re in a park trying out new technologies!

Pardon me for blowing my own horn, but as an alternative to all the usual approaches (Scrum, Kanban, SAFe, LeSS, etc.), for software engineering management at scale, my I suggest my own &quot;TameFlow Approach&quot;<p>It is based on Patterns and the Theory of Constraints.

Are Skype and Whatsapp even comparable? Whatsapp was competing with SMS (at least in developing countries) and it had a killer feature of making groups. Anyone who had a phone moved to WhatsApp overnight as they didn&#x27;t wanted to pay for SMS.

Being ISV I do not do SCRUM but I did see the examples of it at couple of my clients and did sit on few SCRUM meetings there (never again). My impression was that is is nothing but feel good tool for managers to cover their asses.

<i>Shape Up: mentioned for a few venture-funded companies.</i><p>Has anyone here some experience with Shape Up? Love to hear your thoughts. I just read about it so far and would love to hear some real-life stories.

I&#x27;m armchair at best, but I think scrum is a management and organizational process, something to help communicate upwards instead of something that is best for a team. That said, some companies and teams need the structure. They compare with Whatsapp, which seems to me like a small, dedicated, driven team with ownership and complete control over their own application. In my experience with Scrum, it was a product owner and management layer operating outside of the team, sending work downwards to the scrum teams while the scrum teams communicated progress and the like upwards. Less ownership, more oversight, etc. The scrum teams were implementation teams, there to do what they are told to do instead of owning a product. Cogs in a wheel, whose individual components (and the whole cog) could be replaced, shifted around and moved without the layer above really needing to worry about it.

&gt; The success of companies and project management approaches is not always correlated<p>Glad to see the author admit this... unfortunately most scrum cultists can&#x27;t believe this can be the case.

I have been a proponent of Agile for many years. But it bothers me that it has been used to take power way from Senior Developers. We really need to bring back the Tech Leads.

A lot of large companies in banking or insurance for example, don&#x27;t understand or seem to realize they are going to have to execute as if they are tech companies.

Agile In Their Own Words<p><a href="https:&#x2F;&#x2F;github.com&#x2F;rayfrankenstein&#x2F;AITOW" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rayfrankenstein&#x2F;AITOW</a>

I&#x27;d be interested to hear the meeting-to-work ratio at big tech and if the meetings are valuable.

Kind of surprising that the article doesn&#x27;t mention the profits and sway that Big Tech has to afford the approaches he describes. Borrow money very cheaply, buy back stock, profit from higher stock price. As well, Big Tech has market power (not necessarily monopoly) to allow for a lot of flexibility in deadlines.

Why imitate? Big tech also run projects to track us and ruin our lives...so

Disappointed that there are no mentions of LEAN in here.

I&#x27;m old enough to remember the B.S&#x2F;B.A. (Before Scrum&#x2F;Before Agile) times.<p>Agile has mostly been a disaster IMO.. I&#x27;ve worked at big public companies and 2-3 startups during it&#x27;s run. It works to come up with a &quot;MVP for 1.0 and then it starts dragging everything down because it encourages tech debt.<p>My experience has always been the successful companies&#x2F;teams were tongue in cheek telling everyone they were Agile when agile was popular while simultaneously trying to ignore Agile as much as they can because it was mostly ceremony and downsides once a product gets anywhere near mature. There was a lot of &quot;we&#x27;re agile with a lower case a&quot; at places that could tell the Emperor&#x27;s new clothes were suspicious.<p>Some of the old processes have been slowly creeping back in, and we&#x27;re kind of at the point now where teams no longer need to feel like they have to advertise saying they&#x27;re scrum&#x2F;agile to appear competent. But I think you either need some older managers or something else to figure out what to do next and how to bring back the good parts of older process methodologies because it feels like theirs a vacuum.<p>The relationships between teams and PM have changed so much. Agile elevated PM a huge amount but as Agile moved on PM seemed to abdicate all responsibility to do their part in the whole agile process, and now you&#x27;re left with a bunch of extra PM just getting in the way.<p>Agile without developers being included in estimates was one of the worst things.. non-technical PMs constantly shooting down estimates with &quot;No, that is easy&quot; is the worst. But Agile to me always seemed to be about management being able to absolve itself of all responsibility for not being able to figure out what to build or how to build it and to always be able to blame the engineers.<p>As we go forward teams need to look back at the past and what worked before Agile, not just make something new up out of whole cloth.<p>One agile team I worked on which probably was the strictest essentially pivoted the entire product to something else 3x because PM never had a clue what to build that would actually sell.

I read the headline as big tech RUINS projects.

Really good, thoughtful, constructive update to Alistair Cockburn&#x27;s thesis.<p>Characterizing people as non-linear, first-order components in software development [1999]<p><a href="https:&#x2F;&#x2F;dl.acm.org&#x2F;doi&#x2F;10.1145&#x2F;1811226.1811241" rel="nofollow">https:&#x2F;&#x2F;dl.acm.org&#x2F;doi&#x2F;10.1145&#x2F;1811226.1811241</a><p>Found TLDR:<p><a href="http:&#x2F;&#x2F;www.csci.csusb.edu&#x2F;dick&#x2F;biba.php?search=Cockburn00" rel="nofollow">http:&#x2F;&#x2F;www.csci.csusb.edu&#x2F;dick&#x2F;biba.php?search=Cockburn00</a><p>Sorry, Cockburn&#x27;s OG website is apparently gone. And I can&#x27;t quickly find a naked link to this paper.

Alternative title: &quot;Big Tech&#x27;s Curious Absence of Innovation&quot;.<p>Am I the only one who thinks Big Tech is slow at shipping?

Matches my experience well. Scrum works OKish in small teams depending on how mature their tech-lead and product owners are. It seems the default in consulting companies where tech consulting companies work with non technical customers. I&#x27;ve seen a few good examples and also some really bad examples of its application.<p>As soon as you scale scrum to organization wide, you get inter team communication challenges for which Scrum has no clear solutions (because its a team methodology and not company methodology). Once you have multiple teams that need to align their plannings to get stuff done, inter team dependencies become a bottleneck. Add a few external teams to the mix and you get a perfect storm of conflicting interests, miscommunication, politics, etc.<p>Having a lot of dependencies between scrum teams also means you get a lot of decision making lag. Scrum teams have two issues: they work in sprints with some fixed length and you can&#x27;t introduce new work during a sprint. If either is not true, you are not doing Scrum. When you have a graph of interdependent scrum teams, the lag you build up to get anything done is basically proportional to the path length through the graph. The bigger the org chart, the slower things get and it adds up quickly. The longer the path, the more planning and implementation sprints are involved in each team along the path and the more chance there is for things to get lost in translation. Beyond 3 vertices, the whole thing starts looking like a very chaotic waterfall style process where it takes months&#x2F;years to even agree to do a thing.<p>I speak from experience. The most dysfunctional thing I&#x27;ve seen on this front was Nokia flying in teams from three continents to have a bi-monthly sprint planning about 12 years ago. That worked just about as well as you can imagine (i.e. not at all). You needed to get your requirements scheduled 3-4 months in advance to stand a chance in hell of anything happening under 6 months. I&#x27;m talking critical stuff getting de-prioritized because one or more teams involved got other priorities imposed on them and thus had to say no. One of two things happens in such organization (usually both): 1) things get escalated to VP level management, a lot, and there is a lot of politics with lots of egos clashing. 2) teams eliminate dependencies to each other to speed things up (i.e. they reinvent wheels they could have reused just so they don&#x27;t have to deal with each other). Both are bad for productivity and cost.<p>The way out is to bypass middle management, ignore the process (on both sides) and establish direct lines of communication with engineers in different teams. Once you have that, pragmatic decision making can actually happen. At this scale, middle management should just not get involved with day to day engineering decisions and instead enable the day to day interactions and smooth out any inter-organizational bottlenecks.<p>Most of the big companies mentioned in the article are not great at this either. E.g. the reason Google has so many chat tools is because they have teams working against each other rather than with each other.

I’m familiar with the way of working described in the Skype web section. One thing this article has made clear is how much responsibility is pushed down to engineering, and removed from product ownership.<p>The product owner is not even tasked with approving the work done! Nor having any real kind of spec. However in my experience they still have veto power and the power to change what the project is at their whim.<p>This is all done with the idea of “autonomous teams” held firmly in mind. Yeah you’re autonomous... you can decide for yourselves how you will do what the project owner has decided they want today.<p>But they are still the owner! And will be the face of success when your project ships.<p>I suppose it’s a good thing they pay well.

Everything described in there is mirrored in SAFe fwiw, even though their survey said it was mostly used in large non-tech companies.<p>Individual teams can use whatever they want to manage themselves (Kanban, Lean, Scrum, etc…up to the team). Estimations planning and commitments for each quarter are done by developers exclusively, including coordinating across teams. Releases can happen at any point. A strong and continuously improving CI&#x2F;CD pipeline is an expectation.<p>I really wish more people knew about SAFe. It’s constantly improving and refining the experience and from what I have seen, if there is a better way to do things SAFe will become it.