Slashdot Mirror

← Back to Stories (view on slashdot.org)

Slashdot Asks: Is Scrum Still Relevant? (opensource.com)

Posted by samzenpus on from the best-practices dept.

An anonymous reader writes: In an article titled "Scrum is dead: breaking down the new open development method," Ahmad Nassri writes: "Among the most 'oversold as a cure' methodologies introduced to business development teams today is Scrum, which is one of several agile approaches to software development and introduced as a way to streamline the process. Scrum has become something of an intractable method, complete with its own holy text, the Manifesto for Agile Software Development , and daily devotions (a.k.a., Scrum meetings). Although Scrum may have made more sense when it was being developed in the early '90s, much has changed over the years. Startups and businesses have work forces spread over many countries and time zones, making sharing offices more difficult for employees. As our workforce world evolves, our software development methods should evolve, too." What do you think? Is Scrum still a viable approach to software development, or is it time to make way for a different process?

12 of 371 comments (clear)

  1. Scrum Was Never Alive by Anonymous Coward · · Score: 1, Interesting

    Scrum wanted to be many things. But, wishes don't always come true. Very few ever cared about Scrum. Scrum was never a "thing", so you can't really call it dead as it was never alive. But, those few that love it are still using it.

    1. Re:Scrum Was Never Alive by DennisZeMenace · · Score: 2, Interesting

      "It also tends to get misused by management who see it as a way to micro-manage developers thereby pissing off the very developers upon whom they are depending."

      This really sums up my experience with scrum meetings..

    2. Re:Scrum Was Never Alive by Anonymous Coward · · Score: 2, Interesting

      a dirty snowball of design layers with no overall architecture produced

      That is absolutely required by Agile. Agile demands that if something takes more than one Sprint that you must not do it. Any big architecture problem that takes more than one Sprint cannot be done with Agile. I was fired from my last job for taking sixteen days to finish a JIRA issue. I almost got it done and out of QA in time. In our Sprint planning meeting, we scored it as a forty and used twenty as the basis for a Sprint. Even though the issue had to be completed in order to deliver to a customer, the certified scrum master that worked for our board of directors would not allow it to be worked on. He was doing good Agile, but it ended-up killing the company since we lost our biggest customer.

      Agile cannot produce good software since by definition you can't do anything that takes longer than a Sprint. And, if it wasn't for the nearly an hour a day we wasted in Scrum, I might have finished it on time. Of course, there were more JIRA issues that would have taken more than one Sprint so I would have probably just failed later due to Agile.

    3. Re:Scrum Was Never Alive by Jahta · · Score: 5, Interesting

      I can see where it might be useful in certain situations. However, when it gets used with other Agile fluff to simply produce a dirty snowball of design layers with no overall architecture produced, then it becomes a headless snake. It also tends to get misused by management who see it as a way to micro-manage developers thereby pissing off the very developers upon whom they are depending.

      Well I've worked on a lot of successful scrum-based projects (full disclosure: I'm a certified scrum master). Done right it's a very effective and enjoyable way to work. But there are some pre-reqs if you are going to succeed.

      • Everybody has to buy into it; developers and customers. Some people like waterfall because you can fudge a lot in big rambling requirements and design documents! On an agile project the emphasis is on personal responsibility and accountability..
      • You need to have a basic usable architecture "blueprint" in place _before_ you start to code. If, on day one, everybody is scratching their heads wondering how they are going to build then you're in trouble. If everybody understands the blueprint then the discussion moves on to delivering the actual customer requirements. And you can always tweak the architecture as you go, if you need to.
      • You need a team of skilled self-starting developers (not coders, testers, analysts); there's no place for "that's not my job". In my experience good developers love the challenge and the ability of the team to self manage. Others just want to be told what to do.
      • Continuous build is essential. The two basic rules are, if it's not in Git it doesn't exist and if the builds (and test suites) are failing it doesn't work. There's no room for fudging; the build server's dashboards don't lie!
      • As a scrum master, one of your most important tasks is to keep traditional "management" out of the developers hair. If they want progress reporting, I point them at the online scrum board (user stories and burn down charts) and the build dashboards. That's actual progress that they can check anytime they want.

      If you do it right, then you can be very productive and have fun doing it. Unfortunately, there are a lot people who have made half-assed attempts at "agile" and then rubbished it when their projects failed.

    4. Re:Scrum Was Never Alive by Anonymous Coward · · Score: 5, Interesting

      I personally found Scrum and Kanban annoying in this respect:

      1: The meeting to tell your "stories" is a time-waster when done more than once a week. Daily, it is pointless.

      2: The "what you did" scenario. It becomes listing everything, relevant, or non, so your manager doesn't think you are slacking, and pits you against other developers or IT people.

      3: The "what you are going to do today" crap. SSDD is the proper answer for that.

      4: The "what is blocking". This translates to "point the finger." As a dev, I learned the hard way that "blocking" means a game of "hot potato" where if you or your code can, in -any- way be used as an excuse for others to not do their work, expect to be training a H-1B fresh off the boat to take your job soon. The "blocking" phase turns into a "The Apprentice" boardroom meeting right before someone gets tossed.

      As for code quality, look at the garbage coming out on average. People thought waterfall coding was bad... but code quality when that was the main method was, in general, far better than the Scrum based systems, just because Scrum mainly is used to pit devs against each other, as opposed to actually creating something.

    5. Re:Scrum Was Never Alive by phantomfive · · Score: 4, Interesting

      Mythical Man Month talked about this. It points out that with a small team, any development methodology can work.

      Scrum is fine, but let's not pretend it's some kind of miracle.

      --
      "First they came for the slanderers and i said nothing."
    6. Re:Scrum Was Never Alive by bluefoxlucid · · Score: 3, Interesting

      Functional (run by department heads), matrix (weak matrix, balanced matrix, strong matrix), and projectized.

      In weak-matrix organizations, the project manager is often a facilitator. Balanced-matrix departments start defining the project manager's level of authority, giving him the explicit right to requisition resources under the sponsor's authority: your VP of Engineering gives you the authority to requisition 4 engineers for 16 hours per week from the Engineering departments under him, to communicate with other departments to gather requirements and interface with stakeholders, and to spend money within a given budget, all tied to the scope of the project.

      The project manager's job still remains the same in all cases: find the most efficient way to plan and execute the project. If he has no power, he has to take it back to department heads and VPs--to the sponsor--to lay out recommendations for action. That includes who to hire, what to buy, how to schedule, and so forth. The decisions are ultimately made by whoever has the vested authority to make them, which may not be the PM.

      This should be obvious, considering "push deadlines" is a meaningless phrase essentially expressing "I don't know what I'm talking about".

      --
      Support my political activism on Patreon.
  2. Silicon Valley Did It Best by barlevg · · Score: 4, Interesting

    https://www.youtube.com/watch?v=oyVksFviJVE

    Watched this with my wife, who, while also in tech, never worked at a workplace that used Scrum. She cracked up and thought it was the funniest thing she'd ever seen. I sat next to her, stone-cold silent. She asked why I wasn't laughing, and I said, "Dude, that's MY LIFE." All that's needed to parody Scrum is... an accurate description of Scrum.

    Of course, in that episode was that Scrum actually worked for them (it probably helped that all the devs worked in the same office)

  3. yes by Kkloe · · Score: 3, Interesting

    Scrum is still used, people dont understand that scrum is to be adapted to the people/software you are working on, many combine scrum or use just parts of it, I know alot of big companies that use a combination of waterfall and scrum when doing safety critical machinery and there is like here in our company were we use just parts of it, we made it fit how we work and what we are developing.

  4. Prone to promise too much by jcdr · · Score: 4, Interesting

    While scrum could be effective to prioritize a lot of small tasks that can be complete in a few hours, we found it useless in situation where a long task must be developed. In the later case the peoples try to say the minimum because there are afraid of hitting unexpected difficulties that will slow there work, and scrum is not a place to change the design, so there feel like in a trap.

  5. Re:The Scrum Master is a big con by sbaker · · Score: 3, Interesting

    In my last job, scrum-master was a task that was rotated through the team. Each sprint, a different team member takes on the responsibility. This gave everyone a better insight on what the job entails. After doing that for six months, it became clear who the right people were for the job - and it rotated around maybe three or four members of the team rather than all of us. New team members usually got handed the job for one sprint after they'd been with us for a couple of sprints.

    Paying someone to be scrum-master is only worth-while when that person masters multiple scrums - and goes to scrum-of-scrums...and so forth. For most small teams, you don' t need that as a full-time role.

    As for the scrum master "barking orders"...whoever thought that was what you do didn't read the scrum guide! The scrum master is a clerk - a book-keeper - and a keeper-of-rules - a servant of the team - not some kind of manager. If you give the scrum-master managerial power over the team - then you're not doing scrum anymore.

    If you don't do scrum by-the-book, don't complain when it doesn't work. You're perfectly entitled to modify the system - but be aware that when you do so, you're not "doing scrum" anymore - you're doing some kind of pseudo-scrum - and when your pseudo-scrum breaks down like this, you have only yourselves to blame.

    --
    www.sjbaker.org
  6. Scrum is fine in theory by tech49er · · Score: 5, Interesting

    The core principles are fine:
        1) Frequent communication means nobody drifts too far out of scope
        2) Breaking a large problem into small problems is something you should have learned before you even started university
        3) Gives nervous business stakeholders an insight into the development process

    But it doesn't work in most settings for these reasons:
        A) The broader business doesn't engage (becomes sprints within waterfall)
        B) The engineering organisation doesn't engage (usually because they don't feel they own it)
        C) It's too complicated - it's the core principles that matter, not rote adherence or form filling

    Too many moving parts; too many new concepts; too many new ways of doing things; for too many people; who aren't necessarily interested and/or sufficiently trained and informed.

    You CAN make Scrum work - if and only if - everybody gets on board and you take a large hit up front while everybody adjusts to the transition.

    Most businesses can't and won't do this.

    --
    "... always going forward 'cause we cant find reverse! "