I often get asked, “Can you use agile outside software development? In real business, not just in software teams?”
Most experienced agile practitioners will instinctively want to shout, “Yes! Of course!” But intuition apart, where is the evidence?
Looking at the roots of agile software development—lean, agile manufacturing and organizational learning—then the answer is obviously yes. These ideas originated outside software in the first place.
Many practices in agile also originated outside software, such as stand-up meetings, prioritization, and visual management. In fact, these practices are so common, it is hard to say where they originated.
Some practices that originated in software development have been exported. For example, lean start-up is largely test-driven development at a company level. Other practices—usually technical ones, like continuous integration—are restricted to software development, but even here analogous practices can sometimes be found elsewhere.
While the logic for agile working outside of software is compelling, where are the case studies? First, it would be helpful to define what agile is—or might be.
What Agile Is
Defining agile is a lengthy article in its own right, and the Agile Manifesto is of little help outside of software. Still, everyone has a feeling in their bones about what agile is or should be, often stemming as much from the word agile itself as anywhere else. It’s something to do with flexibility, speed, and reactivity, serving some need.
Consider the words of professor Michael A. Cusumano of MIT Sloan School of Management:
“[Agility] comes in different forms, but basically it’s the ability to quickly adapt to or even anticipate and lead change. Agility in the broadest form affects strategic thinking, operations, technology innovation and the ability to innovate in products, processes and business models.”
This might not be a watertight definition, but it is a good working framework: Agile is about change, speed, and dealing with the unexpected and unpredictable; it involves technology and innovation and ranges from operations all the way up to strategy.
Case Studies
There is good news and bad news here. The bad news is that there aren't many examples of agile being used outside software development. But the good news is that, yes, there are some examples.
Exhibit A comes from Lonely Planet in Melbourne. At the 2012 Agile on the Beach conference, Kate Sullivan presented a case study of how the Lonely Planet legal team adopted agile after seeing technology teams using it. The team used a whiteboard with task cards, stand-up meetings, weekly iterations, and prioritization. They even estimated their work, measured flow, and held retrospectives.
The following year, Martin Rowe from Petroc College in Cornwall described how his team used Scrum to deliver a foundation degree in computer science. Again the team used a board with cards, worked in timeboxes to meet deadlines, and created a product backlog with a burn-down chart. They also held stand-up meetings, but these were only weekly, so there was room for improvement.
Martin went as far as to say, “Even badly implemented Scrum works.” Applying just a little bit of agile can help.
Through the Agile on the Beach conferences I’ve also seen and heard of customer service teams, a public relations agency, and a florist using agile. The business coaches I used to work with at Grow Cornwall have incorporated agile into an entire program they call Agile Innovation, and they even made a video about it.
My own experience of agile outside software came on a project with the GSM Association, where a team used agile practices to write a large technical specification. Despite the team being distributed throughout Europe, they held weekly meetings on Mondays, which both planed the iterations work and undertook some work. Looking back, I now think the working part of these meetings was a little like mob programming.
An electronic tool substituted for a physical whiteboard, and work was structured as a set of stories. The team delivered the specification by deadline, and in the subsequent retrospective everyone believed the agile approach had helped.
One of my favorite cases of agile being used outside software comes from company strategy formation and execution. Keith R. McFarland, writing in MIT Sloan Management Review, described Shamrock Foods Co., a food distributor in Arizona. The senior management team adopted quarterly offsite meetings. The regional managers from around the US would fly in and the team would evaluate progress and execution, review and adjust strategy, then prioritize and decide on the next actions. At the end of the week the managers would return to their bases and follow through on the agreed tasks.
This is agile on a large scale, with senior managers operating three-month iterations with weeklong planning meetings. I can almost imagine them returning home with a stack of index cards. According to McFarland, after the adoption, Shamrock flourished.
Conclusion
These examples are good and represent a diverse set of applications, but they still only illustrate a very small subset of all the organizations out there in the world. If you are looking for an example of agile in your domain, unless you work in software, there might not be one yet. That is a double-edged sword.
It means that if you want to apply agile, you will need to think more carefully and be prepared for more risks. But it also means there is greater potential benefit because others have yet to forge this path. Adopting agile could carry a bigger reward for your organization just because competitors aren’t using it.
Remember the economists’ maxim: Profit is the return for risk. No risk, no profit.
For organizations thinking of adopting agile practices, the first question should be “What do I want to achieve?” Start by asking what the organization needs and work back to the agile toolkit. It is possible that what the company wants isn’t actually a problem agile addresses.
This approach is good for organizations outside software development, but it is an excellent starting point inside software development too.
User Comments
As you know, Allan, Agile is not a methodology - it is just a set of ideas. Outside of software, some of those ideas are often applicable to the situation.
What does not usually work is to take the Agile _practices_ that have become standard today for Web app teams and force-fit those into every situation. Even within software development many of those practices don't always work. For example, for embedded software, it is often not possible to rapidly test a change. The ability to rapidly and cheaply test a change is a foundational assumption of Agile.
One should always be thoughtful about applying Agile practices. Remember that none of the Agile principles or values are prescriptive - they all express that one should find an appropriate, contextual balance.
Quite right. My first Agile experience was with a marketing team, where wed took XP ideas and applied them to creating a marketing campaign. It's rather easy to replace "software" in the Manifesto and Principles with "product or service" and have them work just fine.
Agile software development fundamentally 1) breaks work into small batches and completes each one before starting the next 2) quickly applies the learnings from one batch to the following batches (thus the agility) and 3) optimizes communication among people. The three basic ideas can work in many other fields. "Agile" per se may not, because it's optimized for software, which is relatively easy to change quickly. An interesting article on an "agile" method for early product development of physical products, wher the cost of change is higher than in software: https://www.linkedin.com/pulse/rapid-learning-cycles-throughout-enterprise-when-agile-radeka/
Pages