I'm looking for a simple explanation of Agile for someone outside of software (Marketing, Sales, Office Assistant)?

Agile is a mindset of bringing together multiple perspectives on a team closest to the problems to come up with solutions with efficient flow and transparency.  It requires collaboration and trust to enable the highest performance.   Think about the difference between how Marketing approaches a problem and how the IT Department approaches the problem.    Marketing typically has many creative minded team members with different specialties who work together for a common objectives.  The work is measured not by dates, but by the results (feedback from customers, sales, brand equity).  A high performing Marketing team is probably already Agile.    IT typically is a back office operation and is not customer facing.  Though there are opportunities for creativity (new technologies and approaches), risks and costs are talked about more than increasing revenue or brand equity.  Therefore on time and on budget is the primary measurement.  This is typically a Waterfall environment.   Think about the best thing you ever worked on in your professional career.  It probably involved working with people in your area of expertise and others outside of your area of expertise.  You worked together well and you trusted that everyone was competent not only in doing their job, but had each other's back when necessary.  The process you followed was less important than the people you did it with.   Just imagine an organization taking on that mindset.  That is called Agile transformation.

Company A and company B are given FRPs for a trouble-ticketing system.After reviewing the RFP responses, the requester selects company A, which uses an older software development methodology such as waterfall. 'A' is thrilled and sends marketing to the company to collect requirements along with negotiating the contract. 'A' takes the requirements and works diligently on the project. Six months later they deliver exactly what was first proposed, but the customer is unhappy. The product failed to include additional features that the customer discovered over the last six months. The project is renegotiated and 'A' goes back to hack into his solution a set of features that stretch his architecture in ways it was never meant to handler. Six months later 'A' delivers a solid product, but the customer is still unhappy because the product fails to use a new industry standard UI. This goes on for years. Now suppose 'B' wins the contract. 'B' sends marketing, technical leads, support representatives to witness the customer's environment. They collect a set of requirements and negotiate a contract for delivery in six months. Before 'B' leaves he gets the customer's commitment to take six intermediate deployments before the final product is delivered. One month later, 'B' takes a small but functional version of the product to the customer who uses it and reports several new requirements and requirement modifications, 'B' says "no problem" and 'B' refactors the code to the adjusted requirements while adding the next set of requirements. A month later 'B' delivers another more functional version of the product, which the customer likes better than the first but he still sees some issues and he has a couple extra requirements. This scenario plys out four more times. After six months, the customer receives from 'B' exactly what he expects since he's seen six incarnations of it over the last six months and had it tweaked to what he wanted. 'B' gets paid and the customer starts negotiations on revision 2.0 of the product. 'A' delivered a totally new product once after six months. 'B' delivered the same but improving product six times over six months. Did the customer have to do more work with 'B'? Absolutely. did the customer also get what he expected and have a partially trained staff upon final delivery. Absolutely. 'A' used the old way (i.e., waterfall). 'B' used the new way (i.e., agile practices).

Here's a story that I think conveys the idea in a simpler fashion without needing to reference a technology project, as I believe Agile extends much further than  software development. Let's say you have to paint a room and the request comes from your spouse or a customer if you're a professional. The customer states that they would like it painted a deep shade of red. They need it done quickly and ideally at a cheap cost. Great. In the "waterfall" method I would then begin measuring the area of the room, determining if a primer is needed, choosing a sample, and providing a quote and timeline. She reviews my plan and agrees. I then spend a couple hours covering the floor and begin painting which takes me about a day. When it is all done, I ask for payment but the customer is upset because when she said "deep" she really meant "a darker shade" but not too dark red. She wants me to redo it. No wait, in fact, she wants me to custom order a specialty paint because she found one with gold flecks in it. Oh, and she considers the hallway to be part of the living room because it's all close together so she needs that done too and why didn't you do that too you silly contractor? Yes she still needs this done in two days her folks will be in town and she told them her house would be ready because I said it would only take me a day and... now I have to wait a week for the paint to be shipped, in the meantime, I lost eight hours of time I could have spent at another customer's site, and I cave in to the extra hallway so I lose a little money too. Now the Agile method is a little more sane. First, I ask, what is your goal in painting this room red. She lets me know that she wants to match the red color of her pillows which have golden flecks to make the room pop when people see her home. I mock up what it would look like by placing a painted piece of poster board against the wall. I repeat with different colors until we finally agree on a basic color but she wants the gold flecks added. Great, I have to custom order it but I know with shipping time, I can have it to her by this date for this price. I will mark the walls I'm going to paint with a piece of tape and explain it will take me about an hour per wall. I paint one wall and ask her if she really really likes it. She confirms. I finish painting, stopping at each wall to confirm if it is acceptable. I know she's going be happy to pay me because I received continuous feedback as I was painting, and she knew up front to expect a week delay for the special paint. Now back to real life, substitute painting for development or completing tasks in a project. Change the poster board to a visual prototype and each single wall as a "sprint" or iterative cycle in an Agile project. Pretend each time I stop and ask how it looks so far, that is "User Acceptance Testing". While this is really a contrived example, the stated goal was an example of a traditional user story. As the home owner (user), she wants this red color (feature), so that it matches her pillows (benefit).

I'll take a stab at answering this ... Very simply put: Agile is a "label" which is used to categorize several different methodologies which are focused on iterative (or incremental) development. Here is one of my favorite analogies, borrowed from one of Mike Cohn's excellent books, http://www.amazon.com/gp/product/0131479415/ref=as_li_ss_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=0131479415&linkCode=as2&tag=irleif-20 (a must-read for software peeps): I often equate the traditional view of a project as running a 10-kilometer race. You know exactly how far away the finish line is, and your goal is to reach it as quickly as possible. On an an agile project, we don't know exactly where the finish line is, but we often know we need to get to it or as close as we can by a known date. An agile project is more like a timed race than a 10-kilometer race: run as far as possible in sixty minutes. In this way, the agile project team knows when they will finish but not what they will deliver. When we acknowledge that the result is both somewhat unknown as well as unknowable in advance, planning becomes a process of setting and revising goals that lead to a longer-term objective. [...] On an Agile project, all the "activities" that typically go into a project are done more or less in parallel; these activities includes everything from planning to designing, system architecture, data modeling, coding, testing, etc. The team focuses on the features (the value they add to the customer), and not so much the activities themselves. Instead of doing each of these activities in separate "phases" (Waterfall-style), the product is crafted in "bite-sized chunks," focused on the features which deliver the most value to the customer. The idea is that the development team have all the resources they need (designers, artists, programmers, etc.) on the team in order to deliver these features, as to minimize "hand-offs" and external dependencies which are typically found in projects which follow the Waterfall model. The main goals of Agile methods are to eliminate or mitigate risks and uncertainties about what you are creating and how you are creating it as early as possible. This is done by getting frequent and continuous feedback from the customer throughout the development. As you and your customer learn more about the product you are creating, you "course correcting" by adjusting the plan and the feature set (scope) accordingly. The particulars of exactly how this could be implemented would largely depend on which Agile methodology you opt for (Scrum, Lean, Rational Unified Process, Kanban, Extreme Programming, etc.), as well as the nature of your project and product and the organization you're working in.

Elevator pitch: Q: Are you ready to commit today my budget department for the next 2 years (any long-term commitment with an uncertain outcome) based on our current assumptions about the future? A: Of course not! Punch Line: So! You are already familiar with Agile!