1. AGILESoftware Development Process Richard Thomas

2. Software Development Life Cycle Models Code and Fix • Little to no planning • Most frequently used model • Immediately start developing, fix problems as they occur • Keep going until you think you’re done • Tempting choice when under tight schedule • See immediate results • Problems found late on in development are costly to remedy

3. Software Development Life Cycle Models Waterfall • Emphasis on design in the initial stages • Document and planning intensive • Good for quality controlled environments • A classic software development model • Widely used in government / large company projects • Results are not seen until late in the development

4. Software Development Life Cycle Models Modified Waterfall • Try to allow some of the stages to overlap • Reduces the documentation and cost of switching between stages • Allowing some Design before finishing the Requirements can help with the Requirements understanding • Hard to know when a particular stage is complete • Tend to put off major decisions, increasing expense

5. Software Development Life Cycle Models Prototyping • Begin development before the requirements are fully understood • Build the prototype, adjust the requirements, repeat until the objectives are fully understood • Gives the false impression of early progress • Prototypes can often be built on compromises that are to be addressed later, making it an ineffective foundation for the future solution • Very similar to code and fix

6. Software Development Life Cycle Models Spiral • Emphasises risk management – find major problems early • Break project into a set of risks that need dealing with • Attack each risk in a spiral: • Analysis • Design • Implementation • Testing • Very experimental approach

7. AGILE Software Development Process

8. “Walking on water and developing software from a specificationare easy if both are frozen” - Edward V Berard

9. The AGILE Manifesto 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. Kent Beck, James Grenning, Robert C. Martin, Mike Beedle, Jim Highsmith, Steve Mellor, Arievan Bennekum, Andrew Hunt, Ken Schwaber, Alistair Cockburn, Ron Jeffries, Jeff Sutherland, Ward Cunningham, Jon Kern, Dave Thomas, Martin Fowler, Brian Marick

10. Individuals and Interactions • In AGILE development, self-organization and motivation are important, as are interactions like co-location and pair programming. Individuals and interactions over Processes and tools

11. Working Software • Working software will be more useful and welcome than just presenting documents to clients in meetings. Working software over Comprehensive documentation

12. Customer Collaboration • Requirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important. Customer collaboration over Contract negotiation

13. Responding to Change • AGILE development is focused on quick responses to change and continuous development. Responding to change over Following a plan

14. 12 Principles of AGILE • Customer satisfaction by rapid delivery of useful software • Welcome changing requirements, even late in development • Working software is delivered frequently (weeks rather than months) • Close, daily cooperation between business people and developers • Projects are built around motivated individuals, who should be trusted • Face-to-face conversation is the best form of communication (co-location) • Working software is the principal measure of progress • Sustainable development, able to maintain a constant pace • Continuous attention to technical excellence and good design • Simplicity—the art of maximizing the amount of work not done—is essential • Self-organizing teams • Regular adaptation to changing circumstances

15. AGILE Methods • Adaptive Software Development (ASD) • Agile Modelling • Agile Unified Process (AUP) • Crystal Methods (Crystal Clear) • Disciplined Agile Delivery • Dynamic Systems Development Method (DSDM) • Extreme Programming (XP) • Feature Driven Development (FDD) • Lean software development • Scrum • Scrum-ban

16. AGILE Summary • Accept and embrace change • Provide early, frequent software releases • Close, frequent collaboration • Continuous testing • Trust • Software-based progress measurement • Technical excellence

17. Success Rate

18. Steven Rakitin “yet another attempt to undermine the discipline of software engineering” Rakitintranslated the manifesto bullet “Working software over comprehensive documentation” into “We want to spend all our time coding. Remember, real programmers don’t write documentation.” This is disputed by proponents of Agile software development, who state that developers should write documentation if that's the best way to achieve the relevant goals, but that there are often better ways to achieve those goals than writing static documentation

19. Conclusion • A good agile team picks and chooses the management and technical practices that best work for them. • When trying to adopt Agile practices, there will be a ton of excuses as why it won’t work. Those who understand the real benefits of the approach – and genuinely want to make the transition – will likely have success. • Those who are searching for reasons why it will fail – well, they will likely find them and either abandon the effort entirely or end up practicing what Elisabeth Hendrickson calls fake agile.

20. VI Shots podcasts • http://vishots.com/37