The Value of Agile Methods

1. The Value of Agile Methods Colin Bird – colin.bird@conchango.com Howard van Rooijen – howard.vanrooijen@conchango.com

2. Project Failure Rate is Too High • Despite the application of methodologies, technology projects still regularly fail more than would be acceptable in any other industry. • The evolution of technology and tools has outstripped methodologies by an order of magnitude.

3. The Methodology didn’t work The Solution didn’t work Reasons For Failure

4. Costly Functionality is Often Not Used

5. Response to regular project failure? • Methodologies to make software development process more disciplined and predictive • More planning • Greater attention on analysis of requirements • Tie down scope and sign-off • Detailed and documented design before coding • Strict change control to suppress change • And the result ?

6. Project success rates haven’t really improved • Methodologies can prove bureaucratic and slow to deliver • Hard for the business to completely conceptualise all requirements in one pass • Even harder to capture all the requirements in a document in a completely detailed and unambiguous form • Developers “Interpret” requirements • Businesses constantly change - the longer the project the greater the risk • Requirements and Priorities change • Its hard to completely design a system in one exercise • And not of great value if the requirements change anyway • If change is successfully suppressed, the business gets software they can’t use

7. Production Start Envisioning Planning & Spec Development Stabilisation Deployment Classic Issues • Q: When is the best time to discover bugs? • Q: When would user feedback be most useful? Testing UAT

8. Evolution: Agile Methodologies • A number of methodologies have evolved to offer alternative approaches to building software that are more adaptive rather than predictive. • These from the “Agile Alliance”: • Extreme Programming (XP) • Crystal • Dynamic Systems Development Methodology (DSDM) • Scrum • Adaptive Software Development • Feature Driven Development (FDD)

9. Agile Alliance 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 interactionsover processes and tools • Working softwareover comprehensive documentation • Customer collaborationover contract negotiation • Responding to changeover following a plan • That is, while there is value in the items on the right, we value the items on the left more.

10. The Agile Methodology Space

11. Scrum + XP • Scrum provides the project delivery approach and aspects of XP provide the engineering practices • Scrum • Incremental & Iterative - 4 week Sprints delivering production quality code • Analysis, design, development, testing performed throughout iteration • Team design and architectural input • Self organising cross-functional teams - including the customer • Minimal creation of “Interim” documents - focus on code delivery • XP - Engineering Practices • Continual Refactoring • Simplest solution that fulfils functional and non-functional requirements • Automated Unit testing & Code Coverage checking • Test driven development • Continuous integration • Peer Code reviews / pair programming

12. Potentially releasable code delivered every 4 weeks

13. Analyse Design Build-Test Deploy UAT Test Elements of an Iteration

14. Sprint Iteration

15. Engineering Practices • Design fundamentals • Single-Responsibility Principle • Open-Closed Principle • Interface Segregation Principle • A good architecture will aid flexibility & minimise impact of change • Layered architecture with clean separation and interfaces • Encapsulation - assess what is most likely to change • Patterns and frameworks • Allow business value to be created in 4 weeks • Architectural consistency and quality through use of tried and tested patterns • Implementations of patterns provide speed of development

16. Engineering Practices • Engineering Practices are fundamental • Accelerators for achieving Quality AND Quantity • Agile assumes skilled developers • Developers make more decisions • Developers play role of Business Analyst • EP make sure developers do their job properly

17. Engineering Practices • Pyramid of Quality

18. Engineering Practices • The Importance of being Unit Tested • Encourages you to be explicit about the scope of the Implementation • Helps separate logical design from physical design from implementation. • Grows your confidence in the correct functioning of the system as the system grows (don’t fear change) • Simplifies your designs. • Immediate feedback – indicates when a developer has finished all the necessary functionality. • Agile projects don’t have upfront formal specification documents, • Unit Tests can become the living specification of the solution.

19. Engineering Practices • Create specification outlines from your Unit Tests

20. Engineering Practices • Create specification outlines from your Unit Tests

21. Engineering Practices • Ensure your Unit Tests are effective with Code Coverage • Code Coverage measures how much of your code is being executed when a test is run. • Highlights untested black spots • Use to reduce bugs and application errors • BUT • Code Coverage can only tell you about faults of commission, not faults of omission.* • Do not set x% coverage as a shipping point – will push developers to write quick and dirty coverage tests

22. Engineering Practices • Ensure your Unit Tests are effective with Code Coverage

23. Engineering Practices • Ensure your Unit Tests are effective with Code Coverage

24. Engineering Practices • Ensure your Unit Tests are effective with Code Coverage

25. Engineering Practices • All very interesting BUT what is the relevance to Agile Architecture? • Scrum tenet: EXPECT CHANGE • If you don’t have unit tests & code coverage – how can you measure the effects of changing architecture?

26. Lean Architecture • Delay design decisions until last responsible moment • Maximises information before commitment • Minimises opportunity of change before software is delivered • But don’t procrastinate! • Do ‘enough’ architecture • Varies per project • Identify the areas of high cost of change • Enough to start developing • Keep doing it until the project ends • Keep documentation light • Loss of fidelity in translation to document form • Resistance to change once its “on paper” • Diagram the essentials but don’t be precious as they will need to change