People will ask, “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? Allan Kelly found some examples and shares how agile works in environments outside software.
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.
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.
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.