Can Agile and Scrum be applied to non-software teams?

This article has been updated on March 2023 by Content Specialist Dominika Kuraś-Moskwa.

Is Agile older than the Internet? Software development anthropologist Gerald Weinberg, the author of The Psychology of Computer Programming and Introduction to General Systems Thinking, introduced incremental development for the first time in 1957 at IBM, Los Angeles. Even back then, people realized that waterfall project management wasn’t the only option. Okay, maybe that’s not the Agile framework we all know, but nonetheless, these ideas have been around for a good 60 years. Evolutionary and adaptive approaches emerged in the early 1970s, and all the methods that are now described as Agile have been in use since the 1990s. But the actual Agile Manifesto came out in 2001, the Scrum Guide was published in 2009, and just during the last years, this concept has become such a buzzword and gained mainstream recognition as a way to boost corporate responsiveness. Why’s that?

As a general mindset of getting work done, Agile is pretty straightforward, universal, and versatile: we need to adapt to change quickly, know our maximum capacity, and be transparent about what we’re doing and what’s blocking us on the way. But the reality is harsher. The 16th State of Agile report found out that while 4 out of 5 organizations are using Agile development practices, only 20% are very satisfied with them in their company. This can happen when the case has not been modeled properly, and thus doesn’t reflect the team’s workflow. It can also occur when the decision itself hasn’t been well thought-over. 

That’s about software development teams. And what about those who don’t code? Why would they want to work in short iterations and be prepared for changes in the requirements anytime? The general aim of this approach is to focus the team’s effort on accumulating value and managing capacity. These rules are universal for every team delivering services or products. That’s why the adoption of agile practices is possible in teams like marketing, sales, or legal. Which often rely on timely communication and short-term goals. The last years’ experience shows that the HR and supply departments also gain much value by amending their practices through agile frameworks. An additional positive effect can occur in terms of meeting cross-team deadlines thanks to greater synergy.

It’s interesting that some Agile practices originated from non-software and IT environments. The Agile coach and author Allan Kelly mentions that daily standup meetings are usual among the restaurant staff. Something we know as pair programming is a common way of working for surgeons or aircrew. But is the Agile process really a good choice for every possible team out there?

The Agile methodology can be applied to the development cycle of products like computers, medical devices, food, clothing, and even music. Basically, everything that can be released in versions and continually improved. The variety of Agile applications is really astounding. Even if we do some simple web surfing. To begin with, there’s a famous 2013 TED Talk by Bruce Feiler, the author of The Secrets of Happy Families. He tells his story of running a family and raising kids using the Agile methods.

On a side note, a couple of years later Matthew Jeffrey from Atlassian wrote about a similar approach. Apparently, simple things like regular meetings and chore checklists work miracles when there’s an overwhelming amount of work to do and no time for communication. After that, Newton Lee outlined Agile music production in his compilation called Digital Da Vinci: Computers in Music. Based on the fact that musicians also rely on some kind of technology to record and produce their compositions. He compared each part of the creative process to its counterpart in the software area, and this way produced outstanding results that landed in the U.S. Billboard charts.

If these examples seem more like poetry to you, let’s move to the more practical ones. During the Jira Day Remote Edition, Karolina Brunet from AstraZeneca gave a presentation. It described a pharmaceutical company that implemented Agile methodologies and tools for clinical data management. Despite the very structured and sequential design, it turned out these types of projects benefit a great deal from the experiment. It increased the company’s competitive advantage through fast test iteration and rapid response to change.

Another famous case presented by Kate Sullivan at Agile on the Beach 2012 was the Lonely Planet legal team. They tried to cope with overworking, multitasking, lack of transparency, and managing lots of internal stakeholders. Each having their own interests. In short, what saved them was one-week iteration cycles with daily standups. As well as a Kanban board with a backlog, work-in-progress limits, color codes for different types of projects, and sub-columns inside statuses for different priorities. The board evolved over time and got adopted among other teams inside the company.

Industrial production benefits a whole lot from Lean manufacturing and Kanban techniques – and, in fact, invented them. The iconic Harvard Business Review article from 1986, The New New Product Development Game, described the cases of Toyota, Canon, Honda, and other Japanese companies. They improved deliverability, and introduced the term Scrum, comparing their teams to the rugby team divisions. This was the game-changer that reportedly inspired Jeff Sutherland to bring these principles into the software area. A more recent example, that depicts the experimental nature of Agile practices, is the Mission Bell Winery. The experiment that meant to just help with Safe Quality Food Level 2 certification. It turned out to be a performance booster. As the distribution team finally could take their time to improve the way they work. Because of this, loading productivity increased from 411 to 425 cases per hour in just 3 months.

Even given all the positive effects resulting from the agile approach, we should keep in mind that it doesn’t solve all the aspects of managing a project. For example, Agile is not very useful in large investment projects like construction and shipbuilding. There are many teams that rarely talk to each other, and one Project Manager supervises the whole thing. So Waterfall methods are more applicable. But what’s interesting, even in such large projects, some smaller ranges of work in which Agile will do well can be found. In the shipbuilding industry, when the schedules are delayed, the finishing jobs such as air conditioning and interior should be carried out quickly, so then Agile can be used.

Apart from that, Agile projects rely on the availability of specialists like designers or architects throughout the project timeline. When waterfalling, after specs’ phases are complete, their contribution is rather occasional so that someone’s absence isn’t mission critical. Also, in such projects, it takes more time to communicate across different functions and specializations. Especially in companies where processes and products are highly complex.

So Agile practices can be inefficient in large organizations and in terms of those types of products that can’t be versioned or iterated quickly. Managers believe that agile methodologies by the book are too extreme and tend to adopt hybrid approaches, depending on their particular situation. This is called method tailoring – every company is different, and so is their attitude to getting the work done. There are even examples of codified mixed frameworks like Scrumban. Team members abandon the time-limited sprints but stick to the product backlog and Scrum rituals. In software development, this is useful mostly for app maintenance and ongoing bug fixing.

There are also cases where a team needs to put aside the agreed agile practices to work towards a deadline. This is a somewhat extreme case of feature freezing. The team stops accepting new projects until the important release. This happened once to our Apps team when they were migrating the codebase of Requirements & Test Management for Jira from Cloud to Server. Also took place in our Marketing team when we had to double the sprint length the week when Jira Day Remote happened. In fact, many will argue that this is the true spirit of Agile where even project squads can emerge and dissolve each sprint. But in many situations, having a strategy in place and planning things well ahead is also important – that’s why there are all kinds of mixed approaches. In the end, a vague roadmap is better than no roadmap.

Definitely not! If you’re considering trying Agile practices with your non-software team, here are a couple of tips:

Remember that each team is different and has various needs, workflow, or requirements to meet. Before implementing any solutions, you should analyze them carefully.