If you’re just getting started with agile and you don’t work in IT, one of the first questions that comes to mind is, “Can agile only be used for software development?”
Agile is a mindset and an approach to building products, solving problems, and managing projects. Agile started as a movement among software developers, but case studies show that it can just as well be used by organizations, teams, and individuals outside of the software development field.
In this post, I’m going to give you my best definition of agile, as well as share some of the best use cases for non-software companies using agile ways of work with you.
If that sounds like what you came here to do, keep on reading.
What Is Agile?
Above all, agile is a mindset.
Agile started out with the Agile Manifesto. A document created in 2001 by 17 of the most influential programmers, who went on a ski retreat in Snowbird, Utah, got snowed in by a blizzard, and, instead of skiing, started exchanging their ways of working with customers.
The members of the group found a striking amount of commonalities between how each built products and managed projects. Most everyone of the people present at the meeting had been researching the success stories and case studies of lean manufacturing in the 20th century, trying to identify what in the lean approach made some of the world’s top manufacturers successful—and which aspects of it could be replicated in software development.
The co-signers of the manifesto had, in different ways and from different angles, come to the conclusions that:
Instead of creating big designs upfront and planning projects end-to-end, it was better to divide the time to complete projects into timeboxes and make adaptive plans for each timebox. This allowed them to welcome change at any stage of a project and control risk more effectively.
Instead of writing comprehensive documentation, sometimes hundreds of pages long, it was better to build small pieces of the product in versions and get them in the hands of the customers. This allowed them to seek out customer feedback about what worked and what didn’t early and often; not just when 100% of the product has been built.
Instead of negotiating long contracts with tens of if-this-then-that clauses for every scenario imaginable, it was better to communicate and collaborate with the customer. This allowed them to determine what features and enhancements to the products created value and which didn’t, helping the customer and the programmers make better decisions about what to work on.
The group summarized their conclusions on the 68-word Manifesto for Agile Software Development, which they later published at agilemanifesto.org:
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Manifesto for Agile Software Development
In the days that followed, the storm passed and the weather conditions finally allowed our group to do what they had gone to Snowbird to do in the first place: ski. But the conversation from that stormy afternoon stuck—and they expanded it by writing down the 12 principles behind the Agile Manifesto.
We follow these principles:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity–the art of maximizing the amount of work not done–is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
The 12 principles behind the Agile Manifesto
The Agile Manifesto gave rise to the agile movement. The fact that most of the co-signers had blogs and books on software development, senior positions or consulting engagements at some of the biggest companies at the time, and a following among the programming community, helped.
Today, agile is the de-facto way to build products, solve problems, and deliver projects in complex situations where the variables are so many and their relationships are so entangled, that you can’t predict the outcome of your actions from the start.
How Agile Works
Companies that operate in agile ways make plans and deliver on them differently than those that follow a more “traditional,” command-control and top-down approach.
In an agile organization, the role of the leadership team (and of all leaders across the organization as a whole) is to:
- Set a clear vision, mission, and goals that represent the interests of all stakeholders;
- Make capital allocation decisions about what initiatives, programs, and projects to sponsor;
- Build, sponsor, and support a network of agile teams that self-organize to achieve the vision, mission, and goals that they’ve set;
- Push as much ownership and responsibility over the “Why,” “What,” and “How” down to their teams—and unblock delivery with strategic decisions and tactical trade-offs;
- Make decisions that maximize the value of the work being done, create a smooth cadence of delivery, and lead to a sustainable pace.
Organizations have different ways of building networks of agile teams. Most often, these ways are driven by and connected to their business planning and budget allocation cycles.
Doing so enables them to make capital allocation predictable, keep track of delivery successes and failures, and exercise just enough control over budgets and risks.
The role of an agile team (and the individuals that are part of them) is then to:
- Deliver value by working in short cycles and shipping useful and valuable chunks of products, solutions, and projects early and often;
- Seek out feedback from the customer and their use of the product, learning lessons and adjusting their plans along the way;
- Take ownership over as much of the “Why,” “What,” and “How” and be accountable about the way of working and delivery outcomes;
- Proactively unblock themselves or quickly escalate impediments that are preventing them from making progress;
- Continuously improve their ways of working by making small changes that pay big dividends over time (also known as kaizen).
Simply said, agile is about achieving a balance of ownership and a cadence of delivery between the people who lead the vision, mission, and goals and the people who make the plans and drive the outcomes within an organization.
As you can see, this approach works as much on software initiatives as it does on non-software initiatives. And there are a number of case studies within companies across sectors and geographies that demonstrate it (which we will look into shortly in this post).
Why Agile Works
An agile approach works, especially for complex initiatives, programs, and projects, as it lets you manage change and control risk more effectively than when the traditional, big-design-upfront, end-to-end-planning approach.
When complexity is in play, agile works better than a traditional approach because it is a more suitable control system for products, problems, and projects in which you can’t predict the outcome and plan the implementation from the start.
In the early days of Scrum, the most popular agile framework, co-founders Ken Schwaber and Jeff Sutherland collaborated with industrial process control scientists at DuPont, one of the leading chemical companies in the world.
In the 20th century, DuPont experienced a number of disasters in its plants worldwide. After the Bhopal disaster, a gas leak that exposed 500,000 residents of a city in India to methyl isocyanate gas, DuPont hired the world’s best scientists to prevent problems of this magnitude from happening again.
The reason why Scrum worked so well, Schwaber found out, was in one of the first principles of industrial process control theory. According to industrial process control theory, there were generally two types of processes: predictive processes and empirical processes.
Predictive processes were complicated, but could be run as an assembly line. Every step of the process had a highly predictable outcome with little deviation. Predictive processes could be run with a predictive control system where every step, its inputs, and its outputs, could be planned in a linear and sequential way.
Empirical processes were complex and their outcomes were difficult to predict. These processes, like mixing chemicals in a vat and exposing them to high temperatures to trigger chemical reactions, required close monitoring and continuous adjustment. Empiric processes had less predictable outcomes with high deviation. They required a different, empirical control system.
“In every case of an exploding chemical plant,” Scrum co-founder Jeff Sutherland recalls his and Schwaber’s learnings, the process control scientists had found “that somebody had applied a predictive control system to an empirical process.”
Agile (and agile frameworks as Scrum) are empirical process control systems. They work best for complex products, problems, initiatives, programs, and projects—where the outcome is hard to impossible to predict from the start.
Even though the agile mindset and approach emerged among software developments, they are just as applicable beyond the software development field.
Examples of Agile Use Outside of Software Development
Let’s explore two examples of companies that work in agile ways and don’t do software development as their core business.
In 2012, the National Public Radio (NPR) in the US began using an agile approach to creating new radio shows.
“Historically, the way that NPR and others in public radio have produced big programming is we come up with an idea we think is really good, we hire a staff, we keep all this very cloak-and-dagger secret, and then we try to make a big launch with it, and we end up with 30 stations and then over time more stations add to it,” Eric Nuzum, then-VP of Programming, told Nieman Journalism Lab.
The problem with this big-design-upfront approach was that it often led to big (and expensive) failures. “Using that process, it takes years to determine if something is going to be a hit or not. And that involves millions and millions of dollars.”
To come up with the agile approach to radio programming at NPR, Nuzum and his team took note of agile software development—and the adaptations of agility in the media industry at companies like HBO, who were known for their iterative approach to programming.
Instead of coming up with big ideas for radio shows and launching them nationwide, NPR started sponsoring small, Minimum Viable Shows, that they often pre-recorded and aired in a small number of markets. That allowed them to test the responses of their audiences and determine if these shows were showing signs of early success or failure before deciding on which one to allocate bigger budgets.
In the story at Nieman Journalism Lab, Nuzum goes on to share examples of radio shows piloted using this process that had begun to achieve major listening and retention metrics among the radio network’s audiences. “Whether [these shows] have a future or not, I’m really proud of what we’ve come up with,” he said. “The bigger experiment is the process…This wouldn’t have been possible a couple of years ago.”
In a case study titled “Owning the Sky with Agile,” training and consulting firm Scrum Inc. tells the story of how the Swedish defense & aerospace company Saab Defense uses an agile process to develop new hardware and software for their fighter jets.
According to the case study, Saab Defense used an agile approach “at every level and in every discipline” of its Gripen E fighter jet program; from developing the software and engineering the hardware to designing the plane’s fuselage.
As a result, Saab Defense created an agile framework of its own, called the “Saab Agile Framework,” which contained agile practices from lean, Scrum, Extreme Programming (XP), and others. Some of the key values and principles of that framework include:
- There is minimum organizational hierarchy and all efforts are on transparency;
- Decisions are driven down to the level of the team doing the work where possible;
- Teams are empowered to take decisions both in process and technology terms;
- Vision is translated into action through clarity; and clarity is achieved by each team understanding what is desired (not expected) from them;
- Customer feedback is sought out in regular and incremental releases of the Gripen E fighter jet and its components;
- Saab Defense aims to build agile teams that have a common rhythm and a stable pulse;
- Increment targets are established each quarter with a “top-down meets bottom-up” approach;
- Each increment ends with a well-defined delivery aimed at verifying and validating the product.
These are the notions of the Saab Agile Framework that stuck with me. Which ones made an impression on you? Check out the case study and let me know below.
The Bottom Line
It’s a myth that an agile mindset and ways of working can only be applied in software development. Yes, agile started as a movement among software developers. But, from its very beginning, it was grounded in the principles of lean and customer collaboration, all of which were created in a number of companies across industries in the 20th century.
I hope that these two examples serve to illustrate that. If NPR can pilot new radio shows and Saab Defense can build new fighter jets using agile methods, the chances are that your business can be transformed through greater agility as well.
If you’re curious to read on why and how that can happen, check out our recent article “How an Agile Mindset Can Help a Company Succeed.”
