Agile methodologies such as Scrum in non-software development projects

Apart from ashes999 great answer there is one more notable mention of how to introduce Agile into non-IT organization or team. I really like the part about not going with all the buzzwords and working mainly through Agile values perspective.

There is a 5 step method according to this post: https://teamhood.com/agile/agile-for-non-it/

1. Educate people about Agile values
2. Define roles and responsibilites
3. Create centralized work backlog
4. Form and practice Agile habits (techniques/ceremonies/etc.)
5. Make Agile cycles (sprints) predictable and of repeatable success

Example of not IT-opinionated language for Agile

Well, "all of the above having now been said," I now appreciate the wisdom of an e-book called "Managing the Mechanism," which made the observation that computer software is "an autonomous, self-directing machine."

"The team's" task is, of course, "to produce computer software." But, when "the computer software that they have produced" finally gets put to use – "the team that produced it" is ... powerless. They've been forced to retire to the locker-room while the robots which they have created actually play the game.

I've never seen this little e-book in paper. But it was an eye-opening change of perspective for me. Neither "a well-designed can opener" nor "a production-line robot" is ever expected to be ... "autonomous."

Agile works best when operating in the Complex domain.

The Cynefin Framework classifies projects into four domains: Simple, Complicated, Complex, and Chaotic. Agile works best when you're working in the Complex domain.

In the Simple domain, you're working with a well-understood area and you're able to complete it simply by following a set of rules and procedures. For instance, assembling Ikea furniture would be a project in the Simple domain; you're just following the instructions in the box.

In the Complicated domain, you're dealing with known unknowns, and you can produce a result by finding out what those are and then getting to work. A lot of engineering work is in the Complicated domain, and Waterfall works well for projects here.

In the Complex domain, you're dealing with unknown unknowns, and you need to be able to flexibly change your course to adjust for them, which is why Agile works best here. Software engineering mostly falls into this domain, which is why Agile is so popular in that field, but it's possible for other projects to do so as well.

In the Chaotic domain, you're dealing with a situation where you can't establish the information in a cohesive fashion, and you have to act to impose order; an example would be firefighters attending to a burning building or police attending to a riot.

So, to answer your actual question, simply re-frame it as such: Are the problems in the Automotive industry Complex?

An open question this is indeed. Also, there isn't one good answer to it. All you can do is trust others' opinion on whether this will work, or try for yourself and see how it goes. I recommend the latter. Having said this, I can take role of the "other" and recommend a quick read on why agile methods will work for any business: https://kanbantool.com/blog/bringing-agile-into-non-tech-environments Whether you take on scrum or kanban is another question - in my experience, kanban is easier for first-starters, but scrum can bring more structure to the workflow if this is what you need, but I wouldn't start with it right away.

When you ask about Agile outside of the software industry what I go back to is the work done by W. Edwards Deming in manufacturing. One of his core principles was the Plan-Do-Check-Act cycle. AKA the Deming Cycle. This cycle along with his 14 pints and 7 deadly sins are the foundation of the much of modern manufacturing process and were key to the rebirth,and success, of manufacturing in Japan post WWII.

With its emphasis on an iterative process and focus on quality of product, rather than post production QA, Deming's work is the logical starting point for applying Agile outside of software development.

By taking Deming's work and adding to it the Agile principles around sprints, velocity, frequency and retros you get a working hybrid for non-IT applications. You additional get 60 years worth of accumulated experience in manufacturing processes that work.

It is entirely possible to apply agile principles and the Scrum process outside of software and is being done in a variety of environments.

The recent Scrum Beyond Software conference held in Phoenix during September 2010 explored this topic in great detail in an open space format. As an attendee, I was among a number of people sharing their experiences using Scrum in different environments including education, marketing, sales, and government. I've personally coached a marketing organization towards applying the Scrum framework towards their campaign planning and implementations, and know of at least one sales team actively applying Scrum (and using software project management tooling effectively in doing so).

Additionally, I'm personally aware of two sessions that have been accepted for the Agile 2011 conference related to the application of Scrum beyond software development. One applies to Scrum in Sales, and the other applies to Agile in Academics. There may be many others I've not noticed.

(Note: I'm not sure of the longevity of these links after the submissions process closes for Agile 2011. As both are accepted, the experience reports will eventually be published in the conference proceedings, which is published by the IEEE)

Most of Agile methods are development methodologies. If you take Extreme Programming, for example, it's obviously impossible to apply it in another domain than software development.

Scrum, on the other hand, is a way to organize a project team. It's really good suited for software development teams, but there is no reason why it wouldn't be suited for project team in other domains than software development.

Edit: I just discovered Jugaad, which could be relevant to your interest. Take a look at the official website: http://jugaadinnovation.com/

There is also a book: http://www.wiley.com/WileyCDA/WileyTitle/productCd-1118249747.html

Jugaad is a way to consider innovation in a frugal and agile way.

Ken Schwaber actually released a book called Agile Project Management with Scrum that runs through a number of case studies in industries outside of software development.

This is pretty much an open question at this time, and as Agile evolves I think we can expect to see greater use of it outside software development settings.

See this discussion for a good blow-by-blow: https://stackoverflow.com/questions/1702128/can-i-use-agile-in-a-non-development-project

BTW, I'm going to be pedantic: scrum is an Agile tool. Also, Agile was designed for software projects - there's no shift in focus as you suggest.

There are two main tenets of Scrum that, in my opinion, define it and tell you the worth of it for any project or product. Those two are: changing requirements and iterative releases.

There are many great posts on this site about Agile vs. Waterfall. The bottom line is that Waterfall is amazing if you can gather all the requirements up-front, and they won't change much. The hard part is getting those requirements right, on paper, before doing any of the work.

This means that waterfall would apply very well to industries like automobile, healthcare, aerospace, etc. where it's easier to clarify up-front what exactly you need.

On the other hand, iterative releases are very, very useful -- even with fixed and un-changing requirements. You could theoretically do it, but I don't see what benefit you'd get out of it.

Instead, I would focus on some other useful parts of Scrum, such as:

• Estimating tasks in vaguer units (story points) instead of time -- if requirements are unknown and/or changing.
• Breaking work down into small units that can be completed in a week or two, or less.
• Communicating daily across the team to say "here's what I did yesterday, what I'm going to do today, and what I got stuck on."

Your mileage may vary. I would say look at Scrum/Agile, and start pulling those practices that you can see will benefit you.