22 ms·

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 co

• 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.
    • lostcolony 4y ago
      Yeah; the thing to remember with formal development processes is it's to try and force something upwards, not downwards. If the team is being forced to adopt Scrum, and the rest of the business isn't willing to adopt the contract placed on them (for Scrum the biggest is the business can't interrupt the sprint or -nothing- is a reasonable expectation from the sprint any longer, and any estimate is null and void and they don't get to ask why the team missed it without a finger pointing back at them), it's not Scrum that is the problem.
  • lostcolony 4y ago
    I've seen agile coaches be amazingly helpful...generally explaining to the VP why "pinning all three points of the PM triangle" is impossible, and why they have to pick either date or scope, not just throw headcount at it, if they want to continue to claim to be agile (let alone be successful. That said, every agile process needs to be treated for what it is; maybe a decent starting place, and probably a collection of good ideas for the context it grew out of, but not directly transferable; the whole point of a retro (the one meeting that the agile manifesto actually stipulates) is to modify the process for the team.
    • pbowyer 4y ago
      Is an agile coach a PM? Or do they function more like a (lifestyle, executive) coach does?
    • nescioquid 4y ago
      Frankly, I think you're already fucked if you need an agile coach to explain that to a VP leading a software development project. Either the VP is grossly ignorant of what they are doing, or they have structural incentives that make building good software of secondary, or tertiary importance. I've never seen mere coaching fix this.
  • icedchai 4y ago
    I remember working at companies where we'd have meetings once a week to discuss what people were working on and plan out the next week. Daily "standup"-style meetings were absolutely unheard of. If you had a "blocker", you'd check in with a coworker or boss, discuss it, and work it out, like a normal person. You're not sitting on your ass to announce "you're blocked" in a daily standup.
    • Panoramix 4y ago
      I agree so much with this that my blood pressure just went up.
  • sodapopcan 4y ago
    I feel like that is misunderstanding scrum. For example, standup is not supposed to be a status report, yet so many companies use it as one. In my mind it’s just a daily ritual where the team comes together and very quickly discusses the day. It should last no longer than 5 minutes. I understand that not everyone even wants that, and that’s totally cool, but standup gets a bad name since most people have experienced it as a status report.
    • sanderjd 4y ago
      I think the reason people end up using it as a status report is that nobody understands what to say otherwise. I can either say only "I'm not blocked" every day like a broken record (because if I were blocked why would I wait until the next morning to say so...), or I can say, "I'm not blocked and here's what I'm up to today", which is just a status report.
      • sodapopcan 4y ago
        It’s supposed be more of a quick planning meeting. But yes, I would often just say “pass”. Although really as far as I’m concerned it’s all about the ritual of coming together every day.
        • sanderjd 4y ago
          I "quick planning" is an oxymoron. If anyone says "I plan to do this today" and the response is "actually you shouldn't, you should do something else", that one thing is going to be at least five minutes of discussion. If that happens twice or thrice it might as well be a half hour meeting. And I actively dislike / don't understand the value of that sort of ritual...
          • sodapopcan 4y ago
            It’s about coming together as a team as far as I’m concern and get energized for the day. It doesn’t work for everyone and that’s ok. “Quick planning” is like, “Hey, I need with this today. Is anyone available?” But really it’s about coming together for me.
  • dfcowell 4y ago
    There are plenty of sub-500k TC engineers getting around, and the vast majority of companies are “lower-tier” by your implied definition. These companies won’t succeed if they try to act like they’re working with mature engineers, because they’re usually not. Skills like knowing how to unblock yourself, how to identify systemic problems in a team and correct them don’t come naturally to a lot of people. If you’re not encountering teams like this I’m happy for you, but lower-performing teams often benefit by adopting a rigid methodology to kick-start the process of self-improvement. In an ideal world, they further transform their working style into something that works for them by reflecting on their experience on a regular basis.
  • shostack 4y ago
    Congrats on being an engineer that can do these things. Many cannot and that is the bulk of teams out there. For those that are this skilled, this gives a window into areas they can flag for where they need to help level up the team. But I'd urge you to reread your post and consider that it comes across as presumptuous, myopic, and holier-than-thou.
• rendall 4y ago
  > "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." Hmm. I think your take is a bit like saying "Baths are only for dirty people. People who stay clean don't need baths."
  • imbnwa 4y ago
    I mean a dog is loyal, can be trained to do what you say but short-haired cats don't actually need baths like dogs do simply cause they take autonomous initiative on grooming and self-care
  • derefr 4y ago
    More like: long-haired domestic dogs require someone to regularly groom their hair for them. They don’t have the instinct required to drive them to groom themselves as much as they need, so a long-haired dog left to their own devices outdoors will end up with hair mats and ticks they can’t reach to scratch off. Long-haired cats do not need the help of a human groomer to avoid these things, because they do have the instinct to chew off excess/itchy/matted hair. Scrum masters — backlog / kanban board groomers — are for junior devs, who haven’t yet developed any sense for what an approachable task size is; what their comparative advantage is vs others on their team; etc. Senior devs do have that experience — and it’s surprisingly portable between teams/orgs.
  • namdnay 4y ago
    The analogy I usually use is “a Michelin-starred restaurant doesn’t have laminated recipes on the kitchen wall. A McDonalds does. Both of these are a good thing, depending on who you’re working with and what you’re trying to achieve”
    • zarkov99 4y ago
      That is a fantastic analogy, it captures exactly the pros and cons and the context dependency of methodologies.
    • sanderjd 4y ago
      Good analogy! Here's the problem though: how to you hire for a "McDonalds". It seems good to be self aware about whether you're running a McDonalds or a Michelin star restaurant, but can you be honest about that with candidates and still hire people?
• SoftTalker 4y ago
  All big methodologies and big application platforms (e.g. J2/Jakarta EE,.NET) are attempts to make average developers predictably productive and to ensure long-term consistency in and across large projects. These things are more important to "enterprise" than raw productivity/development speed. Highly talented developers don't need this structure and process, but if given the freedom, they are also more likely to create software that only they understand, using flavor-of-the-month languages or frameworks that they have personally selected. When their work is done and they move on, nobody else can figure out what they have done or why.
  • WalterSear 4y ago
    > Highly talented developers don't need this structure and process, but if given the freedom, they are also more likely to create software that only they understand, using flavor-of-the-month languages or frameworks that they have personally selected. When their work is done and they move on, nobody else can figure out what they have done or why. IMHE, not so much. You can't tell which code they wrote, except it's easy to read, and there's a lot of it. The loudmouths, they write inscrutable, flavour-of-the-month code. The talented coders aren't as bothered by this as much as everyone else is.
  • lumost 4y ago
    Really unclear on why you would have this perception. Most good devs I know appreciate the importance of a stable toolchain. I’ve worked in nearly a dozen languages at this point and it’s pretty rare that someone uses a language for the sake of using a language.
  • bcrosby95 4y ago
    I disagree. There's nothing interesting about pursuing frameworks and languages of the month. The highly talented, intelligent developers I know don't care about that stuff - their actual work is way more interesting. I think what you're describing is average to slightly above average developers who are working on boring, already solved problems. So they have to find something to make it more interesting.
    • 4y ago
• gfarah 4y ago
  My experience is aligned with this. I would add fast growing teams as well. It is difficult to grow 10->150 in a year without some form of methodology in place.
• hackitup7 4y ago
  Gergely is a great writer and has a lot of accurate insider takes. His Twitter is worth a read as well.
• ch4s3 4y ago
  > Scrum is great for teams composed of new developers who don't yet know how to work together I couldn’t disagree more strongly. My experience is that scrum teaches junior devs bad Han it’s around blame shifting, focuses them on process, prevents them from learning about the business, and bogs them down in meetings that don’t help them learn. > or teams at companies with poor culture I would argue that scrum ossifies bad culture. It has a habit of giving bad leaders metrics around things they shouldn’t be measuring. There’s a lot of software engineering research about processes and the case in the literature for scrum is very weak.
  • sodapopcan 4y ago
    That sounds like you weren’t doing scrum right. It’s also possible I wasn’t doing it right and was doing a healthy version of it?
    • ch4s3 4y ago
      Every scrum proponent always responds to any criticism with a no true Scotsman claim. I’ve never personally seen or heard second hand of a successful scrum implementation, and the SWE academic literature doesn’t support it either. I’d argue that spending time on activities like scrum poker or sprint planning are actively harmful for most kinds of teams. The points games are inherently adversarial, only add value for scrum masters, and waste time that could be spent understanding requirements/business problems better. The incentives are inherently perverse and the whole exercise encourages and rewards dishonesty.
      • sodapopcan 4y ago
        Well I feel it was successful on my old team. We weren’t micromanaged and owned our own process. We story pointed and those metrics were only ever seen and used by us. We got tons of value out of retros (had loads of difficult conversations with high levels of trust). We didn’t have a scrum master—everyone knew how to run all meetings and process. We worked closely with our customers doing rapid prototyping as to not waste time building features they only thought they wanted. We showed progress to the org via demos. I feel like it worked really well and really enjoyed it. As far as no true Scotsman, I didn’t mean it like that—I don’t care if people don’t want to use scrum, but I do take light exception when people shit on it an go on to describe a process that is alien to me. Though I guess what my teen was doing was a bit more of a mix of scrum and XP.
• ShamelessC 4y ago
  That certainly explains why so many competent engineers seem to hate it so much.
• trhway 4y ago
  > 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. Those are just low-immunity weakened places that Scrum is able to infect.
• RayFrankenstein 4y ago
  Three years of the best anti-agile social media comments. https://github.com/rayfrankenstein/AITOW/blob/master/README.md https://github.com/rayfrankenstein/AITOW/blob/master/README....