1. FAZAL WAHAB Agile Software Development

2. What is Agile? An iterative and incremental (evolutionary) approach performed in a highly collaborative manner with just the right amount of ceremony to produce high quality software in a cost effective and timely manner which meets the changing needs of its stakeholders. Core principles  “Fits just right” process  Continuous testing and validation  Consistent team collaboration  Rapid response to change  Ongoing customer involvement  Frequent delivery of working software

3. How Agile is Different Focus on collaboration:  Less paperwork and more conversation  Stakeholders actively involved Focus on working software:  Greater feedback makes agile projects easier to manage  Less documentation is required  Less bureaucracy Agilists are generalizing specialists:  Less hand offs between people  Less people required  Specialists find it difficult at first to fit into the team Agile is based on practice, not theory:  This is a significant change from traditional  You need to see how agile works in practice to truly understand it

4. Myth busters Myth 1. No Documentation 2. Undisciplined 3. No Planning 4. Not Predictable 5. Does Not Scale 6. Is a Fad 7. Silver Bullet 8. RUP isn’t agile 9. Not Fixed Price Reality 1. Agile Documentation 2. Requires great discipline 3. Just-in-time (JIT) planning 4. Far more predictable 5. Eclipse is agile 6. It’s quickly becoming the norm 7. It requires skilled people 8. RUP is as agile as you make it 9. Agile provides stakeholders control over the budget, schedule, and scope

5. Why Agile Works www.ambysoft.com/essays/whyAgileWorksFeedback.htm

6. Agile Development Practices Regular Delivery of Working Software  Only valid measure of progress  Provides visible results to stakeholders  True earned value, not documentation-based “earned value” Daily Stakeholder Interaction  On-Site Customer  Active Stakeholder Participation  Product Owner Continuous Integration  Automatically compile, test, and style check your code  Continuous code integration is nice  Continuous system integration is nicer

7. Test First Design (TFD) www.agiledata.org/essays/tdd.html  With TFD you write a single test and then just enough production code to fulfill that test  Test-Driven Development (TDD) = Refactoring + TFD  TDD is a just-in-time (JIT) specification activity  TDD is a continuous confirmatory validation activity  TDD via Customer/Acceptance Tests  Specification of requirements  TDD via Developer Tests  Specification of design  TDD is also called Behavior Driven Development (BDD)

8. Other Agile Quality Practices Non-solo development  Pair programming  Modeling with others  Effectively continuous inspections Following guidance  Coding practices  Database standards  User interface (UI) standards  Modeling style guidelines (www.agilemodeling.com/style) Refactoring  Small change to your code which improves the quality of the design without changing the semantics  Code refactoring  UI refactoring  Database refactoring

9. Working in Priority Order: Agile Change Management www.agilemodeling.com/essays/agileRequirements.htm

10. Agile Model Driven Development (AMDD) www.agilemodeling.com/essays/amdd.htm  Do just enough initial envisioning to understand the scope and technical direction  Model storm on a just-in-time basis to gather the details when you need them

11. Agile User Experience (UEX) Observations:  User interface (UI) and usability issues are critical to the success of most systems  The UI is the system to the end user  Few developers have solid UEX skills, although many think they do Advice:  Everyone should have some UEX training  Have someone with UEX expertise within your organization, and ensure that they pair regularly  Part of initial envisioning should address UEX issues  UEX issues will need to be addressed throughout development  Recognize that few of us are building the iPod, but when we tread into new territory we may need to do more up-front work than usual

12. Maximize stakeholder ROI Are treated as a requirement Have a specific customer and facilitate the work efforts of that customer Are concise Fulfill a purpose Describe information that is less likely to change Describe “good things to know” Are sufficiently accurate, consistent, and detailed – But aren’t perfect Agile Documentation Practices www.agilemodeling.com/essays/agileDocumentation.htm

13. Challenges with Agile in the Mainstream Agile Development Co-located Geographical distribution Global Compliance requirement Low risk Critical, Audited Application complexity Simple, single platform Complex, multi-platform Team size Under 10 developers 100’s of developers Organization distribution (outsourcing, partnerships) In-house Third party Degree of Governance Informal Formal Entrenched process, people, and policy MinimalSignificant

14. Scaling TDD: Agile Model Driven Development (AMDD) www.agilemodeling.com/essays/amdd.htm

15. The Generic Agile Lifecycle

16. References and Recommended Reading www.agilealliance.com www.agilemodeling.com www.agiledata.org www.enterpriseunifiedprocess.com www.ibm.com/rational/agile/ Ambler, S.W. (2002). Agile Modeling: Effective Practices for XP and the UP. New York: John Wiley & Sons. Ambler, S.W. (2003). Agile Database Techniques. New York: John Wiley & Sons. Ambler, S.W. (2004). The Object Primer 3 rd Edition: AMDD with UML 2. New York: Cambridge University Press. Ambler, S.W. and Sadalage, P.J. (2006). Refactoring Databases: Evolutionary Database Design. Reading, MA: Addison Wesley Longman, Inc. Larman, C. (2004). Agile and Iterative Development: A Manager’s Guide. Reading, MA: Addison Wesley McGovern, J., Ambler, S.W., Stevens, M., Linn, J., Sharan, V., & Jo, E. (2003). The Practical Guide to Enterprise Architecture. Prentice Hall PTR.