What is Agile? The elevator pitch.

Agile: the ability to welcome (and act on) new and changing business requirements with little or no delay, especially when those requirements emerge when the work is in progress. To do that, you need an empowered workforce able to act autonomously.

When you build something inherently innovative, like software, it's natural to learn as you work, and the things you learn often change the nature of what you're building. You have to adapt as you go along. Traditional software-development practices can't handle that situation at all. Agile processes let you easily redefine what you're building as you build.

To pull that off, though, organizations have to work in completely different ways than they have traditionally.

I think the key aspect is the ability to respond rapidly to the need for change.

Most of the rest is about how; not of so much relevance.

Make progress with imperfect information and adjust as new information arrives.

Build a high trust culture.

Treat work-in-progress as a liability rather than an asset.

This formula for "agile" works at any level in any professional services organization, including law firms.

Agile means "moving with quick, easy grace" and "being of an adaptable character." Those phrases come from the Merriam-Webster dictionary. People need examples to make sense of those phrases. For a lawyer, I would cite those phrases and then talk about how a brand named company recently cut down thier NDA (Non-Disclosure Agreement) from 14 complex pages to 1 simple-to-understand page, thereby making it far faster to bring on new partners. The changes preserved legal safety while streamlining the process. The NDA process now moves with quick, easy grace.

It's a way of thinking and behaving that focuses heavily on people particularly the customer and the team. It requires frequent delivery of the product to inspire collaboration and conversation. An agile shop will have a bias towards action and continuous learning.

People, process, and technology, in that order. People within an agile organization empathize with and delight their customers, they learn how to work across silos, and leverage cognitive diversity to innovate and become resilient. Processes are light. And technology is an enabler, not a panacea. The agile organization focuses on effectiveness, not efficiencies.

If you wanted to fly a plane across the country, would you simply aim the plane towards where you wanted to end up? Or would you start in the right general direction and constantly adjust for wind and atmospheric conditions. That's what Agile is like for a project, constantly adjusting for changing business and technical conditions to make sure you stay on course.

I've always used:

1. Deliver in small increments
2. Deliver the most valuable features first
3. Try to be better with every delivery

It doesn't cover all aspects of agile, but it is an elevator speech after all.

Agile means being able to change direction quickly and easily. We assume that you can’t really know in advance what customers will value or the path to delivering it. So instead of applying formal planning and design processes, we use informal but disciplined collaboration and tinkering to discover and build what customers value. These disciplines reduce exposure to unknowns and enable us to exploit unexpected opportunities along the way.

Feel free to replace “tinkering” with “trial and error.”

It is like standing the legal system as we know it on its head, where the litigant or harmed person is most important while protecting our clients rights. And we simplify the process of adjudication by removing the politics and social prejudices from the equation so that we arrive at the truth the most efficient and effective manner.

If you are thinking of our laws, which have been evolving iteratively and incrementally, by learning from plenty of cases and by the efforts of lawyers and other professionals, over many years, in fact it is very much like an agile example.

Allen, perhaps a good way to explain Agile is by using Agile's adaptive principle to explain it.

Instead of a pre-planned statement, adjust to the situation.

You know the person is a lawyer, so you might want to quickly ask what kind of lawyer.

Assuming he's a trial lawyer, you might want to explain it's the difference between a lawyer who plans everything about the trial in detail (arguments, witnesses, evidence, strategy, closing arguments, etc) before they had all the facts, and a lawyer who actively seeks information (who's the judge? the jury? the defense? would the other party negotiate? etc)and adapts their actions according to information uncovered, as they are uncovered. Everyone used to believe software is best developed via the first way (Not true, but hyperbole is not a crime at a dinner table).

Of course you'd have to prepare different versions of this example for each type of profession you meet...

I sometimes get similar questions about what I do from my family and friends who have zero insight into it. If I were asked "What exactly is Agile (software development)?" I would say...

Consider when you last moved into a new home and had to decide how to arrange the furniture. Did each piece go from the truck to just the right place? Did you have new pieces already picked out for specific places? Probably not. You probably went through some trial and error with pieces moving hear and there.

Agile is a set of practices for software development designed to solve the same problem. That is, how to efficiently get from nothing (i.e. an empty room) to the right set of features when little if any prior insight into what's best is available. Agile uses iterative methods to efficiently get to an acceptable set of features. Agile methods also lend themselves to efficiently adapting when needed, as when it's time to rearrange or replace furniture.

Reduce the risk in delivery of projects by working on small increments and communicating findings and progress in a meaningful way. It allows us to respond to changes during the project. How often have you seen a waterfall project that stakeholders get surprised at features or usage during the deliver stage? That doesn't happen with Agile.

Agile. Continuous learning and improvement of the ways things are get Done by a team of creative professionals.

Agile is a business culture designed/adapted to a handle complex business problems, where complex means rapidly changing and unpredictable business needs. The values, principle, and practices follow.

Lawyer : What is all this agile stuff ?

Me : Oh, it is nothing but common sense driven way of working. But it needs a collective mindset and some trust between builders and consumers.

This mindset assures us that it is possible and perfectly all right to build something in smallish iterations even when all the details and minutiae are not frozen upfront. In fact this mindset tells us that unless we start building, we will never ever know the finer details. And hence building is the only way to define and freeze on those finer details.

Here is analogy for the sake of non-technical people

Traditional software development is like a tailor's job. You will be asked your measurements, garment, style and preferences upfront. The suit will go in the making and you don't know about it for the next few days, when it's showed to you. You like it or not, you have already paid so keep it.

Agile, converts you from a tailor to a barber. You work with customer continuously to understand his preference of hair style, you use your tools accordingly, and the customer gets live feedback in the mirror. At the end, the customer is satisfied and you are happy too. The actual doer works with the customer directly and there is a continuous engagement till end of project.

Agile is risk management for software product development. There are too many unknowns to get a product right the first time. Also, it's hard for people to understand each other. These problems expand geometrically with an arithmetic increase in product size.

Agile is a way to break big problems into smaller pieces and resolve uncertainty by iterating and evolving solutions. It also solves communication problems by having both the business and technology work side by side in small teams.

Lean UX is a complimentary technique where we make quick falsifiable hypotheses and test them with people who will use our products.

Agile is set of values and principles just like samurai's codex. though usually sold as a method of getting things done.

People make mistakes and we are people. So when we do something, we make mistakes. If after three months of hard work we find out that we should have done it differently, we don’t get the time to do it over. If after one week we find out we should have done it differently, nobody finds out about it, we learnt how to do it better, and we will much quicker deliver better results.

(First show the problem, before coming up with a solution)

In 30 seconds and with the goal to make the person who asked the question curiously to learn more I would probably answer:

Agile is about delivering (business) value faster, regularly and with less bureaucracy. Agile is about the culture and mindset where collaboration, feedback, responding to change and learnings are some key elements.

In the situation with a lawyer I would also emphasise that Agile is not only for IT and it is applicable in other businesses.

Agile is a product development team iterating a product from idea to reality, breaking down concepts into small clear goals and deliverables along the way. And bringing the customer and stakeholders into the iterative process as the end goal become clearer-and-clearer and the product quickly evolves.

I'm enjoying the discussion, I think most of the responses are very well-put. I would add that agile is a recognition that the decades of detailed software project planning had consistently failed in two major assumptions (1) that it is possible to put together a requirements document that reflects all the detailed requirements of a project without spending the entire development budget on it (2) the vast majority of developers would be lucky to estimate a 3 day task accurately, but traditional up front planning asks them to estimate maybe a year of work. At that point, the connection to realistic expectations is extremely tenuous.

Agile is an attempt to face that truth and work with shorter timelines and more flexibility instead of just constantly being defeated by missed deadlines and budgets.

The mindset, tools and practices needed to discover your current capability, match it with an ever changing need expressed in the language of business model / operating model alignment.

Given just 30 seconds to explain Agile to somebody, I'd recite the four values from the Agile Manifesto.

That's the most direct and accurate elevator pitch possible.

I would go with "Agile is simply getting changes to you, as a user, as quickly as possible. Surprisingly, simplicity is very difficult."

Here's how I like to describe agile to just about anybody.

It's a set of principles that, when followed, creates an environment in which developers and business people work together to frequently deliver quality software that users love and do it in a humane and sustainable way.

Sadly, this too often not the case, even in companies that claim to be Agile.

Try to compress the time between having an idea and exploiting the value of that idea. Frequently release small, valuable increments of a self consistent system (not necessarily software). Review the value after each increment.

A professor of mine always referred to Agile using the phrase "inspect and adapt." I think it sums up the concept nicely. When I'm explaining it to anyone outside of software development, I also try to use some type of non-technical analogy/anecdote to illustrate the benefit of an iterative approach to problem solving.

Consistently employing transparency (clear and concise communication), introspection (checks and validations) and adaptation (changing direction or making modifications as necessary) to align IT development and associated efforts (work) with the moving target that is business need.

Agile is a philosophy of responding to change, quickly. It's like getting an elephant to move like a cheetah. :)

A set of values and principles seeking to deliver value to stakeholders early and often, minimizing risk through consistent involvement of all key parties in all phases of work.

In the context of Thanksgiving dinner with relatives (who know that I "do" s/w development, and that I'm a mgr of some sort), I'd just tell them that until about 15 years ago, I used to be a S/W Project Mgr, then I switched to being an Agile Project Mgr, and in the past 10 years ago, I became what's called a "Scrum Master" on a couple Agile teams, and that I coach some other Scrum Masters.

That might take 20 secs, and cause a few puzzled looks, but then in the next 10 secs I would explain that in the past my s/w development teams used to work for me, and now I work for them as what's called a "servant leader". Also that our project planning is more "agile" - like a cat.

My 30 secs would be up by then, and - unless anyone had any followup Qs - I'd let the conversation flow to wherever it goes from there - like maybe talking about the NFL (American football) standings. Yes, our family has several avid Seahawks fans.

So I start with what my family know about me, then expound.

BTW, this isn't what I would say if ever asked - it's like what I have said. I've had similar (but longer) conversations in family settings. But the first Q was not "what's Agile?", but rather "where are you working now?", and the next Q would be "what do you do there?". And in response to that second Q, the word Agile might come up (when I say "agile - like a cat").

So as I recall (it was quite a few years ago now), the Q "what's Agile?" did not come up until at least 2 preliminary Qs were answered, and I was the one that first mentioned the word "Agile". I am of course paraphrasing, and I'm sure I actually took > 30 secs (but if asked again, I could answer this in < 30 secs—as above).

Allen Holub: If you have the word "Agile" on your business card, and you're handing them at at dinner, then you might provoke a "what's Agile?" Q faster than as I described.

Build what your customer wants, work together, deliver value early and often, learn and grow.

Adapting to change iteratively, e.g when building a house, rather than wait for the entire house to be built to agree on any modifications, agree on minor enhancements as it is being built. .. less risky approach

Agile harnesses the value of collaboration not just with your key stakeholders but also within your development teams to deliver what the customer wants over short iterations. Priorities are negotiated and agreed frequently to allow your product and your development team to be flexible enough to deliver current business requirements.

Delight your customers, employees, investors and suppliers by creating awesome products.

Agile is a business practice based on trust, many and small feedback cycles, collaboration and sustainable development to focus on the continuous outcome.

Agility is when employees make their own decisions (without fear) and are responsible for the outcomes (and consequences) in order to remove communication bottlenecks upstream (traditional command and control).

For me I try to adapt my answer to the given situation and always relate that to the four values. By example Thanksgiving dinner in itself I would identify as an Agile project, especially understanding that a large Turkey (or a ‘large project’) is not always predictable on when it will be “released”. That the resources and delivery location change over the years, etc. Without going into it too much, by example: Individuals and Interactions over process and tools: Aunt Sally likes to cook the turkey, Uncle Frank (all fictitious names BTW) likes to deep fry it. Since we’re eating at Aunt Sally’s house, it’ll come out of the oven. I would then look at responding to change and collaboration. Cousin Chris and his family are supposed to bring the shrimp, and appetizers. Since they are late, maybe cutting up some vegetables and dip or cheese while the turkey cooks and serve the shrimp with dinner. Looking at, next time tell Chris and his family 30 min. earlier for arrival.

Fast, evolving, inspecting and adapting

Discovering what solution will work for the problem in hand and building that solution in a trusted collaborative environment

I think you'll agree "software is eating the world" every company uses software and provides software to their customers in some way. Agility recognises that the customer is the forefront of this digital world. We provide solutions to their needs by incrementally delivering different ways to meet these needs -- you don't know what you want until you see it.

My favorite: "Agile is about aligning the way people work, with the way work works, ideally so it no longer occurs as 'work', and everybody benefits."

My intention behind that it to have them become curious. I want the thirty second pitch to become a thirty minute conversation. The last thing I want them to do is think they understand it after thirty seconds!

By the way it works like a charm!

For me it's about: developing software in small increments to gain quick feedback from our customers (internal or external) so we know we are building the right thing at the right time in the right way, which also means empowering close working teams to make decisions on what they learn in real time. We can the start - stop - continue, based on learning. By doing this we: do the right the thing for the customer which ultimately means the right thing for our shareholders

Usually the context of the question is also tied to what I do. When dealing with non-software folks I tend to focus on the human aspect and avoid buzz words.

So something like "I help teams to be more predictable and productive primarily by helping them to be happier and more engaged."

Dank Pink's Drive is very often the next place we go and in the conversation. Non software folks often don't care at all about "iterative development" or know how traditional development worked to know why "iterative development" is different. So I stick to the people aspects.

Coincidently been going through this question more often than expected and mostly non-IT folks; and for me this usually helps (I try to avoid being vague or go into details; so - agile is pragmatic way of understanding and delivering what customers actually need in short cycles by receiving continuous feedback and reducing risk and just keep improving on all aspects around it.

1. Doing relevant things
2. Doing (1) fast
3. Not doing irrelevant things

3 words- transparency-inspection-adaption

Make change cheap!

Ok, this Thanksgiving challenge is fun. Can I try?

Suppose you want to pay to have something built for you, but you can't tell in advance what it should be like – you’ll have to figure it out on the fly.

Think of those fancy kitchens that rich people build then rip out because they found they didn’t like them.

Do you want to pay for a little bit of work before seeing if you like it?

Do you want to get the most important part right first?

Do you learn complex things better by taking them a bit at a time?

In Agile, we do lots of important little things fast, we get quick feedback from the customer, and we get better and better at our work.

Suppose you want to pay to have something built for you, but you can't tell in advance what it should be like – you’ll have to figure it out on the fly.

Think of those fancy kitchens that rich people build then rip out because they found they didn’t like them.

Do you want to pay for a little bit of work before seeing if you like it?

Do you want to get the most important part right first?

Do you learn complex things better by taking them a bit at a time?

In Agile, we do lots of important little things fast, we get quick feedback from the customer, and we learn how to get better and better at our work.

I worked in manufacturing in the 1980's and 90's. During that time, Japanese Manufacturing Techniques, aka, JIT, Toyota System, pushed US manufacturing to massive changes. By eliminating waste, setup time, work-in-process, while at the same time empowering the do-ers; they radically shortened lead times, while increasing lead times, which resulted in quality, low cost, and fast delivery.

Agile, does the same thing for software development. It uses many of the same techniques and principles. With, the same results.

Oh, and it makes everyone happier.

Love the phase, "very intelligent, but a lawyer." I'm a lawyer and a software engineer BTW. If I had to sum it up as an elevator pitch, I'd simply quote the manifesto. It pretty well sums it up simply, completely and succinctly.

To a lawyer? In 30 seconds?

Been agile is like been a good lawyer in a difficult case, when new facts and circumstances keep pouring in all the time and client is not cooperating.

In other words: see the big picture, take care of the detail, stay alert.

I have seen the debate over "Describe the problem, not the solution" going on for so long that I have come to the conclusion that it is practically impossible for human beings to separate the problem from the solution; to separate as-is from to-be; to separate how my job works now from how it will work in the future.

One can either keep trying to resolve user requests into clear, unambiguous requirements that can be worked on without user interaction or accept the request as a fuzzy statement that one resolves through further face-to-face discussion and trial and error. One should not view negative feedback as a problem to be avoided. Accept that everyone has done their best and we may still have someone say at a product review or post-deployment that "No, this is not what I want."

There is no "required" in "requirements." I wish we had a better term, but until we do, I feel comfortable in treating requirements as a vague, fuzzy statement of need.

Mmm..that's a good one. I would say...Agile is a set of ideas that some of us think help us make the software the client need fast, with less errors and with lots of interaction with the engaged client.

I would say that Agile is a great way to practice your job by sharing a vision and responsibility with all people involved. Technically, it works with little steps followed immediately by a feed-back from users, so that the project can advance regularly, keeping always the best direction and the highest possible value.

Try using an analogy everyone understands: Food.

Agile is like preparing the perfect meal. The first attempt is edible but could improve. But if you stay focused and try again you can create the perfect meal. All it takes is listening to feedback on each meal you serve and adapting to what you learn.

A framework for collaboration and making quick changes, I normally use the analogy of a PLL radio even the new millennial generation known what a radio is.

Most important is the change of mindset, being willing to change and to allow change to come from anybody.

Recognizing when to pivot and change direction.

Agile is an iterative process that favors frequent communication between stakeholders and implementers, allowing finished work to flow in one direction and feedback in the other on a weekly or even daily basis. Rather than trying to define all of a project's requirements at the point of greatest ignorance, it defers decisions until they're actually needed.