When it comes to agile project management approaches, Scrum is often associated with software development. But some people might want to try and apply the principles and practices of Scrum to non-software projects as well. In this article, I’ll explore the question: Can Scrum be used for non-software projects? I’ll look at the fundamental aspects of Scrum, discuss its flexibility, and consider the benefits of using Scrum in non-software domains.
Before going into the how we could apply Scrum to non-software work, let’s briefly recap what Scrum entails. Scrum is an iterative and incremental framework that allows teams to efficiently manage complex product development by embracing adaptability and collaboration. It emphasizes delivering value early and continuously, fostering frequent feedback loops, and promoting self-organizing, cross-functional teams.
Scrum consists of several key components, including a product backlog, sprint planning, daily stand-ups (actually called the Daily Scrum, but whatever), sprint review, and retrospective. These components form the foundation of Scrum and create a framework for effective product development.
The beauty of Scrum lies in its flexibility and adaptability, making it suitable for a wide range of projects, even beyond software development. Let’s explore how Scrum can be applied to non-software projects:
Like any project, non-software projects require clear goals and deliverables. Scrum helps establish and refine these goals by using the concept of a “product backlog”.
In a non-software context, the product backlog represents a list of desired outcomes, tasks, or features that need to be completed to increase the product’s value. The product owner, typically the project sponsor or a subject matter expert, collaborates with the other members of the Scrum team to prioritize and define the items in the product backlog.
Scrum’s iterative approach lends itself well to non-software projects. Instead of attempting to define and plan every aspect of the project upfront, Scrum encourages adaptive planning and continuous improvement. Project requirements and priorities may evolve over time, and Scrum accommodates these changes by using shorter timeframes called sprints. Sprints, typically lasting one to four weeks, provide the opportunity to plan, execute, and review a subset of the project work.
Scrum promotes cross-functional collaboration, and this aspect can really benefit non-software projects. When working on a non-software initiative, a team with diverse skill sets and expertise is often required. For example, in a marketing campaign project, you might need individuals with expertise in design, content creation, analytics, and project management. Scrum’s emphasis on self-organization and collaboration ensures that team members work together effectively, leveraging their collective skills to achieve project goals.
Continuous improvement is at the core of Scrum, and it applies to non-software projects as well. Scrum teams regularly hold retrospectives to reflect on their work, identify areas for improvement, and implement necessary changes. This iterative feedback loop helps enhance project outcomes, processes, and team dynamics.
Using Scrum in non-software projects could give some benefits:
Let’s establish first that although Scrum is related to the agile software movement, it doesn’t actually talk about software at all. If you read the Scrum Guide, you won’t find any software development terms in there. Like defects, codebases, integration, environments, and so on. So, you should be able to use it out of the box in non-software contexts.
As always, though, you need to take other factors into account before you decide to try Scrum. For example, if your product is in a highly regulated environment (such as medical devices) where there is a lot of governance and compliance, then quickly creating product increments might be hard. Also, if your organization has many layers of bureaucracy and has a culture of detailed planning and predictability, Scrum’s short planning cycles might create friction.
Also, Scrum involves a set of new roles and responsibilities. Most organizations don’t currently have a product owner or Scrum Master. So they might need to spend time and money to retrain their people or find and onboard new hires.
There will probably also be other parts of the organization, like marketing and change management, that might need to spend time getting their heads around Scrum and what it means for them.
Scrum has successfully been applied to a variety of non-software projects across different industries. Here are a few examples:
I really have mixed feelings on this matter. I can definitely see the pros and cons of each side. I understand that the Scrum authors really wanted to increase the reach and applicability of Scrum, to spread it throughout the world. Which I think is a nice idea and I think Scrum has done well overall and helped a lot of people.
However, I also feel that many of the powerful ideas of agile software development, are tied to exactly that: software development. Some notice that Scrum seems to have “diluted” itself, in order to appeal more broadly to any type of work.
So if you compare Scrum to say Extreme Programming, you will find that Scrum seems to be missing lots of the technical practices in Extreme Programming. Things like Test-Driven Development, Pair Programming, and Continuous Integration. This has resulted in a lot of Scrum teams with big backlogs and fancy Jira reports, but products full of defects and technical debt.
But maybe those problems are then more for the software development crowd, rather than the non-software development crowd?
Scrum is a pretty broad set of ideas and can be applied widely, for better or for worse. It really is designed for work that happens under conditions of “uncertainty”. So planning an event, designing a prototype, making a physical product, etc. Not for repetitive BAU type work (in which case, you’re probably better off with Kanban or something similar).
You just to make sure that you understand Scrum and its principles properly. And make sure you have proper experienced and empowered product owners and Scrum Masters. I guess that goes for the software work too!
Have you tried Scrum in a non-software context? How did it go? I would love to know, so please let me know in the comments.