Can agile be used for non-software projects?
Agile is a recent philosophy and approach to software development that has changed IT and software by promising frequent releases and a focus on value. But can it be used outside of the software domain? This article will explore this idea, and explain what makes agile work, why it can be effective outside software, and where it might not work for non-software and multidisciplinary environments.
This video might help you understand where agile can be used.
What is agile
Agile is an approach to software development that emerged in the 1990s, in opposition to the traditional plan-driven approach known as “Waterfall”, which came from engineering disciplines and was focused on extensive documents and strict control. Agile instead focused on moving in small steps, adapting to change, and doing small releases that focused on maximum value and learning.
It was popularised by the Agile Manifesto, written in 2001, that specified the four agile values and twelve agile principles that define agile.
So where the waterfall approach splits a big project up into large phases of distinct work (such as analysis, design, development, testing), the agile manifesto authors instead recommend moving in very small cycles or “iterations”. Each iteration should provide a small release to customers, from which the team can learn.
Where the waterfall approach mandates lots of up-front design and planning and tries to capture all requirements as early as possible, the agile approach instead assumes that not all requirements can be known before work has been done. Many software projects learn “as they go”, based on the progress of work, the success of technology implementations, and customer feedback. Agile focuses on value and learning instead of planning and control.
Why agile works
Agile has been very successful in many organizations, because software development and technology have changed. The waterfall approach came out of engineering approaches, which made more sense when software was being built for big companies that were developing software for their staff. Those organizations could rely on training and manuals to ensure people understood and learned the software. Customers didn’t have access to this software.
But with the rise of the world wide web, distributed computing and mobile technologies, companies had to change. Software was now not being used by 20,000 staff but by 20 million customers. Software had to be simple, intuitive, and responsive to changing markets and consumer tastes. Teams had to be able to learn, adapt, and pivot.
Agile manifesto principles also favour early integration and continuous automated testing. This is a much better approach from a technical risk management perspective and allows for more frequent releases. Waterfall projects often suffered from “integration hell”, where code from many developers all got merged at once in the development phase, causing huge merge conflicts and integration testing issues. Agile de-risks work by integrating and testing the software early and frequently.
Agile for non-software projects
Agile was definitely thought of for use in a software environment. In fact, the Agile Manifesto begins with the line “We are uncovering better ways of developing software by doing it and helping others do it”.
So does that mean that the ideas of agile can only be used in a software development environment? Not necessarily… in fact, you may be able to get some significant benefits using agile for non-IT practitioners. Though we need to be careful.
Many of the ideas in agile actually have their roots in Lean! Lean is a much older system of thinking that comes from Japan, and was devised to help improve manufacturing processes. In fact, most of its ideas came from Toyota (yes, the car company).
Lean and Kanban
Lean is a set of ideas around removing waste, focusing on value, and continuous improvement. The key objective in Lean is “flow“: improving the flow of work (and value) from the producer to the customer. Lean practitioners often use “value stream mapping”, an exercise that analyses all the steps from an idea (or request), to getting something in the hand of the customer. You can then measure the steps, identify bottlenecks and constraints and non-value add activities, and continuously optimise and improve the process.
This focus on value, customer and removing waste definitely made its way into agile thinking. And we know Lean ideas work outside of software, since they were invented in a car factory.
A related discipline to Lean is Kanban, which is becoming very popular in agile circles.
And like Lean, Kanban can definitely be used in non-software environments. Kanban is a system for visualising and improving the flow of work through a system. You categorize work into columns and swimlanes, and use techniques like throttling, swarming and WIP limits to increase the flow of work and reduce WIP (Work In Progress).
Kanban is used everywhere, from supermarkets to restaurants to factories. So it can definitely be used in non-software contexts. (If you really want to understand Kanban, I highly recommend David Anderson’s essential book).
Radical Management
An important thing to note about agile that it is not just about work, but also about people. The manifesto talks about building teams of great people and trusting them to get the job done.
Agile practices favor small, focused, cross-functional teams. Groups of people who won the end-to-end value stream of a particular product or service (or part of a product or service).
This is in distinction to the traditional organization structure you find at most large firms: big silo skill-based teams, who aren’t able to deliver anything without handoffs to half a dozen other silo teams.
There is no reason why organizations in any field or vertical can use these ideas.
They can also apply other agile concepts too. In fact, management author Steve Denning has compiled these into a book, Radical Management, which is really about applying agile to business, i.e. agile in non-tech contexts. He defines the concepts of Radical Management as:
- Delighting clients
- Self-organizing teams
- Client-driven iterations
- Delivering value to clients in each iteration
- Radical transparency
- Continuous self-improvement
- Interactive communication.
This book is an excellent introduction to how you could use agile for non-agile teams.
Why agile might not work for non-software projects
There are of course some ways in which you may not be able to apply an agile methodology to non-software enterprise projects.
If you are working in a firm that is dealing with strict requirements (e.g. a project based around compliance or certification), then value and requirements are all locked in up-front. So the iterative and adaptive nature of agile approaches won’t work very well.
You might also be working with clients who want to stay at arms length and control everything through documents and change control. Or you may be working in a heavily regulated industry, such as aviation, healthcare or military, where governance and control are paramount.
Some agile concepts, such as continuous improvement may still apply, but many of the benefits will not be there.
That being said, software projects in those environments will struggle too, so it is more determined by the type of organization, rather than the type of work.
There are also some ideas in agile that simply do not apply to other domains, such as continuous delivery (and its sibling, continuous integration). These are software engineering practices that will simply not apply in many other domains. However, continuous delivery is really a specialized form of the radical management concept “Delivering value to clients in each iteration”, which can apply to just about any project.
So there are some concepts from agile that might work in a general sense, but not if you drill into the specific technical details.
Summary
So agile ideas are primarily focused on software development. That’s where it all came from originally. Nevertheless, many concepts such as a focus on value and customer, increasing flow while decreasing waste, continuous improvement, and empowered cross-functional teams, can apply in other domains. So you may find some good benefits of agile management in a non-software development context.
I hope you found this article helpful! Have you had experience with agile in non-software projects? Let me know how it went in the comments.
