the value of agile methods l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
The Value of Agile Methods PowerPoint Presentation
Download Presentation
The Value of Agile Methods

Loading in 2 Seconds...

play fullscreen
1 / 26

The Value of Agile Methods - PowerPoint PPT Presentation


  • 167 Views
  • Uploaded on

The Value of Agile Methods. Colin Bird – colin.bird@conchango.com Howard van Rooijen – howard.vanrooijen@conchango.com. 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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'The Value of Agile Methods' - harmon


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
the value of agile methods

The Value of Agile Methods

Colin Bird – colin.bird@conchango.com

Howard van Rooijen – howard.vanrooijen@conchango.com

project failure rate is too high
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.
response to regular project failure
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 ?
project success rates haven t really improved
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
classic issues

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

evolution agile methodologies
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)
agile alliance manifesto
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.
scrum xp
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
elements of an iteration

Analyse

Design

Build-Test

Deploy

UAT Test

Elements of an Iteration
engineering practices
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
engineering practices16
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
engineering practices17
Engineering Practices
  • Pyramid of Quality
engineering practices18
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.
engineering practices19
Engineering Practices
  • Create specification outlines from your Unit Tests
engineering practices20
Engineering Practices
  • Create specification outlines from your Unit Tests
engineering practices21
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
engineering practices22
Engineering Practices
  • Ensure your Unit Tests are effective with Code Coverage
engineering practices23
Engineering Practices
  • Ensure your Unit Tests are effective with Code Coverage
engineering practices24
Engineering Practices
  • Ensure your Unit Tests are effective with Code Coverage
engineering practices25
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?
lean architecture
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