How to explain "Agile" to a non-developer?

Question

I am looking for ways to explain "Agile" to a non-developer. You could try to summarize it yourself, but a reference to a short article, blog post or podcast could also prove helpful.

Answer 1

Tell them the point is to get usable products to the customer every iteration, so it can be evaluated by them much sooner than later. I think that's all a non-developer would care about.

Answer 2

Try this:

http://www.martinfowler.com/articles/newMethodology.html

and when trying to implement them into your project, here are some problems you may encounter:

http://www.infoq.com/news/2008/09/fowler-scrum-interview

Answer 3

I would use the agile manifesto (http://agilemanifesto.org/) as a basis for your conversation.

Depending on how much time you have you can

• use it for a 10000 feet overview of the values of the agile movement ("what do we want to acchieve").
• explain why these values are appreciated more than the traditional ones ("what are the typical problems/pitfalls when doing traditional software development").
• what principles and techniques can be used (e.g. continuous integration, unit testing, iterative software development,...)

As always you may encounter the problem that you can only appreciate solutions to things you have recognized to be a problem...

Answer 4

In one sentence, I would say : Agile is a (set of) methodology which integrates change/adaptation in software development.

The client is an active member of the team and collaboration is the team's backbone.

You may insist on the aim : Results are software fitting client expectations and delays.

Answer 5

Agile development methodology considers software as the most important entity and accepts user requirement changes. Agile advocates that we should accept changes and deliver the same in small releases. Agile accepts change as a norm and encourages constant feedback from the end user.

Maybe when it is on paper add something of their principles:

• Welcome change and adapt to changing requirements
• Working software is the main measure of progress.
• Customer satisfaction is the most important thing and that can be attained by rapid, continuous delivery of useful software
• Day to day meetings between business people and development team is a must.
• Business and developers must work together. Face to face to communication is the most important thing.
• Deliver and update software regularly. In Agile we do not deliver software in one go, but rather we deliver frequently and deliver the important features first.
• Build projects around teams of motivated and trustful people.
• Design and execution should be kept simple.
• Strive for technical excellence in design and execution.
• Allow team to organize themselves.

Also googling on Agile for dummies or something helps a lot.

//edit This author does a great job explaining it easily maybe you can use it. I can not link since I'm not cool enough on this site yet but hopefully you can make it out ;).

agileproductdesign.com/blog/dont_know_what_i_want.html

Answer 6

Here is my take at it: In the old ages, people believed that programming was "mathematics", that you could plan every eventuality ahead of time, make a complete plan and then just implement that plan using a computer.

Over time, we learned that this doesn't work. As a project progresses, people learn. Developers learn new ways to solve a customer request. The customer learns what is possible and what isn't and how much something costs. They often learn that their original idea wasn't that good or well thought through and that something else would be much better.

In short, we learned that the only constant in software is change. So we gave up our hopes that we might ever be able to foresee everything and did the logical thing: We came up with a way that allows us to adapt. Instead of talking once to the customer, then starting to program and handing something useless back a few years later, we build something small and show that to the customer. If they like it, we build upon it. If they don't we scrap it. Since we built only something small, scrapping it will be cheap. But we will only scrap the code, not what we learned. So even when we fail, we'll get better. This allows everyone to end up in the same spot when the project is over.

Answer 7

Agile methods consist of common sense recommendations to do things that smart developers were already doing as well as a culture of baby-sitting and constant checkups which presumably prevents those who don't know what they are doing from wasting as much time before the work gets moved to someone competent.

Answer 8

Agile did not originate in software - it started in manufacturing in the 1950s (read up on W E Deming).

Agile is the reason that the Japanese make high quality affordable cars.

Agile is how the big Japanese companies like Honda and Toyota are able to rapidly scale down and cope with the current credit crunch. When the global economy picks up they'll scale back up quicker than anyone else can too.

Yes, agile is about accepting change, and agile in software is about evolving features and avoiding management by quota. But agile is also about minimising waste.

In manufacturing this minimising waste is about not building up loads of stock that bascally costs you money until you sell it.

In software this is minimising the time that you have unsellable products. In a traditional model you have years of development work before you get a final product that you can sell. In agile you have a limited product that you can start selling very quickly, and then it starts getting better.

This is a strong argument for non-agile folks - go BDUF you know exactly what you're going to be able to sell in two years. Go Agile and you'll have something, maybe not perfect and not with everything that you want, but something stable that you can start selling.

Answer 9

Check out Steve Bohlen's Autumn of Agile.

Answer 10

The most concise definition I have encountered for agile is as follows

Agile is a means to deliver working software. Agile methodologies:

• Embraces change via a project management process that encourages frequent inspection and adaptation
• Encourages collaboration via a leadership philosophy that encourages team work, self-organization and accountability
• Promotes sustainable pace via a set of engineering best practices that allow for rapid and sustainable delivery of high-quality software
• Is customer focused by aligning development with customer needs and company goals

Furthermore, the Agile Manifesto is detailed by the Agile Principles (agilemanifesto.org) that map to a set of agile practices. While the Manifesto and Principles have been set, the practices can vary. The most potent set of practices I have witnessed combine management practices (SCRUM) with engineering practices (XP).

Answer 11

By non-developers, I assume you stakeholders: product/project managers, upper-management, etc.

These people are driven (or should be) by business, and they have to spread their attention among many tasks. They can't afford to really listen or read about Agile till they "Get It".

So what you need to do, is give them an elevator-pitch. This means, basically, that you need to be able to sell them onto the idea in the time that it takes to ride an elevator from ground to upper level (1-5 minutes): Work on your delivery

To the point - tell them the most important thing about Agile: Agile is delivering the most (business) value, as early as possible, and as often as possible!

That's it. Understand that, and you've got it. The rest is details. Agile methodologies and processes are methods and processes that help you deliver value early and often.

Anything that doesn't enable this kind of delivery is not Agile.

This is where I'd stop my pitch. Let the idea sink in. Let the "powers that be", decide whether this is a valuable effort. Whether they care about maximizing value to their customers and users, and the ability to react to the market's demands early and often.

If they do, then you can later move on to discussing techniques and methodologies. Do not discuss ever the engineering practices such as TDD, refactoring, and pair-programming with the anybody above the development-manager. Engineering should be abstracted away from them. I assume you are a developer. Think of this as doing coding to an interface, rather than a concrete class. Avoid mentioning specific methodologies. They will carry either no value, or negative value, if the stakeholder heard some warped version of it (besides Scrum is a silly name, and Extreme Programming sounds like something he doesn't care about).

If you've managed to pass this major first hurdle towards embracing agility in your shop, I suggest you look up Amr Elssamadisy's excellent (free) book: Patterns of Agile Adoption: The Technical Cluster, for how to (agilely) introduce Agile methodology to your organization, according to your needs.

Hope this helps, Assaf.