Slashdot Mirror

← Back to Stories (view on slashdot.org)

Scrum/Agile Now Used To Manage Non-Tech Projects

Posted by samzenpus on from the best-practices dept.

jfruh writes "Agile and, in particular, Scrum, have been popular project management methods for software development for more than a decade, and now its use is spreading well beyond software. For example, NPR is using Agile for faster, cheaper development of new radio programs. 'I was looking for some inspiration and found it one floor up inside our building (where Digital Media sits),' says NPR vice president of programming Eric Nuzum. NPR has used this 'Agile-inspired' approach to create several new programs, including TED Radio Hour, Ask Me Another, and Cabinet of Wonders."

8 of 136 comments (clear)

  1. What if... by MonoSynth · · Score: 4, Insightful

    What if Agile is better suited for other tasks than software development? I think Agile is an elegant way of approaching some kinds of creativity, but it just doesn't seem to work for most aspects of software-development.

    Making radio shows is more of an iterative kind of creativity with lots of loosely-coupled ingredients where throwing away an item and replacing it with another won't destroy the whole format, so you can start off with a format, broadcast it, and add/remove items as you go.

    Software is completely different. You create it once and after the first release you have to support it for eternity. Every new addition adds another layer of complexity, you can't just remove a feature without breaking other things or add a feature without duplicating functionality. For every iteration you'll need an overview and a deep knowledge of the whole system.

    1. Re:What if... by RD_Sid · · Score: 3, Insightful

      I think Agile is more of a "getting things done" sort of a methodology. It doesn't care what you're developing or how stable the thing will be. It just forces you to create and manage something which can't be created through a static set of rules. For e.g. you don't need Agile to assemble a car, it's all taken care of by machines. But you can apply Agile to the unprectictable areas, be it S/w, management, research etc.

    2. Re:What if... by todrules · · Score: 3, Insightful

      So true. The biggest proponents of Scrum/Agile are the "instructors." It's just propaganda to make you think that Scrum really works. While it might look great to the MBAs and other execs, it just doesn't work in the real world, at least at any company that has a budget and wants to actually make a profit. I'm sure it would work beautifully on side projects, non-profit projects, etc... where you're not concerned about money, though.

      Oh yeah, and a case in point on the GP's propaganda:

      I no longer think of developers as professional if they fail to use these practices.

      So, he resorts to telling programmers, basically, that they're not professional if they don't use Scrum. Trying to appeal to that person's guilt and shame. Sorry, but I don't fall for these "shame" tactics. Just a tactless, tasteless ploy to try and lure people to Scrum.

    3. Re:What if... by JDG1980 · · Score: 4, Insightful

      Actually, top individual contributors are tasked with two separate part-time jobs. So, no, they don't get paid a lot more for this.

      For some people, being tasked with two separate jobs is more stressful than being able to focus on one specific task. This is true even if the total hours are the same (and I'm rather skeptical that this is actually the case in practice).

      Furthermore, the skills needed to be a good programmer are different from the skills needed to be a good trainer. Many of the best programmers aren't exactly very social types.

      What you're doing is driving away and/or burning out your best programmers by making them do a job they probably don't want to do, aren't very good at, and essentially punishes them for their talent.

  2. Re:Architecture by Anonymous Coward · · Score: 4, Insightful

    The fundamental idea of Agile is that you do things incrementally, see how they work and then fix the problems afterwards. This is based on the (definitely somewhat valid) claim that it's easy to change software after the fact but difficult to know in advance what the best solution to a problem is. Moreover, the idea is that you can properly test a piece of software to see that it does more or less the right thing before using it. Basically it's saying that the hardest part of software is the design and it may be worth trying different ones and throwing them away as they fail in order to be sure that the design is sound.

    Architecture is different. It's very difficult to change a building after you have poured the concrete. If you try building a concrete building without incuding steel to see if it works and then it falls down with people in it then that will not be acceptable.

    In other words; the consequence of applying true agile methodologies to Architecture is likely to be well deserved jail time.

  3. Creativity Killer by mnt · · Score: 3, Insightful

    Working in the game industry i found that creativity was heavily hampered by scrum, even after doing several adjustments to the process.

  4. SCRUM stands for SCRrewed Up Management by nickmdf · · Score: 3, Insightful

    ... especially when non-technical people are in charge of this process. One can't map short term deliverables properly to a creative process.

  5. My biggest problem... by pauljlucas · · Score: 3, Insightful

    ... with Agile is the "Daily Stand-up." I don't care what anybody else is doing on a daily basis. Actually, for most people, I don't care what they're doing -- ever. All I care about is that people I work with (1) answer e-mail in a timely manner and (2) if I depend on their work, that they'll have it done when they say they will. (If they're going to miss a dead-line, only then do they need to bring it to my attention.)

    What some other set of people whose work I don't depend on is doing in no way helps me do my job. I'm paid to do my job, not concern myself with everybody else's job.

    --
    If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.