How to Apply Agile to Non-Software Work

The concept of “Agile” has been tied to software development mainly because of the 2001 publication, The Manifesto for Agile Software Development (a.k.a. the “Agile Manifesto”) which popularized this idea. Written by a group of software professionals, this artifact helped many teams apply a new way of working, which arguably revolutionized the way software applications are designed and delivered.

What is not commonly known is that the philosophy and values behind this Manifesto originated decades ago from manufacturing; Toyota Motors was the very first organization that conceived values such as short feedback loops, optimize flow of work, limiting work-in-progress, etc. This also means that the concepts and practices of Agile can be applied to almost any type of work that you do – from recruiting to marketing to business development, Agile practices can accelerate the delivery of nearly any product or service.

This sounds too good to be true, correct? Let’s take a closer look at a few examples of how Agile techniques can be applied to non-software projects.

Agile is NOT just for software?!

In my experience working with Agile teams over the past few years, I discovered a trend that is somewhat surprising – many people believe that “Agile” is synonymous to “Scrum”, which is not the case. This misconception has often led to the belief that if you want to “do Agile”, you must “do Scrum”, or apply Scrum-like practices. This is simply not the case. It is very possible to apply Agile principles and practices without adhering to the guidelines offered by the Scrum framework. Why does this matter, you may wonder. This is an interesting take on the Agile approach because you can apply Agile practices without practicing all of the events that Scrum requires, which means that Agile is potentially much simpler than you imagined!

How to apply Agile techniques even if you are not developing software

Here are a few practices (and questions) to consider when you are working on a non-software/non-technical project:

Start with what you do now

There is no need to abandon everything you do today for the sake of “doing Agile”. It is entirely possible (and likely) that many of the processes and/or tools that you are using today provide value and are quite effective, even if you have a desire to improve what you do now. It is absolutely okay to keep many of the tools and procedures that are already in place. The trick is to explore what makes sense to change. More on that shortly.

Consider where your pain-points are

What is keeping you or your team up at night? Where are the inefficiencies? What do your customers complain about the most? These are all questions that could lead to interesting insights if you dig a little deeper and spend some time to assess the root cause. These repetitive issues will likely provide you with a great starting point to apply Agile methods. A few examples are: long feedback cycles, lack of visibility into state of tasks and/or projects, quality issues, scope/requirements creep, etc.

What work can you complete in a short period of time?

Looking at the work your team is doing, how can you break down the work into smaller units? This may take a bit of experimentation, but if you can deconstruct work into less complex pieces, you could improve your ability to deliver a working solution more quickly, thus giving your customer an earlier view and the opportunity to provide feedback.

How often does your team reflect on how they collaborate?

When was the last time they thought about how to improve their processes and/or tools? Agile way of working is inherently iterative in nature, which means there should be natural checkpoints for the team to inspect their way of working and make adjustments as needed. The mindset of continuous improvement is not always easy for teams to adopt, but it will provide benefits once the team can establish a healthy routine of regularly reviewing how they work together.

How much work is your team trying to do at the same time?

Multi-tasking is a big “no no” in Agile because it takes away focus and erodes customer confidence when you start a lot of work but finish very little. Limiting your “WIP”, or Work In Progress, is one of the key tenets of Agile that is often forgotten. Reducing your WIP sounds easy enough to do, but it is often quite difficult for most of us who are accustomed to doing so, and it will require practice and persistence.

How often do you showcase your work to the customer?

Providing visibility and being transparent about successes and failures is not always easy, especially if you have a demanding customer who is used to getting what they ask for. A key tenet of Agile is close collaboration with the customer, which means partnering with them and being open and honest about everything. Again, not always easy to do, but it will build trust and confidence over time if you can work with the initial challenges.

Conclusion

In closing, you may have noticed that in this article, I did not suggest any technical practices that are specifically related to any Agile framework. While some of these ideas may feel a bit vague and general, I am hoping that you can find a real-world project with which you can try some of these techniques. You can see that none of these approaches are specifically intended for software projects, which means they can be applied to just about any type of project that you are working on. My final recommendation: choose a project that is not too small but not mission-critical so that you can apply one or two of these methods as an experiment. If you can make a commitment to giving this a try, I guarantee that you will learn something unexpected.