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.
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
The interesting thing about all these examples is that the item being developed is something that can
That's not to take anything away from any of them, but maybe gives a hint as to when agile can be applied outside software. It would be interesting to hear the first case of a car being developed using an agile approach.
Actually, cars are incrementally developed all the time, incremental delivery is the predominent method in the car industry. So you see new model updates every year, and you see platforms being developer for a new Golf, and then its used again for a Seat, then an Audi and so on. Sometimes they change the engine, sometimes they restyle the outside.
If you want an out and out car development on Agile lines have a look at http://wikispeed.org/
Its wrong to say: "These guys lucked out, they happened to find themselves working on something that was inherently incremental". Rather its a case that the found a way to make it incremental, to do it in iteration.
Too many people are too quick to jump up and say "But my work doesn't conform to this model". You have to find a way to change your work. And if you don't then you comptitors may well do so for you.
Check out Joe Justice and Wikispeed regarding a car developed using an Agile approach.
Also, at the Scrum Gathering Barc elona number of years ago, a German manufacturer of airtomobile seats described how they applied Agile ideas in a modified Scrum context to design the parts for the seats then send the design to those who made the parts, then got them back an reassembled them into the final seats for auto manufacturers.
Good grief. You need examples - are you serious? 'Agile' is used all over the place.
Even my freakin' builder does agile... He and his team of labourers elicte requirements, get the materials, decide priorities for installation, do the work, regularly check back with me on progress, etc, etc. Mind you he doesn't need to plaster the walls with lame-brain dumb-ass Post-It notes to remind him what tasks he's completed and what's next. And he's the first to tell me if things start to slip or costs start escalating.
I honestly don't get why the Agile'istas seem to think 'agile' is so mind-blowingly revolutionary. It isn't and in other industry sectors it's been around in one form or another for donkey's years. Granted it is highly unlikely to have been or to be called 'agile' though, but the underlying approach to product development is much the same.
I don't think you understand Agile very well. You're describing Waterfall pretty well though.
iPod -> iPod Touch -> iPod Touch - it is Agile development as well
What is Agile: http://www.slideshare.net/ishmelev/agileeng
Bit late to the party here, but can you recommend any software applications for managing agile teams that *isn't* software-development centric? I have no need of an IDE, for instance, but I do want assistance controlling development of User Stories, management of sprints and calculation of burndowns, velocity and so on.
There are so many online tools out there I can't keep up. Trello is really quite simple and technology independent.
That said, I really recommend doing it physically with cards and boards to start with: the learning experience is so much richer. When you have some experience with cards and boards then look at tools.
Think of it like this: we teach kids to do maths on paper, with pencils and in their head before we let them have calculators. Teams should be the same.
A great software I have used is Seapine's Test Track (et all). It is very configurable (field names, workflow, etc.) and I have used it on all types of projects- software and non-software.
Pages