23 ms·

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

• lbriner 5y ago
  I don't quite understand the "lack of Scrum in large companies" when they all seem to Plan-Ship-Build. That is pretty much the high level description of Scrum isn't it? Sure Scrum has some ceremonies, but these are basically planning and retrospective for improvements, so again, not really any different. At the end of the day, most of the ways I have worked end up with Tickets/PBIs/Stories and you work through them. The only major difference is how much in-advance these are specified and to what detail.
  • Mehdi2277 5y ago
    I’ve worked at a couple big tech companies and one scrum. Notable differences, much less ceremonies, planning is also more up front with deviation allowed but not needing additional planning, and ticketing being optional thing that varies by team. I do not usually track my current task with a ticket or story. I have once week meeting with my team to discuss what I did last week and what I’ll work on next week. There is no 2 week sprint/constant stand ups/individual ticket estimates/retro. A typical plan is for a project that will take a month on short side or 2 quarters on long side. Deadlines tend to be soft with it culturally accepted that most deadlines are rough estimates and a week or two so deviation being fine. Process feels very light for me and I’m pretty happy with that.
• ilrwbwrkhv 5y ago
  Usually in interviews I check if they use Jira in their day to day process. If they do, I don't join that company.
  • worldsayshi 5y ago
    What would you use instead?
    • dboreham 5y ago
      Bugzilla
    • jumpkick 5y ago
      Bugzilla is still around.
    • Arcanum-XIII 5y ago
      Basecamp, Bugzilla, Redmine, a wiki, anything else. But there's a worse Jira than Jira with the Azure Dev Board.
    • tmcneal 5y ago
      Github Issues, Linear, or ClickUp
    • zozbot234 5y ago
      Phabricator?
    • kragen 5y ago
      A TODO file in Git. Seriously, though, having your software enforce too much prescriptive workflow on you is dramatically worse than having it enforce too little. Historically it was common for every software team to write their own bug tracker for this reason.
  • kayodelycaon 5y ago
    I mostly agree. It does depend who set up Jira and why. I’m a developer and have full admin access. I know exactly the kinds of tooling required for smooth integration with the rest of the business. Jira is the one product everyone involved agrees on. (If reluctantly.) It is a fuck-ton of work to set Jira up so it gets out of the way, but it has all of the customization I need to serve most of everyone’s needs. If anyone so much as thinks about enforcing workflows on our scrum board, they are going to hear my polite, but firm, rejection of such meddling. It’s our board and we let other people see it so they don’t have to bug us with requests for status updates. Jira isn’t a hard no for me because I’ve been an admin for it at both this job and my previous one. Let my team manage our stuff, and I’ll happily set up Jira to keep everyone else’s grimy paws off my team.
  • strife25 5y ago
    Why is Jira a deal breaker for you?
    • ilrwbwrkhv 5y ago
      I have found it to be a great heuristic for companies which focus on process for the sake of it and usually treat engineering as a cost center instead of there reason of being.
  • amai 5y ago
    Too bad for you if they use Excel instead.
• nickjj 5y ago
  The article mentions: > 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. What if each team member came up with a few tickets to work on during let'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? I'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.
  • Arcanum-XIII 5y ago
    You forget that there's a big administrative load added to a two week scrum (planning, daily, daily...), that you need to test and validate, potentially validate the work with QA and do a demonstration at the end. I've never seen a two week sprint working as intended. Especially if you factor the interruption for fix, new feature discussion, task that are more complex than expected and so on. If you add a manager in the loop, pressuring the team member to agree to unrealistic deadline, Scrum is pretty much the best way to destroy everyone involved.
    • UK-Al05 5y ago
      I think most people I see doing scrum these days, do a story, demo a story to owner, release story. Move onto next story. Rarely do they release at the end. The review at the end is for all stakeholders to be able to catch up on what's being going on the last 2 weeks.
    • nickjj 5y ago
      > You forget that there's a big administrative load added to a two week scrum It wasn't forgotten. Maybe the places I've done contract work for didn't follow scrum to a T. There was no daily planning. It was meeting once for 2 hours every 2 weeks to figure out what to work on and then a few small teams self regulating themselves asynchronously until things were done. This included doing the work, updating the ticket, having at least 1 person review / test the PR and it getting released. Usually there was a 1-3 day turnaround time from the PR being set to review to it being live on the site. Could be longer if the PR needed a lot of changes from things caught in the review process but the ball was always moving. It never killed a single developer's productivity to wait on a review because every developer had a few tickets to work on during that 2 week process so they could jump to the next one or review another person's PR in the mean time. There was no manager component once the tickets were chosen for the sprint (which was often a manager + developer group effort). Code could go from a ticket to production with no administrative bottlenecks.
• mindvirus 5y ago
  One pet peeve of mine: people often say they run a "lightweight" 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.
  • jmnicolas 5y ago
    It depends: when I was hired 12 years ago the manager said "we're going to mix agile and waterfall". What he really meant was that there wasn't any methodology at all and I would be left alone on how to organize myself. I'm still employed there so I guess my methodology (or lack thereof) isn't that bad ;)
  • Scarblac 5y ago
    I have been on teams like that. It's just biweekly planning meetings. I don't see how that means you pay the full costs of something like Scrum.
    • desert_boi 5y ago
      Is biweekly twice a week or every two weeks? My previous gig had grooming/internal grooming every week. We had stand ups twice a week (biweekly). Almost all of these meetings were relatively worthless imo. They existed to justify a BA's position and "track velocity".
      • Scarblac 5y ago
        Every two weeks, in our case. Confusing word, sorry. We had two week "sprints". Every day a 15 minute standup before lunch. We planned what we were going to do the next two weeks. During that time urgent work would also be added and other things wouldn't be finished, but they just moved to the next sprint. Releases were quarterly (customers didn't like frequent releases) so not related to the "sprints". Some managers described this as "Scrum light", fine with me.
• softwaredoug 5y ago
  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. 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. 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. Odd how so many companies want to do “what [successful tech co] does”. Yet those companies innovate their own processes.
  • snarf21 5y ago
    One thing I learned a long time ago is that a "bad" process that is followed universally by everyone (dev, pjm, pm) will always out perform a "great" process with only token buy-in and constant exceptions.
  • noneeeed 5y ago
    Nice to see big companies working like this. I wish more places would understand that different approaches work for different people, teams, products, technologies and contexts. There is no one true way, and most attempts to impose one tend to create something that is bigger and more complex than any single team needs. It's like the human equivalent of a code library that is trying to solve too many problems and so becomes an unweildy mess of config and options and meta-problems. We (Bugsnag) are a relatively small engineering team, so have the advantage of low comms overhead, and we do have an overarching approach, but each of the teams works a bit differently. Even from project to project I'll adjust what makes sense based on complexity/risk/size.
  • tootie 5y ago
    I find this concept utterly baffling, but probably because I've never worked at this kind of org. I can see how letting engineers run their own process is great for engineering efficiency, but how do they know what to deliver and when? My conjecture (please confirm or deny) is that these self-organizing teams are a result of and not a cause of big successful companies. You are probably iterating on a very well-understood and successful business model with a huge cushion for mistakes because you have some much revenue. By contrast, I have mostly worked in consulting and non-tech orgs. If we don't show that we're spending their budget on high value features, we get layoffs. Hence we not only need very thorough clarity on what feature development will yield the greatest returns, but also deniability that we had good reason for doing what we were doing if it turns south.
• danjac 5y ago
  My tinfoil hat theory is that Scrum was invented by Big Tech to hobble potential future competitors.
  • Arcanum-XIII 5y ago
    Nah, it was created to add a new industry on top of IT. Everyone is doing Agil.. I mean Scrum. So everyone need to be certified, to follow workshop, to follow the "innovation", to buy the associated toolings and so on.
    • ironmagma 5y ago
      How can I get anti-Scrum certified?
      • ChuckNorris89 5y ago
        Refuse to work at places that practice?
        • ironmagma 5y ago
          No, I want to be able to represent myself as authoritatively as the guy who proclaims to be “scrum certified,” as though scrum is so valuable as to have a certification.
          • ChuckNorris89 5y ago
            Did you miss the /s by any chance? I pray to god that you did.
            • ironmagma 5y ago
              I guess I'll keep you guessing.
  • aitchnyu 5y ago
    > ...Skype in 2012, the company had gone all-in on Scrum. All engineers and product people were sent to best-in-class Scrum training, facilitated by one of the Agile manifesto’s founders. We trade the story of one Agile Founder wanting to kill his monster baby, but the others have been making bank.
• brightball 5y ago
  Everything described in there is mirrored in SAFe fwiw, even though their survey said it was mostly used in large non-tech companies. 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/CD pipeline is an expectation. 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.
  • jon-wood 5y ago
    I'm sure there's some nuggets of value in SAFe, but I just can't take anything seriously which welcomes you into it's world with this diagram: https://www.scaledagileframework.com/wp-content/uploads/2021/01/SAFe_5.1_Portfolio_SAFe_ImageMap.png https://www.scaledagileframework.com/wp-content/uploads/2021... Also note up in the top left corner, where you've got the customer abstractly feeding work into this treadmill of... stuff. If your development team aren't talking to either the customer, or representatives of the customer, nothing else in agile will work.
    • brightball 5y ago
      I do hate that diagram.
    • namdnay 5y ago
      oh you sweet summer child... that's only the first or second level of SAFe. Once you get to full "operating thetan level 8" , they give you this abomination: https://www.agilest.org/wp-content/uploads/2018/03/scaled-agile-framework-4-5-big-picture.png https://www.agilest.org/wp-content/uploads/2018/03/scaled-ag... yes, that's right, an "agile" process with 5 levels of bullshit between the customer and the keyboards EDIT: anyone know why this is "flagged"? is there a trigger on keywords? or on URLs?
  • namdnay 5y ago
    SAFe is beautiful in that it is the ultimate expression of Enterprise Agile Cargoculting: all pretenses of agility are lost, there are ten different levels of decision making, and all responsibility is diffused in a confused mess of worker bees running around under an all-powerful and all-seeing LPM > Individual teams can use whatever they want to manage themselves (Kanban, Lean, Scrum, etc…up to the team) Except that they can't, because they will need to align on PI dates based on sprint durations, publish their burndown statistics and various other measures, and there's no way the poor soul who is reponsible for collating that will go into several different tools > Estimations planning and commitments for each quarter are done by developers exclusively, including coordinating across teams No they're not, they're done by the product owners, the system architects, the release train engineers (shhh... don't call them project managers), the product managers etc > Releases can happen at any point In my experience, releases can only happen at the end of a program increment, or maybe at the end of each sprint because until then nobody has integrated everything together > A strong and continuously improving CI/CD pipeline is an expectation. Fair enough, until the "innovation sprint" becomes the "bugfix spring" and all those good resolutions fly out of the window > I really wish more people knew about SAFe. So do I, just like I wish more people knew about colorectal cancer > 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. SAFe is constantly evolving, because that's the easiest way to keep the money coming in. It's as if PADI had found a way to change diving equipment every 2 years and ask everyone to recertify Sorry for the tone, but I still have PTSD
• sparsely 5y ago
  > Many teams work on main branches, get quick feedback from CI/CD systems and can immediately share functionality which they are working on with other team members. I occasionally see statements like this floating around - does he mean: * Devs make their changes locally, commit and push directly to main, and then the CI/CD either notifies them that tests failed or deploys to prod or * 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. 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 "work on main" means. I also don't really see a drawback to the second one in comparison.
  • science4sail 5y ago
    > 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 "work on main" means. Yep, that's the point - it's to discourage devs from checking in failing code (because then they'll be swarmed by annoyed coworkers). It's fairly common to see developer A make a breaking change to some low-level library and then see developer B push a rollback of A's changes a few minutes later (with or without A's permission).
    • sparsely 5y ago
      If that's fairly common it doesn't seem like a great setup? Why not automatically run the tests beforehand? And presumably there is no need for a staging env, since your code is deployed to production as soon as it has passed tests.
      • Jensson 5y ago
        At Google your tests are automatically run beforehand, but not all tests of entire Google are run for your commit beforehand. Sometimes you break others code with your change. Edit: Just to clarify, it isn't ok to break downstream projects, if you do the change gets rolled back almost immediately. And you can run all tests for the change before submitting, but it isn't default since it is expensive for many core projects to run so many tests.
• lordnacho 5y ago
  The thing about Scrum is the observations and principles make sense, but then to sell it as a course they've turned it into very specific prescriptions. 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's also common sense that you should have tasks written down somewhere, and that some of them are more important than others. You certainly need to think about how long tasks will take, but there'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. If you have a team of people that more or less adheres to a few principles, there's no reason you can't get things done.
  • shados 5y ago
    Scrum is a specific implementation of some vague overarching concepts. Of course it's going to be prescriptive, that's the point. Else you're just doing "agile". When you bring a prescriptive implementation, you can then leverage learnings from many orgs over many many years to handle all the edge cases instead of reinventing the wheel. If you don't, or do "Scrum but not quite", then when things don't quite work out, you're on your own. I'm no fan of Scrum, and rather use almost anything else, but that doesn't change that there's significant value in using systems that are mostly figured out and "work". Most of Scrum's bad rep comes from people who think they know better, tweak it to suit their needs, then realize they made a ton of holes in the system and their Frankenscrum doesn't really work. At that point you're better off just doing your own things. Which is what folks do, they abandon Scrum and do agile their way.
    • ipaddr 5y ago
      Scrum is like a global variable or a goto statement. If used carefully it could provide benefit but is often thought negatively. Used by untrained or junior team members and projects spiral. Senior members shy away because of experience.
    • jerf 5y ago
      If you do "Scrum, exactly", then when things don't quite work out, being "on your own" is the best case scenario. Worst case is that someone yells at you and blames you because Scrum Objectively Works so it must be your fault. I see no reason to believe that Scrum is a tightly tuned machine that must be precisely run to work at all, and any deviation from it makes it fall apart. In fact, if that is the case for Scrum I'd consider it a fatal objection. I don't believe the effectiveness landscape for project management techniques is shaped like that, I don't believe that the effectiveness landscape is a black pit everywhere just around Scrum only for a sudden spike of effectiveness to exist precisely where Scrum is located, and if it were shaped like that, I don't believe in the capability of anyone to have found and proved that spike. Since the only practical algorithm to explore this landscape is gradient descent, anyone carefully and thoughtfully exploring this landscape should never have found Scrum. Or, to put it in less mathematical language, the idea that Scrum is super effective but if you deviate from it just a bit it all falls apart is complete garbage. Do real agile, all the time. Scrum's only useful for raiding for ideas, and I'm not particularly impressed with it for that purpose, either. But it's not quite literally bereft of good ideas. I wouldn't give its ideas any particular credence for coming from "Scrum!", through. I don't see a lot of evidence that it is specially deserving of respect. It seems to work for some people, yes, I don't deny that, but the rate at which it works for people is sufficiently low that I don't think it has any sort of special claim.
• throwaway4good 5y ago
  "Teams struggling often had little to do with the methodologies. People mentioned lack of vision." I would say "lack of vision" is one of the key features of SCRUM.
  • speed_spread 5y ago
    You need vision for scrum, but it's not that big lofty goal that never changes. Agile vision should be affected by what you discover as you advance.
• megamix 5y ago
  Why imitate? Big tech also run projects to track us and ruin our lives...so
  • draw_down 5y ago
    Ewww, you don’t wanna be like Amazon! All that money they make... yucky
• hatchnyc 5y ago
  > 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. 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.
  • deleted 5y ago
    [deleted]
  • dasKrokodil 5y ago
    The gatekeepers are the ones with the people skills: https://www.youtube.com/watch?v=hNuu9CpdjIo https://www.youtube.com/watch?v=hNuu9CpdjIo
    • ericbarrett 5y ago
      What a utopia this movie portrays! Individual cubicles, administrative assistants for senior staff, and the protagonist has only been asked to work over a single weekend.
      • lostdog 5y ago
        Funny to look back. Here's Intel's HQ: https://www.youtube.com/watch?v=XrZrTJqK7ys https://www.youtube.com/watch?v=XrZrTJqK7ys All I can think is "Wow, I bet I could really focus on something difficult in that cubicle!"
      • 1ark 5y ago
        ... and, unpopular opinion, business attire!
  • whynotmaybe 5y ago
    I've also seen some instance where gatekeeper were pretty effective at filtering users demands because some of those requests were too dumb and the "paying" users were used to have everything they wanted, and because they "paid" the dev department, "they had to do everything they wanted". Like asking for a 6months dev work to help them save 1 hour annually on an annoying task they had to do.
• draw_down 5y ago
  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. 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. 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. But they are still the owner! And will be the face of success when your project ships. I suppose it’s a good thing they pay well.
• megamix 5y ago
  Software engineers need more rigid structures and stop thinking they're in a park trying out new technologies!
  • amrx101 5y ago
    Amazing. Hope you prosper.
• amrx101 5y ago
  Name me one company that doesn't profile a programmer using the points and velocities (etc, etc).The up-speak and dishonesty can be seen readily when they say "All these metrics and data on your board will not be shared or used to decide your compensation or salary-revision.". 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.
  • Mehdi2277 5y ago
    I’ve worked now at Facebook, tiktok, and snap. None of my teams used tickets so there are no points to track. Most of the time my tasks were just discussed with my team and main way you could track is by prs. How many points a task is worth is something I’ve only had to do for 1 job at a startup where we did follow scrum. I do occasionally give estimates but they also aren’t really tracked as they’re frequently not written down anywhere and just something I tell my teammates.
• Kharvok 5y ago
  The important distinction here is this is a set or principles for agile software development at scale. If you aren't "at scale" and having trouble running basic Scrums, then you aren't solving any problems by scraping Scrum necessarily. If you struggle organizationally to use Scrum principles then you're going to struggle even more with this.
• throwaway5752 5y ago
  I really want to say this: SAFe is an awful process and a trend that will hopefully go the way of Unified Process/RUP. I won't go into it, but it'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. I find it interesting that they author references Skype circa 2012. It sounds like classic "uppercase A" 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. The idea of an "agile enterprise" is intrinsically absurd. Teams are agile, not companies, and teams and products should be loosely coupled. That's why the big tech companies in this link have converged to similar answers to this problem (they are not "agile enterprises" but give teams some latitude to solve their own problems, and rather focus on results). Kanban is better in most ways for most teams. Also, Tuckman is a silly model that is only popular because it rhymes. PS: Strawberry-Jam-O-Meter and a Wrong-Order-O-Meter 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. https://www.wired.co.uk/article/skype-coronavirus-pandemic https://www.wired.co.uk/article/skype-coronavirus-pandemic has is a reasonable overview if you'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.
  • rusk 5y ago
    > The idea an "agile enterprise" is intrinsically absurd. Teams are agile not companies I’m really not sure what you are basing this on. Agile, as I’m familiar with it is framed in terms of lean management which is a well established approach to running business, exemplified by Toyota. Now you can debate the suitabilities of this and the effectiveness til the cows come home, just as you can with agile and scrum etc but it isn’t accurate to say that there aren’t a lot of businesses that aspire to the lean approach.
    • kragen 5y ago
• root-z 5y ago
  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/features at a very specific date (some sort of launch event), so we have to know very early in the year what'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.
  • lbriner 5y ago
    You cannot get management buy-in to Scrum or most agile processes unless they can accept the agile manifesto principles. The whole idea that you can be agile while having delivery dates for things several months in advance is a nonsense. Agile is about doing what is important now, not doing what we thought was important a few months ago. The best you could probably hope for is Kanban or the never-ending backlog but some people struggle when there is no finish line, just an endless sea of work!
    • convolvatron 5y ago
      the idea that you can deliver a multi-month or multi-year project without ever looking past the next two week sprint is really misguided.
      • sethammons 5y ago
        We just delivered a multi-year project under Scrum (edit: point of clarification, we did not have a due date). You still have a guiding vision and some idea of the major milestones you need to reach, you still define what the next set of milestones are. You will want several sprints worth of work lined up ready to be more concretely planned. You just do concrete planning for the next sprint or so and work to minimize disruption of that sprint. Learnings being incorporated and plans updated as needed. Work that will yield more understanding should be prioritized. Not sure where the idea of "only look one sprint into the future thing" came from.
• debarshri 5y ago
  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'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.
• Traster 5y ago
  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: > “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. I have repeatedly see teams that run like this fail. They're happy in their own right, they'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. It'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 "Oh well here's the process we follow, here's what you need to do". But in reality what they're saying is "We're entirely unable to respond to the actual requirements of our stakeholders, so instead we've decided there are only a subset of requirements we're going to fulfill" 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're either doing the wrong thing, or it's no longer needed or they fail to actually deliver it to the stakeholder. It's a great system to build a well functioning team that entirely fails to deliver what the larger organisation needs. /rant over I guess
  • birthday 5y ago
    That's where short cycles come into play. If something is urgent for business (and often everything is "urgent") then it can fall in the next cycle which is just 14 days away. It's rare that something is so urgent that it should disrupt your entire dev team flow and focus. Also what happens is you end up with a never ending dev cycle where business expedites an item making the cycle a little longer, business sees the cycle is longer and thus adds in more items to be included further lengething the cycle... I think you get where this is going. At my startup company we have suffered from just this in past, where we would have never ending dev cycles while our maintenance back logs filled up and never got worked on properly.
• deepGem 5y ago
  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 ? "We'll fit this into the next release cycle" is not an option, let's say. 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 ?
  • mandevil 5y ago
    In my experience, there is no good solution to this problem- when feature X comes along and it is decided that the ongoing work on A,B,C need to be paused because X is that important, there really is no way to quickly context switch back to A,B,C after X is finished. The best thing you can do, in my experience, is make sure that the devs are fully bought in on why X is so much more important than A,B,C. Ideally, you want to present it to them as 'X enables us to get this contract/solve an uptime issue/whatever' and then let them decide, as a group, that maybe we continue on B while the two working on A and C instead focus on X.
  • aninteger 5y ago
    Well, hopefully that is not the norm, but it's not like you are limited to a single branch (fork) at a time.
  • shadowgovt 5y ago
    Version control will let you set the work aside and resume it later. You might have to burn a few cycles merging your old code up to date, but it won't be lost. I haven't really seen a better option. Urgent work is disruptive to schedule by definition.
  • mywittyname 5y ago
    > What is not clear to me is how an abrupt new feature with an urgent deadline fits into all this ? "We'll fit this into the next release cycle" is not an option, let's say. Maybe the larger, successful tech companies avoid doing this. I believe that most of them define work at a quarterly level. So a team is unlikely to have the sudden changes in direction. They are also unlikely to be resource-constrained, so when the odd high-priority feature emerges from the ether, they can put together a new team to tackle it. Smaller companies need the discipline to know not to suddenly change everyone's priority, and instead, work emergent features into the current backlog at a pace appropriate for the size and scope of their teams.
• vthallam 5y ago
  One of the bests parts about working at a faang is we don'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.
  • deleted 5y ago
    [deleted]
• specialist 5y ago
  Really good, thoughtful, constructive update to Alistair Cockburn's thesis. Characterizing people as non-linear, first-order components in software development [1999] https://dl.acm.org/doi/10.1145/1811226.1811241 https://dl.acm.org/doi/10.1145/1811226.1811241 Found TLDR: http://www.csci.csusb.edu/dick/biba.php?search=Cockburn00 http://www.csci.csusb.edu/dick/biba.php?search=Cockburn00 Sorry, Cockburn's OG website is apparently gone. And I can't quickly find a naked link to this paper.
• voidfunc 5y ago
  Ive worked in big tech and startups and the most effective planning ive seen is the TODO list we curated once a week.
• ryanmarsh 5y ago
  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. Each has benefits and tradeoffs. Like all tools the proper process type for your project will be context sensitive. For an industry so full of smart, supposedly logical, people ours is still quite immature and tribal in its management theory.
• OmegaPG 5y ago
  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't wanted to pay for SMS.
  • francisthesixth 5y ago
    Well I guess that’s the way (SMS alternative) Skype was trying to go. They clearly didn’t get any close though.
• osigurdson 5y ago
  I'd be interested to hear the meeting-to-work ratio at big tech and if the meetings are valuable.
• k5z 5y ago
  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. The approach is described here https://www.gordiansoftware.com/news/two-weeks-too-slow https://www.gordiansoftware.com/news/two-weeks-too-slow 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.
• RandomLensman 5y ago
  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. However, no process can remove actual randomness (did anyone get the necessary ideas, for example) or uncertainty (is it even feasible, for instance). That said, in larger - and I'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/Scrum kind of construct. To me, seeing Scrum then more in non-tech/consultancy makes total sense.
  • dayofthedaleks 5y ago
    Criminy your first paragraph is well put. I'm definitely stealing that.
• wirthjason 5y ago
  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. 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.
• PerkinWarwick 5y ago
  Just to be the old grouchy guy, I can't say that any of the modern processes sound like any fun. 90% of the time I'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. Perhaps it's just a difference in the scope and type of projects (boutique hardware vs. large scale online stuff). 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/ad hoc approaches. Simple source control. Simple spreadsheets for bug lists. Admittedly it'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. ..or maybe it's just that earlier generations of programmers were stupid. I can accept that.
  • kragen 5y ago
    The software process stuff I've found most valuable is really the XP/Joel-Test stuff, not the Scrum stuff: · nightly builds or continuous integration; · pair programming or code review; · automated builds; · comprehensive test suites or test-first programming; · fixing bugs before adding features; · source code version tracking software; · keeping a list of bugs and planned features instead of not keeping one; · prioritizing planned features instead of not prioritizing them; · merciless refactoring to keep the design simple; · DRY, as a criterion for what "simple" means; · "YAGNI" (not writing code to provide functionality that I'm not implementing right now); · a sustainable pace (no death marches); · exploratory "spikes" to explore unknown features; · taking regular breaks; · informal usability tests with prototypes; · standup meetings; · frequent releases; · quiet working conditions; and · retrospectives. I'd add, though these usually go without saying these days: · high-level languages; · interactive development environments, as opposed to the batch-mode approach where you submit a batch job and get back your program output an hour or a week later; · enough testing hardware that you never have to wait for a testing machine to become available in order to get your work done; · using available software libraries instead of not using them. I'm pretty confident that each and every one of these helps me build better software faster, though a few of them may vary somewhat depending on circumstances—I know a guy who can concentrate to write code better in a noisy café than in a private office, frequent releases are at best minimally useful for pacemaker firmware, and you couldn't have written qmail using existing libraries. Also, though, I'm guessing that the old codebases you're looking at with simple spreadsheets for bug lists practiced "working software over comprehensive documentation", "customer collaboration over contract negotiation", "responding to change over following a plan", and especially "individuals and interactions over processes and tools". And those are the core aspects of agile development (though not the Fake Agile we so often see). Some of these are things earlier generations of programmers could only rarely do. If you're working at a company that values processes and tools over individuals and interactions, there's not that much you can do to fix that if you couldn't start your own company; https://news.ycombinator.com/item?id=28670326 https://news.ycombinator.com/item?id=28670326 suggests one reason this is so widespread. Similarly for fixing bugs before adding features, using an interactive computer, having adequate testing hardware, and having quiet working conditions. Source control systems, automated builds, and automated test suites provided substantial benefits to teams that adopted them, but many didn't. That doesn't mean they weren't valuable at the time, just that many people did without. By contrast, I'm less convinced of the value of private offices, written spec documents, schedules, dedicated low-paid testers, scrum masters, planning poker, splitting and merging product backlog items, quantitative task estimation, and even coding interviews.
• blunte 5y ago
  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 "So-and-so-contact is not available." 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.] Maybe they were missing what I noticed missing from my last Scrum-focused company: view and attention from the higher altitudes. 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't encourage higher level reviews, refactoring, etc. It's the problem of not seeing the forest for the trees. Of course you can intentionally create epics for these kinds of reviews, but those don'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. 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't understand the value, and generally NOT solving the real problem.
  • tootie 5y ago
    That's not a fault of scrum. If you can't sell the value of refactors on to product, then either you're not making your case or they aren't being reasonable. But you'd have the same problem with any process. We run kanban mostly and we get refactors and tech debt into the backlog pretty regularly. We also reject them pretty regularly when they don't see any viable business cases.
• FpUser 5y ago
  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.
• Cthulhu_ 5y ago
  I'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.
• shoto_io 5y ago
  Shape Up: mentioned for a few venture-funded companies. 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.
  • artichikin 5y ago
    We adopted it a year ago and the team still quite likes it. Reduced day to day stress and distractions and a good structure and shared vocabulary. Wouldn’t say it’s perfect but much nicer than the sprint treadmill.
    • esel2k 5y ago
      We just started using it and I am pretty happy that it keeps PM (me) really shaping things with a fat marker to farm for dissent early on without distracting devs in endless meetings. So sharing vision and customer problems early is great. What miss is (maybe its me): How do you get into that execution mode from there? Break it down? High level estimates? How do get started (especially large endeavors that would be more than 6weeks)? Thanks for any insights
• mempko 5y ago
  Alternative title: "Big Tech's Curious Absence of Innovation". Am I the only one who thinks Big Tech is slow at shipping?
  • WJW 5y ago
    Compared to who? Two-person startups can be faster yes, but all the Big Tech companies are legit racecars compared to (say) a bank or a pharmaceutical companie. Also, shipping fast and actually innovating are not the same.
  • wittycardio 5y ago
    Yes you are because they ship an insane quantity of products with very high quality. I'm guessing you're looking to justify the existence of scrum?
    • mempko 5y ago
      I just think Big Tech not using scrum is a strange way to make an argument against scrum since there are sectors in tech that ship faster imo. So why not look at the fastest shipping segments and see what they use. I would love to hear from Big Tech employees if they feel like they ship a lot. To give a baseline, 1k LOC per developer per week is a lot. That's what the highest performing teams can produce.
      • wittycardio 5y ago
        Are you trolling or stuck in the 60s? Do you seriously consider lines of code to be a real measure of productivity
• Yizahi 5y ago
  I don't get Jira hate. It may be clunky, slow and overcomplicated but really it's just system to document stuff. If you don't document stuff on a sufficiently big project (I'd day >10 engineers, and especially at >100) then it's a recipe for a disaster. 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.
  • dstaley 5y ago
    > I don't get Jira hate. It may be clunky, slow and overcomplicated Ding ding ding! Seriously though, I think a lot of issues with Jira stem from poor implementations that cause it to perform terribly, which impedes an engineer's ability to quickly get in and out of Jira. For example, the on-prem Jira instance for one of my clients would take upwards of five minutes to render the board, and another 30+ seconds to render the ticket page. Adding comments was another frustrating experience. I'm sure the OOTB experience with modern Jira is probably fine, but it seems that hardly anyone uses Jira without some resource-intensive customization.
  • rightbyte 5y ago
    What is needed is registrars keeping track of documents and writing summaries etc. I blame the 'savings' on secretaries for many of the modern corporate worlds problems. A tell tail of that the top brass them-self don't believe secretaries are not needed, is that they them-self have them. It is just engineering that can't have them - pushing any bigger engineering org. into chaos.
• spaetzleesser 5y ago
  My theory is that in tech companies top management usually understands how tech development works and have respect for their workers. 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. 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. 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.
  • esel2k 5y ago
    Same here. Worked all my career on medical/biotech as software product and project manager. I‘ve even heard management telling me „this is just code, should be copy paste“ and „why is this taking so long that should be easy“… and if things of course don’t go as planned they layoff and hire Accenture. My role (as I see it) is to keep devs motivated, translate this mystery of development for them and present some kind of roadmap. As much as I would love to only work with empowered teams, the reality is that with these big nontech companies are not ready to change anytime soon. Maybe we worked at the same place?:)
    • spaetzleesser 5y ago
      “lay-off and hire Accenture” Seems we are at different companies and my company is a step ahead. After Accenture then comes TCS where nobody knows anything :).
• deleted 5y ago
  [deleted]
• ekianjo 5y ago
  > It measured a Net Promoter Score (NPS) of -83. This is staggeringly low, and means that 83% of engineers would advise against JIRA No, that'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.
  • excitom 5y ago
    NPS is a marketing tool. I agree it's misused in this case, but the people at the extreme ends of the scale DO matter. They are the ones who will passionately voice their opinions, write reviews, do blogs posts, etc. The people in the middle of the scale can't be bothered with doing anything about their opinions.
  • blululu 5y ago
    It's not exactly what an NPS score of -83 means, but it's close enough and an NPS score of -83 is sufficiently awful that it should be considered a crisis for any business that does not have strong customer lock in. Actually a few promoters in the sample would potentially imply that more than 83% of engineers would advise against JIRA. Of course NPS scores overlook some nuances. It's a single estimate of a complicated space. The imprecision is probably to its advantage. The goal is not to be perfect (no single number could do that), but to provide a quick estimate of quality with a single question (nobody wants to fill out a 3 page survey, and the executive team is only going to sit and listen for a single statistic). As an exercise, consider how you chose a restaurant based on a standard Yelp 1-5 scale: you might find that you are using a similar methodology while reading product/service review. Ratings of 1-3 are considered bad reviews, 4s are decent and 5s are good. American culture as a strong bias for positive affect so a 3 is considered to be unfavorable. Additionally, there is a lot of variance in terms of how people get upset and express their anger. Someone may rate something as a 1 because they are more expressive of their angry, while another person rates it as a 3, but neither is really happy with the service. Try coming up with a better metric based on yelp reviews for restaurants you are familiar with and you might find that NPS does a reasonable approximation of what you have discovered.
• christopherbalz 5y ago
  Kind of surprising that the article doesn'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.
• mbeex 5y ago
  I was there when Agile was invented. In my opinion, Scrum has always been the worst embodiment of a good idea. 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've been in the industry for more than 20 years, that's not too little. These days, mandatory Scrum is a contra-indicator for any project that crosses my path as a freelancer.
  • g051051 5y ago
    > These days, mandatory Scrum is a contra-indicator for any project that crosses my path as a freelancer. Yes! Although I don't agree that Agile is a good idea that scrum ruined.
    • ebiester 5y ago
      How long have you been in the industry? Agile in 2021 means something different than Agile in 2002. Project Management was a different consideration 20 years ago. Which of these do you disagree with? https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html I disagree with 2. Now, perhaps you disagree with 5. These were written in 2001 for problems in 2001. Now, some of these problems have been solved. Some of them are taken for granted today. However, we take them for granted in large part because a group of people got together and said, "we can do better." I personally think it's time for another group (not the old agile luminaries but people with new ideas) to take a look at today's problems and take a fresh stab at it. Maybe it looks like "Plan-Build-Ship." But maybe it looks different. But first, I think we need a clarifying question: What in the principles or manifesto do you disagree with?
      • g051051 5y ago
        I disagree with the whole thing. It was written by consultants to sell consulting services. The "principles" are empty aphorisms that have practically crippled the software development industry. Edit: > How long have you been in the industry? 32 years.
• g051051 5y ago
  > The success of companies and project management approaches is not always correlated Glad to see the author admit this... unfortunately most scrum cultists can't believe this can be the case.
• faizshah 5y ago
  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. 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. I think people should think twice before looking at big tech as the place to learn good management practices from.
  • foobiekr 5y ago
    I think your last point is wrong. Shipping big, complex projects at big tech companies, especially vendors who actually literally ship and can't do live patching to cover up shoddy practices, is actually something _everyone_ in the industry should do because you learn a lot about what it really means to build and release software. Cloud-delivered CRUD apps are the easy mode of SW development and people who have never done anything else really end up quite stunted IMHO.
    • faizshah 5y ago
      I agree with your second point, I often read project management advice and realize it comes from consultants and agencies and small companies and doesn’t really scale for big tech or address issues with large engineering teams. I actually agree with your first point too, I do think big tech devops and security practices should be copied. The point I was trying to make is that I don’t think big tech management is actually that good. Big tech is optimizing for staying big (reliability, security, etc.) the famous projects are usually the most uninteresting to engineers cause they ship a handful of new features a year and you spend most of your time working on bug fixes, infrastructure updates and security patches so those projects end up having the most churn in engineers and management. Because of that churn these teams tend to adopt the practices most suited to oversight (stand ups, sprints, retrospectives, etc.) instead of the ones best fit for improving the customer experience (grooming the backlog, collecting user feedback often, etc.). So that’s why I say we shouldn’t be using big tech management practices as an example imo, cause big tech still hasn’t decided on a solution to the problem of slipping deadlines, exploding backlogs and insurmountable technical debt.
• deleted 5y ago
  [deleted]
• ben7799 5y ago
  I'm old enough to remember the B.S/B.A. (Before Scrum/Before Agile) times. Agile has mostly been a disaster IMO.. I've worked at big public companies and 2-3 startups during it's run. It works to come up with a "MVP for 1.0 and then it starts dragging everything down because it encourages tech debt. My experience has always been the successful companies/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 "we're agile with a lower case a" at places that could tell the Emperor's new clothes were suspicious. Some of the old processes have been slowly creeping back in, and we're kind of at the point now where teams no longer need to feel like they have to advertise saying they're scrum/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. 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're left with a bunch of extra PM just getting in the way. Agile without developers being included in estimates was one of the worst things.. non-technical PMs constantly shooting down estimates with "No, that is easy" 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. 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. 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.
  • rfrankenstein 5y ago
    > 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. This is Agile’s “Executive Armor Effect”, which turns developers into a sort of ablative armor that can take hits for executives.
• jillesvangurp 5y ago
  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've seen a few good examples and also some really bad examples of its application. 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. 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'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/years to even agree to do a thing. I speak from experience. The most dysfunctional thing I'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'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't have to deal with each other). Both are bad for productivity and cost. 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. 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.
• lifeisstillgood 5y ago
  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. I think the big takeaway is "dont worry about your project managment system if you are playing the wrong game."
• romanhn 5y ago
  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 "no process" 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. 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'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/bonus/whatever. There'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'd choose that any day, JIRA or not. 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 "no process" story at the rest of the companies. Note I'm not claiming that the Agile processes are by definition good. I'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'm suspicious of is the "every team picks their own process" claim, having seen company-set norms exerting enough force to make deviations from the common pattern rather painful and counter-cultural.
  • paxys 5y ago
    Funny that you mention spreadsheets. When I worked at Microsoft my entire business unit (multiple thousands of engineers, managers, PMs) exclusively used Excel for project management. Clean UI, filters, data rules, conditional formatting, validations, pivot tables..it was the absolute best. And with Excel data tools it was all hooked up to a central database (TFS) for live sync/updates. Now I use Jira and hate every second of it.
  • fredliu 5y ago
    Very interesting, do you have any examples of how FB manages long term (2+ years out) project that involves 100+ Engineers? Are those 100+ engineers all "individuals working on their own project"?
• deleted 5y ago
  [deleted]
• tibiahurried 5y ago
  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 "agile" methodology, or really any particular methodology. The goal was to get shit done and make customers happy. 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. It was an excruciating ritual that would take my most productive hours of the day: every day! I always try to work with smart people. People who don't need much direction and know how to get things done.
• tomc1985 5y ago
  Disappointed that there are no mentions of LEAN in here.
• HeroOfAges 5y ago
  A lot of large companies in banking or insurance for example, don't understand or seem to realize they are going to have to execute as if they are tech companies.
• w0mbat 5y ago
  Startups implement Scrum or nothing, but the FAANGs each have an existing unique process with a cargo-cult veneer of Scrum on top. 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 "sprint" but it doesn't mean anything as you can be given an urgent task or have a feature cancelled at any time.
• RayFrankenstein 5y ago
  Agile In Their Own Words https://github.com/rayfrankenstein/AITOW https://github.com/rayfrankenstein/AITOW
  • deleted 5y ago
    [deleted]
• jkingsbery 5y ago
  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. First of all, I work at Amazon (and posting this under our social media policy, this is just my experience, and I don'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). 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't a lot to it. You sync with your teammates daily, to make sure you'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've been on that have tried to not do these things either in actuality, did these things, but did them subconsciously, and therefore unintentionally. When I hear people say "Oh, I don't like Scrum because my old team did Scrum and I didn't like how we..." what follows is almost inevitably something that if you asked a professional scrum coach "Should we do that?" the answer would be no. > Competent, autonomous people need less structure to produce reliable, high-quality output. Big Tech is able to attract, afford and hire these people. I don'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. 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't particularly helpful.
  • Jensson 5y ago
    Pretty sure the article refers to Google, Facebook and the companies trying to be like them. Apple and Amazon works quite differently as you say.
• knightofmars 5y ago
  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. "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."
• marcus_holmes 5y ago
  Reading this, I'm struck by a thought: Are we the bad guys? According to the article, what the big tech companies have in common is engineer-led products. It's not the besuited MBA's making product decisions, it's us, the engineers. 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 "big tech" is doing things that actively harm society. Cue the "are we the baddies?" meme [0]. If engineers are left to build products by ourselves, do we build things because we can and not because we should? [0] from https://www.youtube.com/watch?v=uK-kWRAVmRU https://www.youtube.com/watch?v=uK-kWRAVmRU
  • Jensson 5y ago
    Pay engineers to optimize a number and they will, that is all you need to do. In this case they told engineers to optimize the number of ads clicked and then the engineers self organized and did the rest.
  • colinmhayes 5y ago
    People who sign up to work on ad services for google or engagement for facebook have already self selected as willing to do morally dubious work in exchange for more money. There's no question that engineers do work that decreases society's utility. I don't think following incentives makes someone bad though, it's only human nature, and of course there are plenty of people queued up to replace you. The system that creates those incentives might be bad, but it can be impossible to untangle where the incentives stem from.
  • kragen 5y ago
    Maybe evil is just more profitable than good because it externalizes its costs. Creating a sports car, or paying someone else to do so, is a lot more expensive than just stealing one, if you can get away with it. Robbing a bank is cheaper than building a bank. If you can do this kind of thing at scale, well, to the extent that you only have to spend money on capturing value instead of both creating it and capturing it, you'll be vastly more profitable than the "suckers" you're capturing it from. Same thing is true of Fecebutt: creating the mountains of data their users go to Fecebutt for (restaurant recommendations, family photos, thoughtful essays, sexy bikini shots, social-network data) took perhaps a trillion person-hours, but Fecebutt gained control over it at a cost of under a trillion dollars. Ballparking, they had to spend less than 5% of the cost of those assets to acquire control over them. Now it can leverage them to organize genocides, rig elections, and extort photos of government IDs and use them to out promiscuous women and closeted gay people—not to mention selling you tens of billions of dollars a year of stuff you don't need through advertising. It's hard for positive-social-value companies like Shopify and Datadog to compete on salaries with that 20:1 value multiplier. The fact that they manage it at all is not only a testament to the enormous value they're producing but also the enormous destruction of value implicit in Facebook's business model.
• mcguire 5y ago
  Minor side note: My current employer has been pushing SAFe hard (training for everyone, etc.) recently. As a result (and I do mean "as a result") about 3/4ths of the senior technical people have resigned in the last three months. This is at a "Large, non-tech enterprise" (sort of; it's an engineery chunk of the federal government). Now back to a personal opinion: Most "software engineering" "methodologies" are intended to appear productive without actually requiring productivity. Or, as I sometimes put it, "software engineering is about making people who are fundamentally not very good at writing code look as if they were producing code." Look at the number of managers, leads, coaches, trainers, and consultants required for every methodology and compare that with the number of such "overhead" positions in, say, open-source projects. (Note: I'm not trying to start a "which is better" discussion; open-source is just a convenient example since their development techniques are transparent, unlike everyone else's.) 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 all fail at some point, even if they eventually deliver a usable product. 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.
• tootie 5y ago
  Of the weekly "Scrum sucks" posts we see on HN, this was by far the most articulate and well-reasoned. I'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'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. 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'd still be a bit surprised that anyone working on a customer-facing product isn't running their design decisions through product experts. Idk what that world is like, but I've spent a lot of energy duking out product debates where nobody is really sure how a feature should work or it's even beneficial and developers usually have the worst instincts.
• corpMaverick 5y ago
  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.
• jldugger 5y ago
  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. 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. This is why the big tech companies don'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.
• mmcnl 5y ago
  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't care about engaging without customers, like to complain about a management and take little responsibility. You need to have rules (however dumb you might find them), you even need babysitters. There's no going around that. Someone making 1/4h of what a SV engineer makes is highly likely to be less competent.
• dave1999x 5y ago
  s/Scrum/Kanban in most of these critical responses and it would still be pretty accurate of the state of most applications of it. I can't help but feel that people say Kanban because Scrum is so uncool. You can see that from the roasting Scrum's getting here. With these visceral reactions, I can see why people are cautious about saying they do Scrum. As for Kanban, most teams are no more doing Kanban than they are Scrum. That is, they're probably just following Jira's process. I've asked candidates in interviews what they mean by Kanban (e.g. if mentioned on their CV) and the common answer is, "the process we use in Jira".
• phendrenad2 5y ago
  "We went from shipping the flagship Windows app once-a-quarter at best, to monthly shipping" Here's some professional advice: The idea that releasing more often is a good idea is total rubbish. Eric S. Raymond said it originally ("release early, release often") 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't even notice. But what if your program isn't a webapp? Updates aren'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's a good idea?
  • kragen 5y ago
    XP was developed in the Chrysler Comprehensive Compensation project. The project began in 01993 and brought in Kent Beck to reboot it in 01996, at which point they still hadn't gone live; they went live in 01997 and continued work on the project until 02000. Frequent releases are one of the cornerstones of XP — every 2 weeks, I think, on C3. You can read about it in https://martinfowler.com/bliki/C3.html https://martinfowler.com/bliki/C3.html and https://wiki.c2.com/?ChryslerComprehensiveCompensation https://wiki.c2.com/?ChryslerComprehensiveCompensation. ESR wrote http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral... in 01997, but Jim McCarthy said "Release Early, Release Often" in his 01995 software-process book https://www.amazon.com/dp/1556158238 https://www.amazon.com/dp/1556158238 (which I haven't read) according to https://devops.stackexchange.com/a/80 https://devops.stackexchange.com/a/80. Releasing often isn't always a good idea, but it isn't necessary for every user to upgrade to every release. Here are some advantages of releasing every iteration (once or twice a month): 1. You can never have the software in an uncompilable or unshippable state for an entire iteration, much less three months at a time, so the only time you don't know how long a showstopper bug will take to fix is immediately after you find it, and you're never "integrating, don't know how long this will take," because frequent releases force continuous integration. You never slip a ship date, at least not by more than a week or so; you just cut scope. Slipping can be enormously painful and sometimes fatal to a business. 2. A hacker costs a business US$200k a year. A team of ten hackers costs US$38000 per week. If you release once a quarter, then, on average, at any given moment, you have six weeks of work that you've paid for that haven't reached users and are thus not yet producing any value; that's about a quarter of a million dollars of "inventory"—having a lot of inventory might sound great if you're a survivalist or an RPG player, but for a business, "inventory" is wasted money. If you can cut that to monthly, you only average two weeks of inventory, so you've saved US$170k, almost the cost of a person-year of work. 3. When you ship software to users, they react, which is an opportunity to learn from them about what they value and what they don't; this both gives you ideas for new features and gives you more information about the value of features you'd already thought of. This is true even if only some of your users install the new release. If you ship once a quarter, you get four of these round trips per year; if you ship once a month, you get twelve. So you can learn a lot more from your users. Evidently that wasn't enough to get Skype on track. 4. If you're a business, the business environment changes as you're developing software: for example, your competitors add new features, systems you interoperate with change their behavior in ways that break your software, and new libraries become available. To remain profitable and in particular to remain better than the competition, you must observe these changes, orient yourself with respect to them, decide what to do, and then act. In competitive environments, the competitor who can go through this "OODA" loop faster will almost invariably win. Shipping features that embody the right decisions for this month instead of the right decisions for three months ago can be a decisive advantage—though I think this is what WhatsApp was better at. 5. When your sales guy meets with a potential client on October 10 and finds out about a missing feature that's a showstopper for that client, and the October 28 release now has that feature, it gives you totally different chances of closing the deal than if the January 10 release has the feature. Even if they don't buy then, you've made a totally different impression, and you're more likely to make a sale later or get a lead on another potential client from them. 6. More generally, frequent releases make progress and quality legible to people outside the programming team, circumventing the "thermocline of truth" problem named in https://brucefwebster.com/2008/04/15/the-wetware-crisis-the-themocline-of-truth/ https://brucefwebster.com/2008/04/15/the-wetware-crisis-the-.... Having five features "80% done" after four months could mean you'll deliver them in another month, or that you'll deliver them in another 8 months. By contrast, the difference between delivering four of those features in four monthly releases, and delivering one of them, is a difference observable to users, management, sales, and customers. Sometime it's even helpful for keeping the people inside the development team from fooling themselves, despite being below the thermocline of truth. I'm writing this based on the experience of utterly smashing two established competitors at AirWave, where upgrading one of our clients always involved a field engineer, often doing a site visit. We weren't writing open-source software, either.
• mtc010170 5y ago
  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're drawing some pretty big conclusions from just over 100 responses. And while the focus of this seems to be pitting "big tech" against others.. with the assumption that we're talking about FAANG.. there are 16 responses from public tech companies (if I'm understanding this spreadsheet correctly). Data from article here: https://docs.google.com/spreadsheets/d/1Cz7NqDblls_TBJVI4xwDeTStmVJ0Q75hch4qlwmARpc/edit#gid=1786561341 https://docs.google.com/spreadsheets/d/1Cz7NqDblls_TBJVI4xwD...
• belter 5y ago
  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. 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 "velocity"? Use the "One Hacker Way" instead: https://youtu.be/FvMuPtuvP5w https://youtu.be/FvMuPtuvP5w
• newfromblammo 5y ago
  I read the headline as big tech RUINS projects.
• chronologist 5y ago
  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 "TameFlow Approach" It is based on Patterns and the Theory of Constraints.