[HN Gopher] The MANY Alternatives to Scrum
       ___________________________________________________________________
        
       The MANY Alternatives to Scrum
        
       Author : rbanffy
       Score  : 34 points
       Date   : 2024-10-01 17:32 UTC (5 hours ago)
        
 (HTM) web link (rethinkingsoftware.substack.com)
 (TXT) w3m dump (rethinkingsoftware.substack.com)
        
       | hyggetrold wrote:
       | Would have loved to see the author include a section on Extreme
       | Programming.
        
         | rbanffy wrote:
         | Still my favorite.
        
       | bm3719 wrote:
       | Probably the biggest disservice done by Scrum was changing our
       | thinking and language around methodology. It made it so that if
       | something was going to displace it, it had to start with a
       | capital letter, be a "real" version of something, and have a lot
       | of institutional momentum behind it. It acted like some kind of
       | social exploit--one we had no immunity to.
       | 
       | So, we ended up stuck with it, suffering untold millions of hours
       | wasted in useless meetings and untold creativity crushed since it
       | didn't fit into the process. We should've just tossed the notion
       | that there's some kind of planning structure that makes sense
       | across all possible projects, then done whatever made sense for
       | our specific environments, not put a name on it, or even talked
       | about "methodology" much at all.
        
         | lloydatkinson wrote:
         | Agile instead of agile, Scrum, Kanban, Scrumban, "shift left",
         | etc are all words that indicate the place has not only drank
         | the kool aid but tried to drown any voices of reason with it.
        
       | inSenCite wrote:
       | All these frameworks and still Common Sense reigns supreme yet
       | rarely applied.
        
         | hermanradtke wrote:
         | Common sense is not common. Common sense is more akin to
         | wisdom.
        
       | __loam wrote:
       | I like how kanban and agile are "alternatives" as if they're not
       | very similar to how scrum it's defined.
        
       | DowagerDave wrote:
       | This is a weird and unbalanced selection... I expected to see
       | waterfall or some variation on here, but nothing like it, even
       | though it is very common. Lots of mentions of evolving & fully-
       | autonomous engineering structures without even mentioning how
       | this interfaces with all the other parts of every company larger
       | than a few people. Valve's approach is not really a methodology
       | vs. a perk from generating ridiculous per head revenues for a
       | pretty small company. Shape up can only work as described when
       | your company is small and run by a benevolent dictator will
       | complete control.
        
       | tuna74 wrote:
       | The subtext of the article seems basically to be that the author
       | does not want to estimate tasks. Which is nice when someone else
       | pays. It is less nice when you have to pay however.
        
         | OutOfHere wrote:
         | Despite what they have told you, that's never a real issue. If
         | the project is divided into small tasks, if progress is not
         | being made on these tasks, the management always has the right
         | to steer the direction of the project or to reassign the staff
         | tasked to it. This is how management can continue to control
         | the expenses. As for estimates, even an AI can give those,
         | probably better than what a human can, and without any stress.
        
           | tuna74 wrote:
           | So if you would hire someone to redo your bathroom or
           | kitchen, you would hire them without an estimate and quote as
           | long as they divide the project into small tasks?
        
             | OutOfHere wrote:
             | That's not a fair comparison at all. A bathroom or kitchen
             | is something they have worked on a hundred or more times
             | before, with little variation. In contrast, software is
             | almost always original. If you ask me to implement the same
             | software a hundred times with minor variations, of course I
             | can give you good estimates without stress.
        
               | bdangubic wrote:
               | THIS exactly is what Software "professionals" have
               | amazingly successfully been able to convince everyone.
               | That somehow what we do is "special" and we just cannot
               | possible tell you how long XYZ is going to take...
               | Software "is almost always original" is the same argument
               | as if an incompetent carpetner would say "sorry, no two
               | kitchens are alike and while I use same sh*t to build
               | them I have never built yours exactly and hence I'll send
               | you the bill when I am done."
        
             | Smar wrote:
             | How often carpenter needs to study while constructing what
             | is the correct method to build to wall, and while doing
             | that, try to find out whether the client wanted the wall or
             | a floor, or even both of them?
             | 
             | Try to give any proper estimations before actually starting
             | that kind of project, when the scope is not known and there
             | is no buy-in to spend half of the time just to plan all
             | little details.
             | 
             | It is not just "give an estimation", but a whole procedure
             | to complete.
        
             | nine_zeros wrote:
             | > So if you would hire someone to redo your bathroom or
             | kitchen, you would hire them without an estimate and quote
             | as long as they divide the project into small tasks?
             | 
             | I love these general contractor analogies because it tells
             | me that these people don't understand software engineering.
             | 
             | Here's an answer for you: the vast majority of software
             | engineering is less like repetitive contracting and more
             | like unpredictable lab experimentation.
             | 
             | It is up to management and business to decide if they are
             | skilled and willing to accept the nature of software
             | engineering.
        
         | paulddraper wrote:
         | Yeah, the real world needs costs, estimates, timelines.
         | 
         | And you can help make them as good as possible.
        
       | ElectricSpoon wrote:
       | This reads like someone which had bad management using effort
       | estimates as hours and bugged the team about it. I'm saying that
       | having seen plenty of environments where they do Scrum wrong.
       | 
       | > Because there are no sprints, you don't have to worry about
       | whether something fits into a sprint
       | 
       | I like fitting things into sprints. It forces tasks to be broken
       | down into manageable items. If it's too big to fit, it's also
       | probably ill-defined. Sometimes it goes over the sprint; it's
       | alright; discuss during retro and learn from it.
       | 
       | > If an emergency arises, everyone pauses their work
       | 
       | You can still do that with Scrum. Scrum is a framework to
       | estimate the effort and measure at fixed points in time. That's
       | not an excuse to dismiss issues. Unless all of your work is
       | unplanned, you can handle surprises AND estimate your leftover
       | velocity.
        
       | davidjfelix wrote:
       | I thought they debunked the "Spotify model" as something being
       | promoted by a few consultants but also being phased out at the
       | same time as being exposed to the public (nearly 10 years ago in
       | 2014).
       | 
       | There are dozens of articles about the problems with matrix
       | management that it introduced.
        
       | 4ndrewl wrote:
       | "When you finish a task, you simply pull the next one from the
       | top of the backlog"
       | 
       | Please, no. When you've finished a task see if you can help with
       | a blocked or in-flight task.
       | 
       | Teams win points for finishing work, not starting new work.
        
       ___________________________________________________________________
       (page generated 2024-10-01 23:01 UTC)