Does Agile Work for Non-Software Projects?
How agile can work for non-IT teams.
One frequently asked question I get about agile is: ‘Can agile work outside of software projects?’
Short answer: Yes.
Long answer: Yes, and here’s why …
As agile missionaries, our decisions and actions always revolve around these 4 core values, popularly known as agile manifesto:
- individuals and interactions over processes and tools
- working software over comprehensive documentation
- customer collaboration over contract negotiation
- responding to change over following a plan
These points show you what agile prefers. How you make them happen however, is up to you. If we swap the word ‘software’ in point 2 to ‘complete body of work’, you’ll find that the thought process and values that come from following the manifesto applies to virtually any project and industry.
Let’s break down these values point by point.
1. Individuals and interactions over processes and tools
Imagine a scenario where you chase an approval that’s been pending for a few days, only to be greeted by a classic ‘waiting for email reply’ response. You find the person responsible for the approval only a few steps away on the same floor. You come around their desk, and after a short conversation they immediately approve the action — and you’re left wondering ‘if that’s all it took to get approval, why did it take so long? The answer: delays caused by text-based communication.
I cannot stress hard enough the importance of direct communication with your colleagues. Direct chats cut so much communication overhead, even compared to teammates who sits in the next room separated by a wall/partition. Face to face interaction should always be the prime choice, followed by video/audio call. If all else fails only then should you choose text communication. One way to encourage this is to have co-located team members.
When people sit together, something magical starts to happen — they start talking to each other. Face to face conversation happens naturally and ideas get exchanged way faster than you can write emails. Now the room becomes a communication highway and everyone is happy. This type of communication benefits any situation where you need to get things done — no matter if you’re in advertising or movie production. Bottomline, direct interaction saves time and increases collaboration, so it pays to invest in making it happen.
2. Working software over comprehensive documentation
As we only have so many hours during the day to do work, it’s always a good idea to spend them on things that bring most value. Although this point mentions software and documentation, what it’s actually saying is to focus on what matters most. We see documentation as something that supplements software releases. It’s important, yes — but as important as it is, working software always trumps the importance of complete documentation. After all, what good is documentation when you don’t even have a working software? I thought so.
No matter the nature of the project — whether it’s software, marketing or anything else — you can always break down the to-do list and prioritise them based on value. Once prioritised and shared with your team, the chances of your team being busy working on non-essential tasks is greatly reduced, and they start being way more productive in focusing on what matters first. Once you have the essentials, only then should you focus on the supplements.
For the next task you or your team picks up, ask yourself if there’s anything else that’s worth doing more. If there is, you know what to do.
Pro tip: you can start using kanban wall to start plotting the to-do tasks based on their journey.
3. Customer collaboration over contract negotiation
One main purpose of our work normally boils down to making someone at the other end happy — it can be a customer, a colleague, or even a distributor. This point highlights the importance of collaborating with anyone who benefits directly from our work. The main idea is instead of having an ‘us vs them’ attitude, we look to have everyone on the same side by having them involved in discussions as early and as frequent as possible. We take an inclusive way of working, instead of exclusive.
When we involve others in our activities, a healthy interaction will start to happen. Instead of blindly following what’s written in the contract, our interactions with them give much better understanding about their needs. We get first-hand insights on how our actions affect them — information we can never learn from reading a piece of paper. Soon enough, trust will be established and you significantly cut down issues caused by miscommunication or assumptions.
This method of working can benefit you even if you run food stalls, where the people you want to make happy is your foodie customers. By involving them into your business plans, you’ll have good insights on how to serve them better, which brings in more customers and ultimately, income.
4. Responding to change over following a plan
One potential pitfall in software projects, or any other projects, is thinking you can control changes — changes in preference, changes in technology, changes in customer behaviours. What you know about your customers now may not apply next month. These are factors you have no control over, and the variables that make up the scale of those changes are endless. So what do you do?
Since the only constant in life is change, it makes sense for us to also change. Instead of resisting changes, let’s embrace them.
What’s important here is having the mindset that to be the pack leader, we have to constantly evolve. If we look at how fast fashion giants like H&M and ZARA roll out new collections, you’d immediately know that they’re in it to win it. They constantly monitor the market and tap on any new trends at record speed. This is why you see shoppers flock their stores in droves — to get most current clothing items.
On the flip side, we’ve also seen the rise and fall of giants who failed to change with time. I’m talking about the likes of Nokia & Blackberry. Once upon a time their phones dominate a significant chunk of the market. Everyone was exchanging Blackberry Messenger PINs or on their Nokias playing Snake. Now, they’re in the footnote of many case studies that talk about why companies fail.
Moral of the story: when it comes to responding to changes, no one is safe. Not even the giants. One question remains — how far are you willing to change to get ahead?
Now that we’ve established how agile can work outside of software projects, it’s just a matter of how you choose to apply it to your business.
Of course being agile takes good intent and consistency. Or there’s even chance that you’re already agile without even knowing it. Either way, if you’d like to properly introduce agile to your company but not sure where to start, I’ve also written a piece on how to help you get started HERE.
