1. The Value of Agile Methods
Colin Bird –
Howard van Rooijen –
20 September 2018

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.
20 September 2018

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

4. Costly Functionality is Often Not Used
20 September 2018
Costly Functionality is Often Not Used
80% of benefit comes from 20% of the requirements.
20 September 2018
© conchango

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 ?
20 September 2018

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
20 September 2018

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

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)
20 September 2018

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 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.
20 September 2018

10. The Agile Methodology Space
20 September 2018

11. 20 September 2018
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
Scrum – it’s not a silver bullet – it adds transparency (for better or worse)
20 September 2018
© conchango

12. Potentially releasable code delivered every 4 weeks
20 September 2018
Potentially releasable code delivered every 4 weeks
A common statistic is that 80% of benefit comes from 20% of the requirements. Prioritisation, along with early release can deliver the majority of required functionality very quickly.
20 September 2018
© conchango

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

14. Sprint Iteration
20 September 2018

15. Engineering Practices
20 September 2018
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
A class should have only one reason to exist (and so change).  Classes should be really simple and do really simple things.
Software entities should be open for extension, but closed for modification. Where extension is by inheritance (not always a good idea), this may break the ‘rule’ that all classes should be sealed unless absolutely necessary. See Decorator pattern.
Fat interfaces subject clients to changes in that interface to accommodate other clients’ needs. Separate out thin interfaces.
See Agile Software Development, Principles, Patterns, and Practices: for more info
20 September 2018
© conchango

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
20 September 2018

17. Engineering Practices
20 September 2018
Engineering Practices
Pyramid of Quality
The “Pyramid of Quality” represents practices that are recommended as aspirational points of quality.
Those practices at the top of the pyramid represent the pinnacle of Agile development practices, whereas those at the bottom represent the foundations without which those practices at the top would not usually take place.
20 September 2018
© conchango

18. Engineering Practices
20 September 2018
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.
20 September 2018
© conchango

19. Engineering Practices
20 September 2018
Engineering Practices
Create specification outlines from your Unit Tests
If you code your unit tests properly…
20 September 2018
© conchango

20. Engineering Practices
20 September 2018
Engineering Practices
Create specification outlines from your Unit Tests
You can easily use tools to parse them and generate outlines… see AgileDox -
This information should be enough to present to testers / business owners to see if you’ve fulfilled the requirements.
20 September 2018
© conchango

21. Engineering Practices
20 September 2018
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 *
See How to Misuse Code Coverage: for more information
20 September 2018
© conchango

22. Engineering Practices
20 September 2018
Engineering Practices
Ensure your Unit Tests are effective with Code Coverage
20 September 2018
© conchango

23. Engineering Practices
20 September 2018
Engineering Practices
Ensure your Unit Tests are effective with Code Coverage
20 September 2018
© conchango

24. Engineering Practices
20 September 2018
Engineering Practices
Ensure your Unit Tests are effective with Code Coverage
20 September 2018
© conchango

25. Engineering Practices
20 September 2018
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?
20 September 2018
© conchango

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
20 September 2018