23 ms·

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

• speby 4y ago
  A lot of comments in here misunderstand what it means when they think that teams at Big Tech aren't required to follow a specific process as meaning that those teams don't follow a process at all. The difference is that most senior, capable, and autonomous teams define and figure out their own process that works for them, not a pure absence of any process. Empowered and capable teams are simply better suited to figuring out and defining "just enough" process that works for them. It could just be an ultra-basic Kanban board managed through Linear.app or JIRA. Or it could be a more mature team that is still doing a more streamlined version of Scrum that probably is one or steps away from really looking more like Kanban. But autonomous teams does not mean that those teams "do whatever they want" with zero process at all. That's chaotic and doesn't yield very good results.
• synu 4y ago
  Running scrum is kind of a red flag for me, not a strong one but a concern for sure. Maybe this is unfair but for me it indicates a potential cargo cult mentality.
  • Silhouette 4y ago
    I was recently looking at the state of the contractor market and was shocked by the prevalence of Scrum, the lack of distinction between Scrum and Agile, and the number of places that apparently think Scrum is a modern development process that will appeal to good engineers. Perhaps they'd like people to go through a four stage process lasting about a month and including a weekend-long take home test and a LeetCode panel interview as well? At least it makes it easy for anyone who is better to stand out!
    • synu 4y ago
      Exactly - I’ve definitely seen a surprising number of companies here in Europe where they talk about using Scrum as if it’s proof of them being an innovative and modern company, and really make it a big selling point in their hiring materials. It comes across (at least to me) as a bit old fashioned and out of touch.
      • Silhouette 4y ago
        I suspect one problem is that the people who are high enough to be bringing in senior+ contractors have often been at the same company for a while themselves and may not realise how quickly their impression of the rest of the industry can become outdated. I had a discussion with someone not so long ago who was very senior, basically running all of software development in a tech business well past the early startup rush phase, who told me quite sincerely that everywhere did daily standups and worked off a Scrum-based process these days. This was someone who I respected for being smart and open-minded about most things, yet they had this intense blind spot about how tired Scrum and all the rituals that come with it are looking to a lot of good developers now.
• carlisle_ 4y ago
  Great insight, my key takeaway is this: > The fewer people you need to make decisions, the faster you can make them. This is the only way I’ve seen a “rockstar” or “10x” get stuff done as fast as they do. They only have to talk to a couple of people at most to start making big changes. The more large and stable a company gets, the more they seem to want to spread decision making power around the org. This appears to be very counterproductive, and it’s nice to see the simple truth called out.
  • azemetre 4y ago
    I feel this in my soul, I'm not even allowed to update internal documentation in our repo without linking it to a JIRA ticket.
    • mr-ron 4y ago
      I mean, thats pretty normal for any stage tech organization. The question is, who gets the right to create a jira ticket? Maybe you can do it, or just one other person. Thats not a big limitation at all to moving quick. Edit because this is causing a stir: Engineers within teams should have the right to create tickets themselves. Tickets should be minimal depending on the task. Creating a ticket that says 'update documentation' may take 10 seconds. Updating documentation may require a pull request. Controls (SOC compliance) may require that work is tracked to tickets. The core questions I have is, who can create the tickets, and how detailed do they need to be?
      • notyourwork 4y ago
        What is normal about this? Engineers should be empowered with ownership. Adding. friction or barriers to enabling engineers to make what they own better is backwards and counter productive at best. At worst, it discourages proactive willingness to make an improvement.
        • mr-ron 4y ago
          What is normal about this that Ive seen is work and tickets is often written into controls that are required for things like SOC compliance. And documentation often requires a pull request. And again read what I said, that engineers can and could be empowered to make these tickets, which can be minimal at best. Done right, its not a limitation at all, and instead adds accountability.
• umeshunni 4y ago
  My biggest surprise, when moving from 10+ years at FAANGs to a smaller valley startup, was the cargo cult worship of SCRUM, agile methodologies, story points and all that over just building and shipping value to the customer and moving metrics. I was also surprised, when starting to get involved in the broader Product Management community, that PMs at most companies (especially outside tech), are mostly project managers pushing JIRA tickets around.
  • ecshafer 4y ago
    My experience echos your finding, but in reverse. Going from Enterprise companies to a tech company, I was surprised that PMs actually seem to do things. I was so used to Project Managers / Scrum Masters just taking up time with meetings and pushing around Jira tickets with status updates, that when I finally got a Product Manager that really seemed to do stuff, and get a vision for where things are going, but worked well with engineers to get a design it was a breath of fresh air.
    • oblak 4y ago
      That reminds me it's a been an entire decade since I have worked with an actual product manager who knows and cares about the product they manage. Project managers are NOT it
  • greatpostman 4y ago
    Real product management is actually quite rare. Abs because of the length of the development cycle, mostly not needed
  • ishanr 4y ago
    That is why I am building notik.app. Having worked at big tech, I have taken the essence of scrum: single person responsible for a project, weekly updates, clear success metrics and delivering incremental value, and removed the bs which surrounds it. Oh and tie it with lessons learnt from other projects and suddenly you're in magical territory.
  • lloydatkinson 4y ago
• jonpurdy 4y ago
  My take as a TPM and certified in Scrum: the better and more skilled the team members, the less you need Scrum and other frameworks. Scrum is great for teams composed of new developers who don't yet know how to work together, or teams at companies with poor culture. But the best teams are self-organized and don't necessarily need the guidance of Scrum. As Gergely mentioned, team autonomy is a big factor in job satisfaction (and performance). But, it can still be worth doing in high performance environments if specific things are needed. Part of being Agile is adapting processes to teams, and some Scrum processes can be useful (relative estimation for example) even when not doing Scrum itself. As an aside, Gergely has a newsletter[1] (of which this is one of the free articles) that is absolutely fantastic. It's $100/yr IIRC and well worth it. Gergely deep dives into topics around tech including hiring, structure, comp, etc. Gergely also has a book[2] that helped me get hired in SF when I moved here a couple of years ago. [1] - https://newsletter.pragmaticengineer.com/about https://newsletter.pragmaticengineer.com/about [2] - https://thetechresume.com https://thetechresume.com
  • ardit33 4y ago
    Scrum (stand up and all) is a waste of time and only lower tier companies are still using it. That doesn’t mean that you don’t have a process at all. You might have once or twice a week sync meetings, and a biweekly planing meeting. But scrum as it is traditionally thought (Daily stand ups, scrum master, agile coach) and all that hoopla is thought to be out of date. If a company is spending 500k for an engineer the last thing they want is pointless meetings wasting their time, or have a non technical lower level agile coach try to dictate things (which I have seen it happen). At that level the expectation is that the engineer is mature and will know how to unblock themselves and doesn’t need infantile hand holding.
    • antupis 4y ago
      Thing is that scrum is for kinda hostile enviroments where developers need some safeguards and peace agains adhock requests and constant ops works.
      • 4y ago
• macco 4y ago
  The article mentions Plan->Iterate->Ship a lot. How is this essentially different from Scrum sprints?
  • ecshafer 4y ago
    Plan -> iterate -> Ship is different than scrum. One big difference is that its not usually time boxed into sprints. Another is that there may be multiple independent projects being worked on on one team. So you might have a team with project A being in the final touches, while an engineer leads on the plan phase for project B, as another person might be leading C in Iterate.
  • lostdog 4y ago
    1. Scrum sprints have all sorts of goofy restrictions, that you don't need to waste time on with a true-agile process. You don't need to plan out exactly two weeks. You don't need to worry about having too much or too little work in the sprint. 2. Scrum requires you to break things down pointlessly, when really most teams can execute on higher level goals. 3. Teams do not need to meet for a standup every day. 4. Effort estimates can be extremely approximate and wrong, but scrum tries to force you to spend way too much time on them. The "plan" in a non-scrum environment is much better at focusing on what matters, rather than ticking all the scrum boxes.
    • treis 4y ago
      You can do anything badly. Like point one, no you don't need to plan out exactly two weeks. You estimate what you want to get done in two weeks and then at the end you see how close you got. It's supposed to be a reality check to see how well estimates are matching up to actual effort. Which I don't really see why you shouldn't do something like that.
      • dubswithus 4y ago
        Our pointing sessions sometimes last 1.5 hours and involve the whole team regardless of expertise. Just imagine how much money we are wasting to determine: is this story a 1 point or 2 point story.
• indymike 4y ago
  A long time ago, I hired a scrum master. Two months later, I fired the scrum master, and exorcised scrum from my company. It was bureaucratic, it siloed people (you are front end, and you will only work on front end) turned simple decisions into decision by committee designed to reduce risk to the committee members, favored people who had little knowledge in decision making and put 10 out of 10 client projects behind schedule. I've never really looked at scrum again...
  • epicureanideal 4y ago
    > you are front end, and you will only work on front end That is something outside the scope of scrum. Whoever you hired may have called that scrum, but it seems they were bringing in unrelated processes. > turned simple decisions into decision by committee Scrum isn't a decision-making framework either.
    • eropple 4y ago
      > Whoever you hired may have called that scrum, but it seems they were bringing in unrelated processes. This is both true and not exculpatory, IME. I've often referred to/heard this referred to as "Scrum-but", i.e. "Scrum, but X", and it's pretty true in my experience that Scrum legitimizes and encourages Scrum-but. There are places where Scrum is legitimately useful (as a way for managing stakeholders when dealing with war-room problems where the entire implementation team is of roughly equivalent competency and is literally sitting around a table), but beyond that, the first hint of Scrum-but and the boat's taking on water.
    • baobabKoodaa 4y ago
      > Whoever you hired may have called that scrum, but it seems they were bringing in unrelated processes. Every time a Scrum project goes badly, any criticism attributed to Scrum is deflected with this no true scottsman argument. News flash: nobody is doing the actual, literal version of Scrum as defined in the Scrum Guide. Nobody. So if you use this argument to deflect criticisms of Scrum, be consistent & don't attribute any success stories to Scrum either.
    • 4y ago
• dboreham 4y ago
  This is an instance of an abstract pattern I've observed almost every day over my several decades in this industry: people imposing processes, techniques, tools, approaches, architectures, that appear to be inappropriate to the work at hand. A common factor is that the people doing the imposing are not experienced in doing the kind of work they're targeting. Sometimes the thing they're imposing was appropriate in some other context, but not in the current one (e.g. it works at Google but only because they have CI and RCS tools we don't have). Sometimes there's a kernel of truth to the thing, but that got lost in translation (e.g. have daily meetings, but we don't know the purpose of those meetings). The pervasive vibe is of people not thinking too much about what they're asking others to do, and not having any direct experience of the thing they're trying to control.
  • civilized 4y ago
    The idea that Management is a discipline in which one can be effective, independent of who or what one is managing, is silly. But it is a very convenient conceit for Managers of all stripes. Having a management issue? Bring in a Certified Manager(TM). It could be a PMP, a CSM, an MBA, or a WTF. It doesn't matter. Just airdrop them in and things will turn around.
• tyingq 4y ago
  All relative I suppose. Scrum on its own might feel refreshingly light if you've been experiencing something like: https://i0.wp.com/jeffgothelf.com/wp-content/uploads/2021/05/Scaled-Agile-Framework-_Full_web.jpg https://i0.wp.com/jeffgothelf.com/wp-content/uploads/2021/05...
  • perlgeek 4y ago
    Just wow. I "love" how in that picture, the individual contributors doing the actual work are the only ones not having a label. And it took me quite some time to even find them, and where the programming happens.
    • baobabKoodaa 4y ago
      You don't need to label your group of anonymous resources any more than you'd need to label the spokes on a gear.
  • cillian64 4y ago
    My company is in the process of implementing SAF. How doomed am I?
  • noisy_boy 4y ago
    All I see is, "You get a job, and you get a job and you get a job and everyone gets a job!"
  • diarrhea 4y ago
    I had never been able to make sense of that picture. It just looks like someone took all the premade symbols PowerPoint had to offer, combined them with all the buzzwords a quick Google search revealed, and scrambled everything on a canvas. Still, there’s bound to be thousands and thousands of people taking this seriously (it looks like satire to me) and at face-value.
    • tyingq 4y ago
      I suspect it's optimized to help reflect the need to purchase their training materials, pay for their certifications, hire their partners for coaching, etc. If it were simple, why would you need help?
• sirsinsalot 4y ago
  There's huge amounts of anti-process arguments in the threads here that is frankly immature. Most engineers when "empowered" and left to their own devices without much accountability go off on their own side quests that often add no value to the business, but scratch that engineer's curiosity. These side quests also tend to not contribute to business aligned goals. It'd be great if we could all just do what we want, but in my experience, process is crucial when aligning great people's efforts and energy with the business paying them. I'm not saying scrum is the way, but calls for "just let engineers decide and get on with what they like" sounds like 20-somethings with little experience of when and how often that goes horribly wrong. Suitable, proper process keeps chaos at bay and ensures everyone's expectations are aligned. That keeps business running and jobs and growth happening. Funny thing is, 15 years ago, I'd have been the first to agree that processes are "infantile handholding" (to quote one poster here). 15 years later and much wiser, I'd never hire anyone with that attitude.
  • MikeTheRocker 4y ago
    > Most engineers when "empowered" and left to their own devices without much accountability go off on their own side quests that often add no value to the business, but scratch that engineer's curiosity. These side quests also tend to not contribute to business aligned goals. At my last job, there was a strong bottom-up engineering culture where ICs were empowered to work on what they thought would deliver the most business impact. This was actually quite effective because there were performance incentives to ensure individuals and the organization had aligned goals.
    • sirsinsalot 4y ago
      In an ideal world this is the way. In cases where I've not had hiring decision making and the manager got it wrong (more often than not) this wasn't possible. Sad reality.
    • lupire 4y ago
      How many employees?
• jef_leppard 4y ago
  Ok I'll be the contrarian. My team transitioned to agile about a year ago. The difference has been dramatic. We ship faster, are way more focused, able to prioritize effectively, and don't burn out committing to unrealistic delivery dates. We don't have certified SCRUM masters or any of that silliness. We do have a PMO that knows what shes doing and that makes a huge difference IMO. The entire process is very fluid and we'll never go back. It took us a lot of work and iteration to find a working agreement that worked for us. I think maybe thats where a lot of co's go wrong implementing this stuff. You can't just cookie cutter it. It's a collaborative process with your teammates to find a way you collectively like to work together. And before anyone says that I don't know what it's like on the other side, know my team was following practices very close to that described in this post before switching. An EM decreed that we didn't need all the baggage of sprints etc and ditched it. Total disaster. Everything ended up being high priority (which means nothing was), fire fighting, heroics, burnout, the works. We shipped stuff but we struggled to prioritize larger initiatives such as architectural migrations etc. Really sucked. That EM was an idiot. Also that EM was me.
  • vander_elst 4y ago
    Could you share more background? Industry, size of the team, roles within the team, seniority, high level project description, etc
  • dgb23 4y ago
    From what you describe you don’t seem like an idiot, but rather someone initially doing decisions outside of their expertise and learning from it. That’s the opposite of an idiot in my world. You have a great PM now which might be a bigger factor than the specific methodology you use now.
  • exhaze 4y ago
    Please read the article. It has a whole section called "In Defense Of Scrum". The author of the article was personally involved in a situation similar to yours and addressed many of the things you brought up.
• dubswithus 4y ago
  This is basically why I opted out of any leadership role at my company. I'm not interested in being more involved in scrum/jira/whatever. Absolute hell and bringing in a dedicated scrum master makes it 1000x worse. I hate that I have to hear about deadlines as they relate to scrum and not business objectives. Or rather, the only business objective is to get something done in a quarter so we can show it off. We also can't start work on something mid-quarter if it won't finish in a quarter. Outcome is the same EOY but getting there sucks.
• Guid_NewGuid 4y ago
  My company is undergoing an "agile transformation" to use Scrum. Whereas before my team was working prioritising people and communication over process we're now "committing" to arbitrary deadlines and bogged down by process and useless meetings. Rather than being able to respond to change we have set scope and bringing work in is frowned upon because it might cross the "deadline". We don't even have a fixed release schedule so the fortnightly sprint boundary is pointless. I can see why you might need to run a low-trust low-skill offshore project this way but actually existing Scrum is worse than even the waterfall my first company did.
  • ibejoeb 4y ago
    Sorry to hear again that common refrain. Imagine it's 2002 and you're pitching a great new way to get work done: SCRUM, and its heart, the Sprint. From the docs: "A new Sprint starts immediately after the conclusion of the previous Sprint." Now imagine ever believing that sprinting for eternity is good, or even feasible. It really is a testament to their marketing prowess that this ever took off.
• nilsbunger 4y ago
  I think over-reliance on scrum or other heavyweight methodologies create a very low ceiling of performance for your team. You can't hire good people into that environment, and you're teaching a form of learned helplessness. I wonder if instead you could teach better practices to a broader swath of engineers. I don't think you have to be a 90th percentile engineer to respond well to empowerment, accountability, and an expectation to collaborate with others. They may not have seen that behavior modeled before, but I bet a lot of them would rise up and meet the challenge. Even if 50% of the team didn't meet the challenge, you're likely still better off with that smaller but more productive team.
• siliconc0w 4y ago
  I work in "BigTech" and larger projects often have 'sync' meetings to give updates and note where you're blocked. You also typically have 1:1s with your TL (or maybe stakeholders with other teams depending on scope) where you typically give updates on what you're working on and might chat about challenges/blockers. These systems are crazy complex, proprietary, and constantly changing plus you need agreement from a number of people to do anything making it very easy to get blocked so you really need to give people a forum to escalate technical or non-technical blockers.
• jdlshore 4y ago
  The phrase “plan -> build (iterate) -> ship” is carrying a lot of water in this article. It’s unfortunately vague. Scrum and Kanban, which are each called out separately, are also plan -> iterate -> ship methods. Reading between the lines, I think the distinction the author is making is actually between named methods and unnamed methods, some of which are customized variants of Agile methods, and some of which are entirely ad-hoc. For example, Spotify has a very disciplined approach to development that involves coaches and Agile principles, but is listed as plan -> iterate -> build in the article. The result is that plan -> iterate -> ship basically means “other,” which makes it hard to draw any conclusions. There’s also an unfortunate lack of distinction between Scrum implementations, which range from lightweight and team-driven to heavyweight and dysfunctional (mostly the latter, to be fair). The author uses the term “heavyweight” to describe Scrum, but it’s not clear that their survey respondents have the same biases. Ultimately, I think what the author has discovered is less a difference between processes and more a difference between Theory X and Theory Y management. [1] [1] https://www.jamesshore.com/v2/books/aoad2/management https://www.jamesshore.com/v2/books/aoad2/management
• AtNightWeCode 4y ago
  The only benefit of Scrum today is that it has a fixed set of rules so if you come from and old linear sequential methodology it is a great starting point for beginning thinking in agile terms. But as anybody will notice the rules of Scrum are inflexible and completely random in some areas and not very agile. That is why Scrum is pretty much dead. To use a methodology is extremely effective though. If you work with people with various knowledge and experiences in software development, it is must. I have seen companies go from Kanban back to cowboy coding and completely stopped producing anything at all that ended up in production.
• ibejoeb 4y ago
  I love this topic. Scrum is old enough now that many people think it is the way to make software. It's worth recalling that Scrum is a product that proponents use to sell books, win consulting contracts, and get on the talking circuit. It is self-reinforcing. Scrum, itself, is the endeavor. It is not genuinely a tool to assist you in your endeavor. Also note that practically nobody in industry does actual scrum. And, according to the Scrum authorities: "Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices." I'm not suggesting that Scrum can't succeed, but there's not much to suggest that it will help you succeed. It was never designed for that. Recognizing that Scrum itself is the product is the key to understanding why it often doesn't work and is so disliked.
• olliej 4y ago
  My reading of comments if that people seem to see two options: * Scrum/Agile/Current-hot-buzzword * PMs micromanaging via jira/whatever bug management My experience in corp engineering has PM as facilitators between teams that are for various reasons not directly interacting at a planning level. I’m not actually if they create bug reports unless they’re filing actual bugs they’ve found. Generally bug tracking for feature development is essentially umbrellas so you can see where things might be getting held up, and so you can (as an IC) prioritise. Many of my assigned bugs are my own personal task bugs, again the bug tracker is helping me manage my own tasks. I’m fairly sure this is how the majority operate. ICs have plenty of freedom for their own prioritization, and generally how they get to the end goal, and they’re able to experiment if they believe their current load has the spare time. There’s never really an ability to just randomly go off into some side project without at least arranging task redistribution with your manager. Another thing to realize is at bigcorp/FAANG many engineers are working to support multiple unrelated projects, which is again a thing the PMs help with - occasional meetings between people from the different teams working on a given project helps find if there are any issues being missed. The important summary is, I guess: * no annoying formal processes like daily stand ups, etc that waste time if different people in a team are working on unrelated things * PMs aren’t driving development, they exist to support communication * ICs have freedom to choose what they work on, and how they prioritise, but have all the info required to actually do that correctly. * with said freedom ICs are expected to do prioritise appropriately and effectiveness impacts responsibility (and presumably comp) in the future * I don’t know how things differ if you’re an IC wanting to go into management/PM land because that all sounds awful so I’ve never investigated :) The way things like scrum appear structured seems to be based on a lack of trust in ICs, or a sufficient overall lack of experience among people in the org, so maybe this simply represents a valuable tool in early stage companies.
• lumost 4y ago
  Anecdotally, the worst part about scrum is the skewed incentives it creates. When you start doing scrum, a few things become really hard. - Long term planning, few impactful projects/features ship in 2-3 weeks. Many can ship in 3-6 months. Talking about these things becomes exceptionally hard as debate on whether there should be a plan takes center stage. - Focusing on the right things. Do you care that the sprint points got done, or do you care that the customer's problem was solved? what if the two are in conflict? - Organization politics. When 5 teams publish burn down charts and one goes in the wrong direction, what happens? What happens when you ask another team to do something and they don't deliver? Do we haggle over "acceptance criteria"?
  • deleted 4y ago
    [deleted]
• danielovichdk 4y ago
  No process will solve what is really the underlying challenges companies face when building software. A process is a set of boundaries and has to be agreed upon within the team. If the agreement is slipping then the boundaries of the process is being broken. It's never a process fault that software teams can't deliver. Never. It is always: - handovers to other teams; testers, release, business. - communication between teams or outside stakeholders which has no actual skin in the game for delivering within the team. - keep communication inwards to the team and have the business really really close. - mandate and empowered teams can plan, run, test, release, monitor and adjust without any outside-of-team interference. -teams should be small because it will decrease the communication links and increase the possibility to create a good culture within the team. Enough has been said about processes during the last 20 years. Too little has been said about organization layout for creating productive and happy teams. I have worked in a few places where the process was well implemented but where we didn't have any mandate or autonomy, and because of that our culture was poor and people was frustrated.
• Zigurd 4y ago
  The best of modern software project management is not just Agile. It is the confluence of the spirit of Agile and the workflow patterns that go best with a git-based coding workflow. That has had a few years to evolve now and has incorporated CI/CD. That may seem obvious to some. But I think the influence of git having been designed for a certain type of workflow is underrated.
  • imbnwa 4y ago
    Can you describe some of these patterns for someone at a SCRUM feature factory with no CI/CD
    • Zigurd 4y ago
      Working on it and more re how Agile patterns really emerged.
• vbezhenar 4y ago
  It's funny that Scrum is called "heavyweight" process in this article. I remember agile methodology being called lightweight in contrast to traditional waterfall process. And the whole "Plan/Iterate/Ship" sequence really reminds me of waterfall.
  • arnvald 4y ago
    That's my problem with process management in software development. Things change, processes evolve, thihgs get lighter and easier. We went from bi-weekly releases to deploying a few times a day thanks to automated tests, canary releases, 1-click rollbacks etc. We went from waiting 2 weeks for the ordered servers to arrive to automated capacity management in the cloud. And yet in the process management 10 years ago we had Scrum, and today we have Scrum. No wonder it feels heavy when things around got easier and lighter.
• aleksiy123 4y ago
  I recently made a transition from a company focused on scrum to a FAANG working the way above. A lot of comments here are saying that engineers in this system can just do whatever they want without constraint. I think what people are missing is the focus on documentation that FAANG have in contrast to the focus on in person meetings in scrum. Things like sizing and planning get done in the initial stages of a project. The design docs and plans are peer reviewed and only once it has been signed off on does the actual implementation start. During implementation you have much autonomy but this is because most of the details have already been ironed out. The code is almost an afterthought. This has been my experience so far but also at a lower than senior level. So take it with a grain of salt. Also deadlines feel looser. Things regularly get pushed back quarters because of dependencies on other teams. Because there is no real fear of the company collapsing. It's okay we just work on something else.
  • 64StarFox64 4y ago
    How much of this is possible due to the fact that "there is no real fear of the company collapsing?" This sounds like process-resembling-waterfall, which seemingly works well because use cases, constraints, and patterns are (relatively) so well understood at an established company. Is there "edge" or value in that process, or is the value in the understanding of use-cases, constraints, and patterns (or a drive to align towards reaching said understanding) that enables the process?
    • aleksiy123 4y ago
      I think the second "the value in the understanding of use-cases, constraints, and patterns (or a drive to align towards reaching said understanding) that enables the process" These companies operate at a different scale, speed and constraints to other companies. Just as people say "you are not Google" don't use Google tech solutions for your problems. Don't use FAANG processes for your use case without understanding why those processes are the way they are. As an addendum to my first comment I want to also say that no scrum does not mean no processes. In fact there is a lot of processes. The number one complaint is that there is too much processes. They are just not scrum. There is no one size fits all solution which is what the product "Enterprise Scrum" tries to be. Teams need to understand their needs for themselves and build/iterate on a set of processes that works for them. Large orgs need to enable this as well as set the baseline for processes that work across the whole org at every level (indivudual -> team _-> product area -> organization).
• redeyedtreefrog 4y ago
  Agile industrial bullshit scale: Level 0, aka "kanban with continuous deployment": - Tickets in backlog arranged in approximate priority order. Meetings with business stakeholders (e.g. product managers) take place where the most pressing objectives are discussed, and as a result new tickets are refined and added to the backlog. As a result of changing priorities, existing tickets may be reprioritised or deleted in these meetings. - Pull requests are reviewed and then merged to the main branch. After passing integration tests they may be deployed to production either automatically, or at the click of a button. - status update meetings take place a couple of times a week. Or perhaps they are daily but asynchronoulsy via slack or a web app. - there is regular, adhoc communication and planning both within teams and between teams Level 1, aka "scrumban": - In addition to the meeting(s) to refine tickets, there is also a "sprint planning" session where approximately 2 weeks of tickets are put into the following sprint, and a "sprint goal" is assigned that approximates what the team hopes to achieve - If another team or business representative brings up new requirements half way through a sprint, they are told it must wait until the next sprint. - If the team runs out of tickets towards the end of the sprint, more are drawn in. Other times work will take longer than expected, or be blocked, and tickets will roll over to the next sprint. - There are short daily standup meetings, where each team member gives a brief, free-form statement of what they've been up to, shares any learnings or problems they wish to share with the team, and maybe gives a funny anecdote from their personal life - Every sprint has a retrospective meeting where people talk about what went well, and complain about things that they didn't like. Level 2, aka "Scrum as a religion": - Managers use burn-down charts as a way of measuring the effectiveness of the team's organisation and planning. If tickets need to be drawn into a sprint or roll over to another, this is taken as a sign of bad planning. The team is asked how they will go about being more consistent in future. - Developers may be required to vote on a number of story points for each ticket. Managers may become very exicited that story points don't estimate the amount of time taken to complete a task, they measure complexity, whatever that is. Even though the creator of story points has stated he meant for them to measure the time taken. - The daily standup meeting requires each team member to follow a precise process, where they give an update on each ticket they have worked on in each column. Any time a ticket has taken more than a day, the manager asks whether there are any blockers. Any time a ticket has been moved to done, they are congratulated by the manager. After these updates, the team must then discuss the sprint goals - the bi-weekly retrospective meetings are required to have outcomes. These often involve either more meetings or more processes Level 3, aka "Am I in a Dilbert cartoon?": - The senior managers involved in coordinating planning across multiple teams decide to introduce some ideas from the scaled agile framework. Multiple sprints are grouped into blocks of 6-8 weeks. Large numbers of JIRA tickets are refined and divided into epics before the start of each mega-block-sprint. Each week senior management measure the progress towards business objectives with regard to how many tickets remain incomplete in each epic. If a team gets to the end of the 6-8 week megablock having somehow done exactly the same work as they originally planned they are congratulated for being highly Agile. Those that don't achieve this are told they've missed their targets. - Releasing any service to production requires filling out a 20-point spreadsheet checklist along the lines of "have any breaking changes been notified to other teams? has this been tested in a development environment? have new tests been added?". Pull requests must then be made to multiple repositories to actually tag and release a new version, and a series of slack messages must be manually posted on the status of the release. - Making any decision beyond completing work on a JIRA ticket requires scheduling a meeting Level 4, aka "Scaled Agile Framework ®" - The megablock multi-sprints are 10-12 weeks, and are alternated with "hardening" sprints where people fix all the bugs they introduced in earlier sprints, and possibly "innovation and planning" iterations, which is the only place anyone is allowed to do any work that requires any thinking. - Half the employees have titles like "Solution Train Engineer", "Release Train Engineer" and "Scrum Master" I've just reached level 3, previously couldn't get beyond level 2. Anyone managed level 4? Are there bonus levels beyond that?
• gorgoiler 4y ago
  When it comes to engineering success you have to be very clever to be successful. I’m not sure how hard a truth this is for some people. Every time I hear of a learn-to-code boot camp I worry that we’re training bus drivers when we really need master stone masons. The worst people to work with are the ones that don’t realize how wrong they are. If you end up with a group of them all reinforcing their mediocrity on a day to day basis then you are in a lot of trouble. Some shops can tolerate this, especially if they are just screwing together business logic without having to really innovate in terms of pure software. Scrum probably works quite nicely for them. They ship their ISO compliant b2b software once every quarter with the dollars rolling in. If you know Douglas Adams you’ll know the term B-ark. These are the B-ark software teams.
• voidcrab 4y ago
  > Unlike Skype, Whatsapp never bothered with a framework like Scrum. Early employees shared how they never even muttered the word and deliberately ignored all heavyweight processes. Whatsapp out-executed Skype, built a more reliable messaging experience than Skype, and ultimately won the battle of messaging and communication apps. Article overall is ok but this part killed me. It's like it's implying that the team management methodology is what made Skype lose, and not that Whatsapp was the right project at the right time that filled a mobile niche, while Skype was an older project that was unlikely to go through a full rebrand. To put it simply, Skype was really bad. Team managament can in some cases stale the developers, but in this case it wouldn't do anything if Skype was already headed nowhere. Unless not using scrum magically made the people working on Skype have a vision and good UI taste.
• osigurdson 4y ago
  This is useful information for projects/teams/companies doing Scrum. Many of them are likely doing it because they think this is how big tech companies operate and wish to emulate them.
• drewcoo 4y ago
  I have a couple of problems with this. 1. Scrum is not a heavy process. It's an agile process, the opposite of heavy. It rarely involves Gantt charts, UML, or book-length specs. Kids these days . . . sheesh! 2. "Plan -> Build(Iterate) -> Ship" seems like a made up methodology. Or a badly-copied O'Reilly title.[1] It does not describe the way teams behave. Consider teams as software-producing systems. Systems need feedback to correct; to adapt; to learn. Where is the feedback in this methodology? Yes, there's probably some feedback smuggled in with the iteration, but there needs to be feedback in the system about the system itself. And because of #2, I'm calling BS. Which was not intended as a poop joke but I will pretend I meant it that way now if anyone asks. [1] https://www.abebooks.com/9781491984871/Design-Build-Ship-Faster-Safer-1491984872/plp https://www.abebooks.com/9781491984871/Design-Build-Ship-Fas...
• nunez 4y ago
  honestly, i've always been of the impression that SAFe and, to a degree, Scrum have just been adapters installed to "increase engineering autonomy" in a way that maximizes compatibility with traditional project management. at hugeco's, someone, somewhere, is translating story points into man-hours and velocity into project burn in dollars, usually in a guarded Excel spreadsheet. engineers running the show at these places would accelerate companies to the stratosphere (because engineers can do pretty much anything with enough money and autonomy). a man can dream.
• stonecharioteer 4y ago
  I've been at one small tech company, one large fintech company with insane redtape and one mechanical engineering company. Of all the three, only the mechanical company was slightly religious about using our ticket tracker to figure out what I was doing. Maybe because I was the only developer there for a while. I wish I could have worked at a place where scrum means something, or where PR reviews actually did what they're supposed to. I'm tired of always being the one who has to teach others.
• lifeisstillgood 4y ago
  My hot take - project management is about co-ordination with other teams If you are co-ordinating through the code, you hardly need a common methodology let alone a common tool. If you are co-ordinations outside of the code (ie by having a project manager send their updates up a chain) then yes common methodologies matter So this is a problem of software literacy - a company that cannot introspect itself cannot see where it is.
• geekraver 4y ago
  When this article was first published I contacted the author and told him it was misleading; Scrum (or large portions of it, like time boxed iterations, daily stand ups, and sprint boards) is popular in a number of big tech firms (I’ve worked at 3 on teams that have used it).
• antipaul 4y ago
  Great intro story of Skype vs. WhatsApp!