So the BIG buzzworld around the development world is Agile. Agile Methodology, Agile Object Technology,AgileModeling, AgileDevelopment, Agile Eating... it's all about the agility.
But what does Agile mean? By definition agile is an adjective characterized byquickness, lightness, and ease of movement. How would this apply to software? (other thanthe technology changing so fast that we have to constantly spend $80 on books andmagazine subscriptions, not to mention keeping involved in the community to even attemptto keep up)... Agile SoftwareDevelopment. It sounds exciting and confusing. Hopefully, through the use of examplesI got from the recent OTUG/AEG meeting and ourexperiences within our company, I will turn you to the dark side and show you how agilitycombined with producing quality software makes complete sense.
Traditionally, software has been sold, estimated, designed, developed, tested, andreleased under a strict, orderly waterfallapproach. You spend months on end gathering requirements, trying to understand theentire system. Then you spend another good amount of time with that knowledge coming upwith an estimate for a contract. You design, develop, and test the project that usuallyends up over time and budget. Then you support and recieve change requests for thingsthat could have been solved along the way. But the very discipline and strictness thatcomes from using a waterfall technique did not allow for such things to happen. Insteadof an extremely valuable product for your customer, you end up spending MORE of theirmoney figuring out (after the fact) exactly what they want.
Notice how I used the word "valuable"... this keyword will be brought into ANY agilemethod conversation that you'll have...
Enter the irrational object thinkers (who tore the industry apart by FORCING people tochange their entire thoughts about code paradigms). Look what has happened? Granted it'sbeen close to 30 years since the beginnings of Object Oriented "Thinking", it's thenotion of changing traditional thought that is and will continue to hinder the forwardmovement of Agile "thinking". They were radicals in their field and made a change for thebetter of software development. I, along with many others, feel that the same type ofmovement needs to occur in order to bring more of the industry up to speed with the AgileMethodology. Though I hope it would advance slightly faster.
So thus far, I have kept speaking about the Agile Methodology and how it can radicallychange the software industry, so let's define it. Agile Software Development is definedas a methodology applied to design, development, and testing that creates shorter,iterative deliverables of software product that have been tested and thought out in asmaller, more agile manor (definition of agile above). Feel the agile love (as the usergroup would suggest).
Notice the differences between a standard waterfall approach and an agileapproach.
Requirements
Waterfall - do it ALL up front
Agile - do it for an iteration
Estimation
Waterfall - do it ALL up front with little confidence in correctness
Agile - do it for an iteration with HIGH confidence, give them a lengthy estimation withlittle confidence
Design, Development, Testing
Waterfall - long, separate, diluted steps for each in a very orderly fashion. notflexible
Agile - done per iteration with the thoughts about design, development, and testing onlythe little piece you define for the iteration, thus giving us more quality software andthe flexibility to quickly add features in the next iteration or make changes to currentpieces of the system. Shows the customer VALUE (I told you we'd talk about it)
Release
Waterfall - customer waits till the entire thing has been tried and tested before theycan see a deliverable
Agile - customer sees the steps and can play with real data after each iteration, witheach section being tested, thus the system has been tested thus far. Shows the customerVALUE (I told you we'd talk about it)
So this seems as though its the golden tray that all software will be served... butthere are key things that absolutely must happen before Agile works. There could also besituations where Agile methods might not make sense? (Though I challenge you to come upwith some)
What are those key things that have to happen?
1) Sales - the sales team HAS to be knowledgeable enough to sell a product beingdeveloped with agility. The client has to be informed up front that the costs involvedwill still be the same, if not lower... but we can't exactly tell you how much. Theestimations also have to be brought out with a confidence level to send a message to theclient that, even though they'll end up with a better product faster and cheaper, its notalways, even with waterfall, to correctly predict out into the future. This couldpotentially be one of the toughest parts of selling agile development. It's the educationin our company that needs to happen.
2) Thinking - the team has to be willing and open to agile methodologies. Pairprogramming, different work environments, Test Driven Development coupled withContinuousIntegration, and MOST IMPORTANTLY... COMMUNICATION. Communication needs to happen onEVERY level more so than ANY other technique (as Valpoints out). This technique is client facing and interaction with the team and thecustomer is essential... ecsential!
3) Environment - the team needs to have an environment that is agile friendly...whiteboards, continuous integration servers, source repositories, daily meeting places,team spaces where development happens in relative locality to the other developers.
Once those things start showing up, it's time for you to get some coaching, buy somebooks or research, sell your company on using the method and be a more happy developmentteam! Happy development teams == Better Code == Happy Clients == More Business. It justmakes sense, agile sense.
I will leave you with the AgileManifesto:
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
some resources:
Books -
AgileSoftware Development
Agile Software Development, Principles, Patterns, and Practices
Agile Project Management with Scrum
Agile and Iterative Development: A Manager's Guide
Sites -
http://www.controlchaos.com/
http://www.martinfowler.com/articles/newMethodology.html
http://agilemanifesto.org/principles.html
http://www.agilealliance.org/home
http://www.agilemodeling.com/