Project Management: It’s Scrum or Nothing, Says New Study

A lot of attention is paid to Scrum, but how widely used is it? According to a new study, it’s the leading project management methodology. The second most widely used is… well, nothing at all.

SlashData’s latest Developer Economics study touches on project management practices to gauge which are actually in use. Scrum leads the way, with 37 percent of respondents saying it is utilized at their company.

Digging further into which project management methods are used, the catch basin category of “Agile-Waterfall hybrids” (which SlashData notes as ‘Scrummerfall’ or ‘Waterscrum’ (terrible names, by the way)) scored 21 percent, while Kanban checks in with 20 percent. Waterfall was used 15 percent of the time, and Feature-Driven Development (FDD) hit 10 percent.

Both Lean and Extreme Programming (XP) scored nine percent. Adaptive Software Development (ASD) and Scrumban are in use by six percent of developers, and Dynamic Systems Development Method (DSDM) landed at three percent.

Around 19 percent of respondents say they don’t use any specific method for side projects, which is to say they’re not beholden to a particular methodology. While they may use Scrum at work, their own side projects or freelance work is less organized.

Interestingly, 23 percent say they don’t use any specific project management methodology for any project. This suggests not only is this group not making an attempt to use any specific project management method in their own projects, they don’t use it at work, either. (The percentages add up to more than 100, presumably, because SlashData allowed respondents to select multiple options: “Our data reveals that developers tend to follow multiple methodologies across their projects (2.7 on average),” states the report.)

As SlashData also notes, this data encapsulates all developers, both professional and amateur. It says pros use Scrum some 45 percent of the time, while Agile-Waterfall hybrids and Kanban are both used 25 percent of the time for professional projects. From SlashData:

It appears that it takes a certain amount of experience for professional developers to appreciate the benefits of iterative project management styles and to embrace some of the leading agile frameworks like Scrum, Kanban, and, by extension, Scrumban. The adoption of Scrum almost doubles as experience in software development increases from less than a year to at least six years (from 27% to 48%). So does the adoption of Kanban (from 14% to 29%) and of FDD (from 6% to 12%). FDD, much like other agile frameworks, is an iterative process built around making progress on product features and is, therefore, a not so intuitive method for less experienced developers who are naturally more accustomed to linear processes.

The report goes on to note: “Agile has already taken over the software world.” It seems the alternative is nothing at all, at least for the developer world at-large.

18 Responses to “Project Management: It’s Scrum or Nothing, Says New Study”

    • +1. Saying a team uses scrum vs actually following scrum are very different. The data presented in this article only establishes what teams say they leverage. The last line “The report goes on to note: ‘Agile has already taken over the software world.’ It seems the alternative is nothing at all, at least for the developer world at-large.” also seems out of scope in the article context. Scrum and Agile are conceptually related but are not synonymous (e.g. Many methodologies, almost all the methodologies listed in bar graph, are considered under the agile umbrella).

  1. Arnaldo Souza

    It is not mencioned in this article that the kind of Project is software development.
    For other kind of projects like capital projects it will be impossible to use pure scrum or Kanban tools.This must be clear and is not.

  2. Talha Masood

    There is a lot of ado about Agile / Scrum in software industry but I fail to understand how these agile enthusiast almost tend to forget the enterprise software implementation domain (e.g. ERP or CRM implementations) as if that is not part of IT or software domain….. Agile fails miserably over here because of not being able to extract out “Independent” (not having any dependencies) Sprint backlog items, means in ERP projects, you can’t have a 2 or 4 week sprint backlog which can be actually “shipped” to the client at the end of Sprint.

    • Sujit

      Agile is merely a model and scrum, xp, kanban… are different flavour of Agile. People who had practiced traditional project management, we read this as risk mitigator to software development processes as opposed to our original responsibility of project risk mitigation from stakeholders perspective.

      In India, small and medium enterprises were unable to pay for project managers and used to recruit one or two junior developers and generally the finance officer used give them small chunk of programming work for development, testing and deployment very informally. I see the same is put into a process definition and practice.

      Adapting Agile should be a consus decision from project stakeholders perspective. At times we find deviation in adopting any model but that should be accepted, if justified. A guidelines is a guidelines only. An innovative project manager should have the freedom.



    Could you please provide further information on the population? Quantitative and demographic?

    I didn’t find a direct link to the study either.

    I’m using the cellphone and I may have missed the information.


  4. ciroBorrelli

    Scrum is a framework, over than a methodology, so it needs to be ‘filled’ with practices. We usually fill some Scrum fwk steps (phases) with agile practices from other methodologies, such as: pair-programming, code-review, code-refactoring, stories-poker, clean-env, pomodoro-tech, and others. In few words, our implementation of Scrum includes practices from other Agile fwks

  5. Pablo OS

    It’s nice to see Scrum adoption leading all over the SW world, even if (not knowing how this data was collected) we should consider all those who say they’re implementing Scrum, but are actually doing: Scrumban, Waterscrum or any other combination of methodologies.

    However, becoming the “de facto” software project management methodology, does not turn Scrum into a pack of sacred rules, that you should follow blindly. As far as I can say, the ultimate decision on the adoption of any Scrum flavour, should be a wise decision taking into consideration their specific environment. Nonetheless, keeping Scrum as goal or at least as a reference to compare “where” and “why” they’re doing differently, is important, not only for the value of its proposition ‘per se’, but also because of its validation, discussion and knowledge generated over many and different context all over the world, enabling you to seal over waters where you can predict favour and contrary currents.

  6. Chicken Plucker

    When you think about Kanban, try to describe the differences between it and no project management at all. There are essentially none. It’s a free-for-all with a tiny bit of paint sprayed on top so people can claim they are actively managing “a project”. Scrum forces you to be organized for at least the length of a sprint and not let people continually break in and shove their priorities to the front of the line. I think we’ve all had those people / departments that think they should always get to do that.

    Waterfall is the tail wagging the dog and is what you find more often in large organizations with a huge, tyrannical PMO that has to continually self-justify their worth and their ego. It’s the most demoralizing type of project management philosophy I’ve ever worked with and just one of many reasons I avoid working with Fortune 1000 companies.

  7. Agile was developed to tackle difficult, complex software development as an improvement yo waterfall for those types of projects.

    It’s no wonder this article tosses around stats but doesn’t indicate project types as for example a cloud ERP project might be better with waterfall if it’s not complex and the organization has done this before with good results.

    Also as pointed out earlier Agile is a framework not a method. Scrum is a similar. Kanban, burndown charts … Those are practices for the dev team to earn value or gain throughput and score that.

    IMHO nothing beats a very impressive product manager who can corrall the stake holders and work with the dev team to indicate what in the product backglog truly consititues value in the eyes of the market for the product.

  8. Eric Woerner

    Just a couple questions – maybe I’m not getting the article or understand statistics…
    If the chart shows percentages, why does it add up to 178%?
    Why does the title state “Scrum or Nothing”, when there are other things people use – As shown by the numbers that aren’t Scrum or Nothing?
    If was allows to give multiple answers, how can you have percentages? If you do allow multiple answers, why don’t you just show the number of responses with an explanation that there were multiple answers.
    Just wondering…

  9. Randy Buchholz

    There is no such thing as Agile Project Management (outside of a Marketing department). Projects are big pictures with defined goals and defined/planned steps/tasks used to achieve these goals. Agile is a sequence of tasks, defined “on-the-fly”.

    Think of it like vectors. A Project is a vector defined by a start point and an end point. You move along the vector, adjusting your endpoint and position on the vector. You can track your progress. Agile is a series of vectors, each with a (local) direction and a “force”. You work (apply force) over time ( e.g., a sprint) and see where you end up. Then you do it again. And again, and… There is no overall “management” or goal to track against.

    A project is also the coordination of many organizational units – marketing, legal, production, etc. I can’t imagine a daily stand-up with representatives of all of these organizations showing up every day.

    A Project looks at the overall set of work, Agile looks at pieces of work. Simple example, Say you have to sort 10,000 items (the Project). An Agile team (limited by sprint duration and resources) can sort 1,000 over a sprint. How many sprints will it take to sort the items? Think about it. Likely dozens. Each sprint produces a local result, not a global result. A Project takes all of the items at once, and applies the resources required, for the time required to produce the global result.

    Anyone saying they do Agile Project Manager understands neither Agile nor Project Management.