views:

685

answers:

11

I'm supposed to give a presentation on agile programming techniques for my Business and Professional Communications class. One thing I'm having a bit of a problem getting right is the best way to give a quick and dirty overview of how agile programming works before I get into the meat of it.

So what are some good ways to do this? Are there any analogies that work fairly well? Or is there any way to describe agile programming in maybe 3 or 4 sentences?

Note that gross generalizations and oversimplifications are allowed if not preferred. However, for clarity's sake, it could be nice if you would point them out.

EDIT: Perhaps I should clarify. I'm not necessarily looking for reasons as to why a person should use agile programming so much as I'm looking for a quick way to describe what the heck it is and compare it to more traditional techniques.

+1  A: 

Tell them is a way to work that mix theory (analysis) and practice (coding) together with more flexibility. Explain how version will be deployed and when they will be able to make change. Show them their role and how they can participate (Use Case, etc) and when they can add some input in the project.

Daok
+2  A: 

I like to talk about it as a technique for achieving something that is useful in all kinds of technical and non-technical projects--breaking down the key problem into smaller parts. This has a few advantages:

1) Allows a team to create a system that may be too complicated for them to understand as a whole, by turning into many simpler pieces.

2) Makes delegation much easier.

3) Makes it much easier to measure progress.

4) Gives you many more opportunities to re-evaluate and change directions as you gain knowledge throughout the project.

I'm sure I'm missing some...

jmans
+5  A: 

If I may be gross and overly simple ...

You could think of agile programming this way: it's like a scaled-down version of Habitat for Humanity. Instead of ordering a house and having it built for you, and not being able to take possession until it's completely done, you pitch in and work with the group to build it. Regularly, you decide as a group which parts of the house are most important right now and work on those. You're still building the house to spec, it's just a more fluid and interactive method of building it.

Dave DuPlantis
+1  A: 

The CFO of our company was so impressed by Scrum/Agile as a methodology for prioritizing work that several groups outside of IT started using a form of it. Short sprints of expected work. Planning boards. 15-minute stand up meetings. (The recovering-micromanager's warm blanket dream come true!) Teams in their own rooms together. Pair accounting. (No joke.)

Honestly, I think they have had more luck with Agile than we IT workers have. (Which has more to do with other factors.) That there's a predefined set of work to be finished by a date and those workers are not over-managed or interrupted has really boosted morale over there. no more, "WHERE'S MY NUMBERS?!?!" They know, "Next Tuesday."

mspmsp
But what happens when there's no centralization of scrum? I went to work a company with 400 devs using Agile. 38 daily scrums. And there was reinvention going on all over the place. End result, creative work, and very slow progress. We changed that by adding architecture and having scrum teams be managed to a central task list. Without central coordination amongst scrum teams Agile will fall down. // :)
Spanky
+1  A: 

Hello and good day for you people

how agile programming works?

This can be an answer to your question

Manifesto for Agile Software Development

http://agilemanifesto.org/

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Principles behind the Agile Manifesto

We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity--the art of maximizing the amount of work not done--is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Thats all With no more.... bye bye

yeradis
I'm totally missing the analogy here. This looks like a cut and paste from the agile site.
stevedbrown
+1  A: 

Agile software development is the means to be able to identify and eliminate waste. It allows you to find the shortest distance to providing value for your customer.

Steve Horn
+1  A: 

Check out AgileAlliance.org for reference materials. I found this article there listing 10 reasons to do agile development and this introduction to XP, there.

tvanfosson
+2  A: 

My analogy is to that of a pro athlete.

There is a lot of study, practice, review in pro sports.

But to keep up w/ the extraordinarily fast pace at that level, a player must internalize these experiences at the semi-conscious level and play mostly by feel.

Likewise, I believe an agile methodology places a premium on good design skills, planning, etc. It's just that these guiding principles need to be practiced in real time by the individual.

Thus, for the collection of developers that jells to a good unit, the agile methodology offers degrees of freedom to work smarter, more targeted, and faster. But for those development teams that can't see the forest for the trees, it's a disaster waiting to happen.

6eorge Jetson
Well spoken // :) Hence a hyrbid solution that offers team cohesiveness driven to clearly defined goals (waterfall's structure), and iterative continuous review (agile's fluidity) makes sense... // :)
Spanky
+15  A: 

I like to cook, so I use a soup analogy. Traditional waterfall would be like following a strict recipe, measuring and timing everything exactly, without tasting it until it's completely finished. Agile is like starting with stock and a few basic ingredients, tasting it frequently and adding what your taste-tests show that it "needs."

Sherm Pendley
And: using agile, you set a regular schedule where your soup is in a state where it could be served. The people who eat that version tell you what improvements it needs for next time. OTOH, waterfall only has 1 serve date at the end, and very often people taste it and it's not what they expected.
JeffH
excellent analogy, +1
jcollum
A: 

The only complex systems that work evolve from simpler systems that work. Agile development wants to build the simplest possible system that works, and then evolve it every day, one high priority customer requirement at a time, into another working system. The system is useful almost immediately, and becomes incrementally more useful, and it always works. It evolves in full view of everyone. Today's discussion of what to add turns into tomorrows working system. New requests are welcomed. Things can change. The method is agile.

dongilmore
A: 

This is an interesting question.

Let's look at other industries. TV. Saturday morning cartoons. A highly creative environment, artists drawing and painting on time and on budget to achieve a mark of quality with weekly releases.

It's a system that has been in use for years and adapts slowly to new technology, but does adapt in such a way that the quality remains and the product ships on time within budget. Marketing, sales, revenue all depend on that - that which pays the staff.

How is it done? Clear task delegation with central leadership. A schedule, a production schedule. "You need to do this and you have this long to do it. Looks good. Next task."

But let's stop and think for a minute, wouldn't that work better if we didn't plan it all in advance. Let's build a show, but let's not have a storyboard, or maybe for just the first act, the next ones we can just sketch out as we iterate. Really?

Now I know that isn't exactly what Agile is, but without a plan how do we define where we are going enough to lead there and not have to go over that again and again? How could Saturday morning happen on time or on budget?

Maybe the simple truth is that talent can see in advance what needs to be built. Agile is a means for us to skip that, for now :)

Spanky