Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Businesses Programming IT

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

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?
This discussion has been archived. No new comments can be posted.

Slashdot Asks: Is Scrum Still Relevant?

Comments Filter:
  • by Rei ( 128717 ) on Tuesday November 17, 2015 @09:22AM (#50946883) Homepage

    ... we develop software the old-fashioned way: incremental improvements to an ancient codebase with fundamental flaws in its core that nobody's brave enough to tackle, with irregularly-scheduled releases set into the production server without automated unit testing.

    At home I develop in a more refined fashion: diving right in without much prep or research, working on it for weeks to months, then finding that the project is 100 times more complex than I expected and someone else has already done it.

    • by sbaker ( 47485 )

      Scrum will neither fix nor cause the problems of an aging, poorly-maintained, ill-documented code base. It makes no statements about what you do when you're handed something like that. Only you (and your budgets) can decide whether to wipe it out and start again, or have a program of continuous cleanup, or decide to patch problems as they arrive and build onion-like layers of code to hide the inner ikkiness. But, once you've consciously chosen a path, scrum can help you predict and measure progress - whe

    • At home I develop in a more refined fashion: diving right in without much prep or research, working on it for weeks to months, then finding that the project is 100 times more complex than I expected and someone else has already done it.

      Lol, I'm gonna print that out and frame it. :)

    • This reminds me of an old advertisement from the 70's, from an investment house named Smith Barney: the aristocratic actor John Houseman announced:

      "At Smith Barney, we make money the old fashioned way . . . we earn it!"

      In these Halcyon days of Internet bubbles and fortunes, it seems even more poignant.

      • by Ken D ( 100098 )

        and here I thought they did it by having a very extensive and expensive schedule of fees.

        • by leonbev ( 111395 )

          Shh... Don't run the illusion of the "good old days", where bankers were supposedly honest and not motivated screwing over their customers for profit.

    • by Kinthelt ( 96845 )

      OMG, I think you're in the cubicle next to me!

  • by barlevg ( 2111272 ) on Tuesday November 17, 2015 @09:26AM (#50946909)

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

    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)

  • First thought: what the hell does a Lucas Arts interpreter have to do with s/w development methods?

  • by jfdavis668 ( 1414919 ) on Tuesday November 17, 2015 @09:28AM (#50946931)
    We were running a Scrum project to replace a very poorly designed software system. The people running the project were very skilled, and the scrum team came together well. This was a large project, and took time. As people rotated off the project do to various reasons, the replacements were not as excited about the method. Finally, the program manager moved on, and his replacement killed the project. We went back to trying to add features to the previous system. Scrum is a major change in mindset, and often hard to maintain over time.
  • by halivar ( 535827 ) <[moc.liamg] [ta] [reglefb]> on Tuesday November 17, 2015 @09:29AM (#50946935)

    Scrum works best when you break it and make it yours. As with ANY methodology, do not allow process to interfere with progress.

  • yes (Score:4, Interesting)

    by Kkloe ( 2751395 ) on Tuesday November 17, 2015 @09:31AM (#50946949)
    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.
  • by paulpach ( 798828 ) on Tuesday November 17, 2015 @09:32AM (#50946955)

    When done right, scrum is fantastic methodology. I know this from my own experience. However, I have not see many teams master it. They usually cut corners, or "adapt" it to their own preconceptions that end up breaking the process. They often don't do the retrospective meeting, or do it improperly so they are not able to get better at it, and get stuck carrying over user stories iteration after iteration.

    I don't think scrum and open development have a lot of overlap. They are each suitable for different types of projects. Open development works great for open source projects that a lot of people would have interest on. Scrum works great in small teams developing for particular verticals within a company that would have limited application outside.

    Things can always be improved of course, I would not say scrum is the ultimate methodology, but it is a pretty darn good one, and we are yet to see better ones.

    • by sbaker ( 47485 ) on Tuesday November 17, 2015 @09:40AM (#50947011) Homepage

      I'm still a fan of scrum. I love that it gives the engineer the final word on schedule. No more "You have three weeks to do X."...now it's "How long will it take?"...and the truly awesome part is that it gives lazy team members no place to hide - and gives the team the incentive to meet the deadlines they imposed upon themselves - or have a damned good reason why they didn't.

      I agree - in the last couple of jobs I've had that did scrum well - it really helped. I think it can be adapted to fit individual team's needs - but the huge mistake most people make is to start off by adapting it. My advice - jump in with both feet, use the standard scrum methodology - and after you've been doing it for several sprints, decide where you want to dial it back, amp it up or modify as needed. For example, in my previous job, planning poker worked really well - it was a way for the team to look at stories and say "I think you've missed a shortcut that would save you some time"....or...."I think you're missing a potential problem *here*.". But in my current job, the team is full of specialists in different fields - and that cross-pollination doesn't happen - so planning poker just doesn't work.

      The point here is - try the whole thing - THEN customize as needed.

  • by jcdr ( 178250 ) on Tuesday November 17, 2015 @09:40AM (#50947005)

    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.

    • Scrum has no long tasks. The very first and most fundamental step in Scum, or any agile process really, is to break down long tasks into smaller tasks.
      • by jcdr ( 178250 )

        I agree. The reality is that not all tasks can be easily break down into smaller task before starting the development. An example is porting and integrating a existing code on a new platform. The only way to get the relevant information is to start working on it.

        • So you have a planning task to get in there and figure out what tasks need to be done. That's exactly what I'm doing right now in s major upgrade project. The rest of the sprint my time me is filled with research and planning tasks and the outcome will be a huge suite of epics and user stories mapping out dependencies that will fill several sprints for my team.

          The request was "upgrade the platform to version X" and my planning task means we now have several months of work mapped out that can be rebalanced a

          • Our 'planning task' took a dozen programmers 4 months staring at and experimenting with the codebase before we even knew enough to start splitting the work into tasks. Even then we had things that obviously couldn't be guesstimated with any sort of accuracy or split into small parallel workflows with any hope of measuring progress.

            Some projects are just so fscked the only method that works is hitting them with the sharpest sticks you can find till they give up.

      • by JustAnotherOldGuy ( 4145623 ) on Tuesday November 17, 2015 @10:08AM (#50947213)

        Scrum has no long tasks. The very first and most fundamental step in Scum, or any agile process really, is to break down long tasks into smaller tasks.

        "Okay, you type the first 5 letters, Bob, then Steve will finish the name of the function call. Jack and Nick will add the parentheses and semi-colons. Mary will press the RETURN key when it's time for a new line. Okay team, GO!!"

  • by Anonymous Coward

    If i wanted a devotion meeting I'd join alcohoolics anonymous thank you.

  • Horses for courses (Score:4, Insightful)

    by grahamtriggs ( 572707 ) on Tuesday November 17, 2015 @09:49AM (#50947055)

    Imho, the biggest "flaw" with agile development, is that it is - if not selling itself, seen as by many as - being everything to everyone. You can take a bit of this or leave a bit of that, but this is the right way of doing things. And it all gets wrapped up in terminology (agile, velocity, etc.), that suggest that the process will be faster and better.

    But different processes have different strengths and weaknesses. Sometimes it's more important to put in design effort upfront. Sometimes it's most important to make the most efficient use of resources (e.g. not wasting time doing things based on a narrow requirement knowing that you'll need to change it later), sometimes it's important to be able to adapt to changes, and knowingly change requirements based on feedback. Agile methodologies only really address the last one.

    The best results will come from understanding what the project needs, and choosing the methodology that best addresses that, not from always trying to fit one methodology to every project.

    • Agile's biggest problem is that it is bloated. It tried (tokenly) to be this lean development methodology but it keeps getting burdened with more and more cruft. Same problem every time: some company nobody has ever heard of announces that by forcing all developers to speak only in haikus during scrums, they increased productivity by 12.86%. Now every company feels the need to adopt that. A year and several increasingly-bullshit announcements later, we all have to have scrums from 9:18-9:33am Eastern Martia

      • by Cederic ( 9623 )

        Hmm. Forced haiku. I like it. I like it a lot - brb, off to change a meeting invite..

      • I hate to pull "No True Agile", but a methodology that puts process above people and working code doesn't live up to the Agile Manifesto. (Hmmm. Agile Manifesto is six syllables, and therefore has to go in the middle line of the haiku. This will be tricky.)

        - Black Davidbeard

  • We know you don't read TFA anyway. So really, why bother linking to it at all?

    (For those of you who "are new here" and actually want to read it, the article is available here on OpenSource.com [opensource.com]

  • All engineering is iterative in nature. If Scrum is dead (read as iterative, incremental development), then software engineering is a myth.

  • "What do you think? Is Scrum still a viable approach to software development, or is it time to make way for a different process?"

    NO.

    It's definitely time to come up with a new, trendy name that hides the fact that most programming is, in fact, a solitary sport, even if done by teams of coders all stuffed into a common room.

    I propose "SUCK", "BALLDROP", "HOPELESS", and "VOID" because none of them stand for anything and they all sound cool when uttered in between slurps of brogrammer's favorite energy drinks.

  • We're using Scrum. One of the many variants of it.
    A simplified version of scrum suitable for agency work.
    Simply getting around a board, away from the keyboard, standing, talking (timeboxed) writing cards and moving them around makes things better and enhances team communication and interaction.

    That the overblown hype and overengineering and the holy wars about how scrum is to be done is over is a very good thing.
    Hype ends, Scrum remains.
    I think it's a very good think that this was a big fasionable thing and that Agile (sometimes contradictory to Scrum btw.) brought back the focus on results and regular customer interaction.

    • We're using Scrum. One of the many variants of it. A simplified version of scrum suitable for agency work. Simply getting around a board, away from the keyboard, standing, talking (timeboxed) writing cards and moving them around makes things better and enhances team communication and interaction.

      That the overblown hype and overengineering and the holy wars about how scrum is to be done is over is a very good thing. Hype ends, Scrum remains. I think it's a very good think that this was a big fasionable thing and that Agile (sometimes contradictory to Scrum btw.) brought back the focus on results and regular customer interaction.

      I've never actually worked with a team that has done scrum properly. It's usually poorly managed and a waste of time.

      • According to Sturgeon, 90% of all software teams are crap whether or not they use any particular methodology.

  • by tech49er ( 824086 ) on Tuesday November 17, 2015 @10:15AM (#50947277)

    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.

    • by Anrego ( 830717 ) *

      Definitely A.

      If your testers, upper management, and customers arn't on board, you end up with exactly what you said.

      Personally I think scrum works if you arn't religious about it. Take the bits that work, introduce it slowly, don't get hung up on the "proper" way of doing something. As you said, the core principles are sound, and I'll add that a lot of the management tools built around scrum are pretty decent. Building often makes sense, testing incrementally makes sense, letting the customer see things ear

  • ATTD (Score:4, Informative)

    by Tomahawk ( 1343 ) on Tuesday November 17, 2015 @10:20AM (#50947309) Homepage

    The developers here changed from Scrum to ATDD (Acceptance Test-Driven Development). Throughput it up, quality is up, morale is up...

    They also ran a couple of tests, with one group solving problems using Scrum and another using ATDD. ATDD won every time (although in some cases just barely).

    Just sayin'

  • Union or League?

  • I've been at two companies in the last six years that are trying to implement Scrum. The first failed miserably, due to massive management interference. The second is in progress now, and seems destined to fail (although I certainly hope not!). This company promotes hyper-active micro-managers, who operate in a mode that is the antithesis of Scrum.

    In both these cases, I see the biggest benefit of scrum is that it would prevent the micro-managers from interfering with development that is in-progress, and

  • TFA doesn't seem to have anything to do with Scrum, except to say that they don't like it, and are proposing a working group be gathered from Open Source developers to come up with something to replace it. I've never been at a company that actually "does" scrum, they all just use Scrum, and Kanban and Toyota Lean, and Continuous Deployment and 100 other buzzwords in various combinations. Rallying against Scrum is like complaining about companies using YAML instead of JSON in their config files for their E
  • Once anything as trivial as a type of meeting or process gets hyped to the point of being capitalized as a proper noun, it's screwed.

    No matter how well intended and thought out the underlying principle, once it gets 'adopted' it will bear no resemblance to the vision that it was created with.

    If something is more concrete, specific, and is in no way able to be 'interpreted', it has a chance, but words like Scrum, Agile, Epics, et al are screwed.

  • Scrum is used all over the place and where it is used it tends to work fairly well - assuming its used in moderation. The problems for scrum is there are a lot of bullshit, harebrained concepts & jargon which heap process upon process and make the whole thing a pain in the ass - e.g. social contracts, waste snakes etc. Keep it simple and it's quite tolerable and productive.
  • Read my title. Says it all.

    You want process in software development, you start with industry standard, and that's still Scrum. Unless your project only has 10x programmers (who will get a sprint's worth of features done in a day no matter what). For those types, the better process will always be no process at all. That's the magic behind the genius: nobody understands it, it Just Works. And so does Scrum for the rest of the world.

  • Really when you get down to it it's about 4 things Talking- nobody can go weeks out of communication Trusting - you have to trust that your teammates arnt idiots Respect- don't waste others time or resources Reflect - yes you need to go over what happened and what went wrong and right What I find is agile is some times go fast and stupid and breaks the above ideas but the name agile makes it sound like the point is speed when it's a side effect
  • by cellocgw ( 617879 ) <cellocgw@gm[ ].com ['ail' in gap]> on Tuesday November 17, 2015 @02:35PM (#50949581) Journal

    Can't resist pointing out that, despite its stated objective,Scrum usually makes things take longer, not shorter. That means working Overtime, known as "OT" . Thus:

    ScrOTum

If in any problem you find yourself doing an immense amount of work, the answer can be obtained by simple inspection.

Working...