18 ms·

In one of my previous projects I lead a team of 5 talented and creative people and we did truly agile programming: everyone helped each other, asynchronous meet

• nine_zeros 3y ago
  > After three months, the progress slowed to a crawl, star dev abandoned ship, and customers started complaining for the first time. > Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master :) Oh wait till management finds engineers to scapegoat for their own decisions. If there is one truth about management, it is that they cannot accept "I told you so" from their reports.
  • jauntywundrkind 3y ago
    Yet to find a company where the folks down the reporting ladder can rate how they perceived various initiatives to have gone. So weird how businesses just don't want to hear how "Implement formal agile process" (or other goals) went.
    • nine_zeros 3y ago
      It's because companies are far more obsessed with power structures than with actual output. This is especially true for public companies where the grift is to get into positions of power, propose "initiatives", find scapegoats for failures, then hop on to another company - leaving a trail of damage behind. In my experience, the only time a company does well with structures is when there are fewer levels in the org chart and when the C-Suite penalizes management before ICs. Doesn't happen very often though.
  • WJW 3y ago
    Of course. Because they don't produce outputs directly, reputation is all a manager has to prove their worth to the company. If you take that away by publicly demonstrating how their actions caused bad results, their boss might well fire them since they are apparently being a net negative. Managers face a much more difficult labor market than most engineers too. So to exaggerate a little bit, not accepting "I told you so" from their reports is directly required to keep paying their mortgage and feeding their children. It's not weird that they get upset when you endanger their livelihood. OP has got the right idea and is just being zen about it IMO.
    • nine_zeros 3y ago
      You are not wrong. We both agree that the problem is the org structure as it stands. The incentives for layers and layers of management are divergent from the needs of the business and the needs of the producers of output. Perhaps we need to reduce the number of levels, replace managers with technical leaders whose incentives are aligned with the needs of the business. Offload all grunt paper work to an executive assistant. No need for EM1, EM2, EM3, Director, Sr Director, VP, SVP, SSVP nonsense.
    • rbanffy 3y ago
      > Managers face a much more difficult labor market than most engineers too. Indeed. I've been thinking about shifting back into management after a couple years as an individual contributor (playing an instrument is fun, but so is conducting a well functioning orchestra). In this space, aligning with stereotypes has become very important in the past decade or so.
• coldtea 3y ago
  More likely they'll just blame you, just like the sibling comment says... Their goal was never increased productivity and developer hapiness. It was literally what they said "introducing scrum and bringing in a scrum master". Their purpose is to add and manage processes (bureucratic layers) and increase their dependants.
  • notjoemama 3y ago
    aka: micro-manage, because they don’t understand the effort and cost…or if you’re cynical because you’ve experienced it, some middle manager desperately needs to control other people because they subconsciously know their position is 90% absolute dead weight. Maybe that’s a bit too negative, sorry.
  • vitaflo 3y ago
    In many companies headcount = power. You getting a ton of work done with a small team matters less than Bruce with his 50 reports and $6m budget for them. Middle managers will always increase headcount so that they eventually can become directors. Oldest game in business.
• baz00 3y ago
  Ah yes the defence: "The process failed because you didn't have enough project managers on board" No the process failed because it was fucking shit and everyone went somewhere else. The only good thing heavy processes are for are propping up employment statistics.
  • notjoemama 3y ago
    Have you ever seen the movie Office Space? There’s a bit about “TPS reports” where multiple managers individually correct the main character on a new cover sheet. I’ve experienced that myself. The movie portrays it comedically but IRL it’s kind of a demoralizing experience. A bit soul crushing actually.
    • nine_zeros 3y ago
      Office space is actually accurate once you replace TPS reports with Status reports/JIRA tickets/Performance reports/Incident reports etc. The amount of dancing required for the sake of management in this industry is just insane.
      • l33t7332273 3y ago
        I think “TPS report” is actually meaningless so it’s supposed to be swapped in for whatever is relevant to the viewer.
        • aidenn0 3y ago
          It's actually a real thing that software companies of the time were not unlikely to have: https://en.wikipedia.org/wiki/TPS_report https://en.wikipedia.org/wiki/TPS_report
      • SquirrelOnFire 3y ago
        As a long time PM (of all sorts of P)... If you don't want to have to talk to customers, which only one developer who I've ever worked with has actually wanted to do, you need a way to equip someone else to do so. Same thing if you want to keep your investors happy, your counterparts in other departments informed of when they need to have the hardware to pair up with your software ready, etc. There's definitely such a thing as too much overhead, but developers who just do the things they are interested in without considering that they are part of a larger business are the other side of the coin that you're describing.
• hibikir 3y ago
  The best I can say of scrum is that it's designed to get some amount of output from an otherwise extremely dysfunctional team. If your teams were achieving nothing, it provides a modicum of accountability. So there's places where yes, scrum is an improvement. But yes, a team of people that understand the business, and can prioritize well without needing someone to do it all for them, scrum just slows the team down. I've seen it happen multiple times in my career, and sometimes succeeded at either undoing the change, or making the jira-based work basically fictional.
  • oweiler 3y ago
    There is the old saying that scrum turns bad devs into mediocre devs and good devs into mediocre ones.
• bitwize 3y ago
  Real Scrum has never been tried.
  • notjoemama 3y ago
    True Scrumunism? :)
    • PartiallyTyped 3y ago
      Well, technically OP described anarcho-development.
      • AnimalMuppet 3y ago
        If you've got people who don't need bosses, that can work really well. If you impose clueless bosses on those who don't need them, they will often leave.
    • readyplayernull 3y ago
      In Scrumunism complexity puts the points on you!
    • lamontcg 3y ago
      No True Scrummist
  • _jal 3y ago
    Scrum can never fail, only be failed.
  • baal80spam 3y ago
    https://imgflip.com/i/7xhfm6 https://imgflip.com/i/7xhfm6
• ourmandave 3y ago
  What (or who) made them decide they needed scrum in the first place?
  • freedomben 3y ago
    IME, it's usually a new hire, usually a product person. There's always pressure on those people to introduce changes to increase whatever the KPI metric is, and from their perspective scrum is a great choice. Plus management drools over data/metrics, no matter how much you explain to them that there are serious flaws with the data. You get more of what you measure, and the law of unintended consequence can be a beast. I've seen people come under the Eye of Sauron because they weren't closing as many "story points" as their peers. In reality it's because this person was the best mentor on the team, and the most experienced in the codebase. They spent most of their time pairing and training others, but only one person gets to make the commit and claim the points. That person initially stopped helping people and would (understandably) get irritable when asked questions, and then left the company. Management considered it a win to dispense with a "low velocity" engineer. It hurts my soul to think about the stupidity, especially since they were told numerous times that this person was the MVP of the team, no matter what the metrics said. You get more of what you measure.
• brailsafe 3y ago
  My most informative experience was had at this huge auction company that I was doing frontend on. At one point, I was working on what we'd now call a component, but was at that time manually created dom elements generated with a very long series of logic branches that depended on a number of external, possibly async conditions. It was extremely hard and time consuming to test and keep all of the possible conditions loaded into my consciousness with all of the chatter in the surrounding space and some fuckhead making sales calls on his phone and typing on his mechanical keyboard—because y'know, everyone's gotta be in the same room—meanwhile the product owner would come over to add new requirements while I was trying to focus and then the scrum master would come over to ask why I wasn't done yet. This went on until my productivity and motivation ground to a halt, I burnt out, got depressed, and got fired. However, when I started at the company, it was surprisingly fine. I worked with two other guys collaboratively on some tricky frontend issues, which we solved, and it was fine.
  • t43562 3y ago
    scrum masters should only bother you at the standup. They also shouldn't add requirements. So .... the one you were dealing with was just an average bullshitter pretending to do scrum.
    • brailsafe 3y ago
      The product owner was typically changing requirements, Scrum Master I think realized they had no functional role and tried to be a busybody. Either way, it was awful, and it was looked down upon to try and find some peace and quiet to actually get things done.
      • t43562 3y ago
        Well, a sprint is a contract - people are not allowed to change the deal in the middle and if they are then the PO isn't doing their job. They're really there to defend the team from pesky customers and prioritise work so that you DO have peace and quiet. I get that this often doesn't work because individuals don't really grasp their function properly and don't defend or don't prioritise and then that part of the scheme cannot work. Sometimes the company structure makes the POs too scared to standup. IMO that would be a problem without scrum.
• siva7 3y ago
  This wasn't scrum because talking to the costumer is the primary job of the Product Owner and not of the Scrum Master. PO is also a full time job and not some side hustle of a team lead or SM. Having a good Product Owner makes the difference between adopting scrum successfully or failing at this process. Regarding why your team failed - i've been in a similiar scenario like you as a team lead. The answer is simple - no one in your team was open to adopting scrum so it failed. That's fine but it's not the fault of scrum rather than the company management.
  • lpapez 3y ago
    > Regarding why your team failed - i've been in a similiar scenario like you as a team lead. The answer is simple - no one in your team was open to adopting scrum so it failed. That's fine but it's not the fault of scrum rather than the company management. How do you know no one was open to trying it? I specifically mentioned that I personally objected to scrum, but wrote nothing about other people. What happened in fact was that people initially really tried their best ti cooperate, but it simply didn't work very well and crippled the team.
  • lolinder 3y ago
    I honestly can't tell, because you don't have a history of joke comments and didn't include a /s. Is this intentional parody, or did you miss OP's closing line? > Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master :)
    • sumtechguy 3y ago
      His point is not exactly invalid though? If you go into something with the intention of 'this sucks' and then do not even want to make it work would it not reason that it probably will fail? Scrum usually fails because people become enamored with the process instead of thinking about what that process is for. Layering on more and more of it because something is not working. Until you are busy with 40% of your time just managing scrum. Something in scrum not working throw it out. Do not double down and add more.
• chriskanan 3y ago
  This was exactly my experience, but many more months than 3.
• dragonwriter 3y ago
  > Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master Well, if there was a distinct Product Owner and they delegated this to the Scrum Master, it may have been by-the-Guide Scrum, but just extraordinarily poor judgement. But it sounds like you had a dev team that wasn’t using Scrum, got a Scrum Master and no P.O., and gave the Scrum Master some or all of the P.O. duties. Even as weakly prescriptive as the current Scrum Guide is, that's still not real Scrum. (Moreover, most places that purport to do Scrum also purport to do Agile, and having a bottleneck between the team and client is even more explicitly not Agile than it is not Scrum.) Which is not to say your scenario isn’t a valid illustration of problems with Scrum (or Agile) in terms of the (largely cargo-cult) common behavior going under the name. Its just that in terms of clarity of discussion of what practices should be adopted, its worth noting that the problems being identified are with practices which the Scrum Guide (at the organizational level) and Agile Manifesto (and the broad practice level) are pretty explicitly directed against. Not just in terms of the communication bottleneck but also things like: > tickets taking exactly one sprint to complete This seems to be confusing increments or Sprint Backlog items (for which the dev team is responaible for making from Product Backlog items) with Product Backlog items that the P.O. is responsible for (and also Product Backlog items with client tickets, though the Scrum Guide doesn't explicitly discuss client tickets at all — in fact, it mentions customers only once — and so doesn’t explicitly distinguish them from Product Backlog items. The P.O. is free to, and responsible for, structure Product Backlog items optimally based on achieving customer goals, which is almost never realistically going to be 1:1 with tickets.) EDIT: I want to make extra clear that I am neither disagreeing with the criticism of “Scrum as the thing that I am likely to have imposed on me if my workplace says they are doing Scrum” nor arguing that the Scrum Guide (or Agile Manifesto and principals) are anything like perfect edicts that can only be failed but never fail. I am just saying it is important to recognize the difference between “this failure is caused by a set of practices a workplace adopted under the label ‘Scrum’” and “this failure is caused by adopting the practices described in the Scrum Guide”, eepecially if you are interested in what good practices might be.
  • lolinder 3y ago
    I'm reminded of Ben's question about the shamble-men in The Name of the Wind [0]. It doesn't particularly matter whether people are disappearing because of shamble-men or because of bears and wolves, if people are regularly disappearing in the woods then you'd do well to steer clear of them. In the same way, I don't particularly care if Scrum fails because people consistently fail to implement it "right" or if it fails because it's a flawed concept at its heart. Either way, odds are that my team will suffer if we introduce Scrum: if Scrum isn't fundamentally flawed, it's still hubris to assume that we'll be the team that finally gets it right. [0] > “Listen, if tomorrow we pulled into Biren and someone told you there were shamble-men in the woods, would you believe them?” My father shook his head. > “What if two people told you?” Another shake. > Ben leaned forward on his stump. “What if a dozen people told you, with perfect earnestness, that shamble-men were out in the fields, eating—” > “Of course I wouldn’t believe them,” my father said, irritated. “It’s ridiculous.” > “Of course it is,” Ben agreed, raising a finger. “But the real question is this: Would you go into the woods?”
• systems 3y ago
  I am curious, how did management respond when the progress slowed did they revert back to the old method, did it deteriorate so fast there was no way to stop it, was the team not very important what happened ?
  • lpapez 3y ago
    Their view was that there was no problem, but rather that the new process was an improvement. I am not joking. They said that we didn't measure the work before, so they had no visibility into how much the team does. But after introducing scrum, they were very happy to see that the team usually delivered around 20 story points per sprint, while the other teams in the company did around 10. In my view, if we estimated tickets in old process as we did after introducing scrum, we would have been delivering around 60 points in two weeks through old process.
  • dylan604 3y ago
    this would be an example to be studied in future classes of business school if this resulted in a change like you would hope for. otherwise, it's business as usual, and no, the changes you seek would not happen. i'm obviously turning this into a hypothetical
  • palata 3y ago
    > how did management respond when the progress slowed Rule number 1: management is never wrong. The progress did not slow down.
  • CipherThrowaway 3y ago
    Standard playbook in this situation is everyone involved saves face by blaming the team who were driven out, then they adjust to the new normal and everyone forgets they were ever able to build and ship software.
• Justsignedup 3y ago
  "if everyone is productive, don't hire a manager, promote." applies here. If scrum isn't working for you and you're productive, do more of that. If what you have isn't working, and scrum might help. Do that. That's the point. Don't break something just because others are doing it.
• username332211 3y ago
  > I objected to this and listed all of the problems I could see if Scrum was introduced: losing dev creativity and incentive, tickets taking exactly one sprint to complete instead of doing them at leisurely pace, the mistranslation coming from having one extra layer of communication (Scrum Master handling the client now). And that was your big mistake. Those are real concerns, but those things are abstract and non-quantifiable. The proper way to fight scrum is to measure the time it takes to perform the scrum 'ceremonies'. It's rarely less than 30% of the total work time in a sprint. 50% seems to be very common. In my experience even the dumbest and thick-headed management can understand that. I've always imagined if it didn't I could ask to hire more people to compensate for the time lost, but I never had to resort to that. Granted, you still end up with a mutilated scrum at the end. But if you mutilate it right, you can fit your pre-scrum work process into the terminology of a mutilated scrum.
  • ahtihn 3y ago
    > The proper way to fight scrum is to measure the time it takes to perform the scrum 'ceremonies'. It's rarely less than 30% of the total work time in a sprint. 50% seems to be very common. I do not understand how this is possible. * Sprint planning: 2 hours * Sprint review: 1 hour * Sprint retro: 1 hour * Daily stand-up: 15min / day On a 2 week sprint, 80 hours, that's 5.5 hours spent on ceremonies. That's ~7%. What are you doing that it could ever take _half_ of total work time and how will you convince management that you aren't completely fucking up scrum?
    • spc476 3y ago
      At my previous job, the "daily stand up" never lasted less than 30min, and often times went to 2 hours. Also, I didn't just have one "daily stand up" but two! One with multiple teams, and one with just our team because our manager really wanted to silo our work and ignore as much as possible other teams (especially QA for some bizarre reason). Yes, we weren't doing "scrum" right, but like communism, no one does it right.
      • t43562 3y ago
• Attummm 3y ago
  Scrum master name is supposed to be joke, like dungeon master. They are supposed to lead the process of scrum and stay in the background.
• gumballindie 3y ago
  [flagged]
  • yihtserns 3y ago
    > Scrum _is_ a bit like communism. Each time it fails people claim it's wasn't the real thing. The difference is when people do communism, they actually follow the recipe (and failing), i.e. central planning, one-party state, state ownership, etc. But when you read about people complaining about Scrum, it doesn't look like what the Scrum training taught nor the Scrum guide. (This reminds me of a time when a manager pulled all the teams into a room, then pulled out all the Scrum terminologies and say "now we're going to have a meeting to decide what we want them to mean".)
• karaterobot 3y ago
  Ugh, swapping out a successful development paradigm midstream sounds like somebody up the chain thinks change is the same thing as progress. In situations like this, one strategy I have used (not for Scrum, but for people who want to tinker with shit for the sake of tinkering) is to say: "Great, we welcome experimentation, this is really cool. What will we measure to decide whether this change is improving our process, and how long will the initial round of experiments last?" Because: this frames it as something we are trying together rather than something they are dictating, but also something that is not necessarily permanent, which can be changed in the future (including changed back to the way it was), and which is oriented around measurable improvement rather than arbitrary whims. Almost nobody is willing to be the guy who says "we'll do it my way because I said so, even if it makes everything worse", and if they are, that in itself gives you some valuable information about your manager or leadership team.
  • lpapez 3y ago
    It never occured to me that the change can be framed this way, I will learn from this. I thank you for this perspective kind stranger, truly.