Quality not-speed-for-distrobution

410 views

Published on

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
410
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
4
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Quality not-speed-for-distrobution

  1. 1. Quality not speed09.05.12
  2. 2. Agencies get fired for low quality delivery
  3. 3. Scrum/Agile is all about high quality
  4. 4. Our highest priority is to satisfy the customerthrough early and continuous delivery ofvaluable software.
  5. 5. I use agile software development techniquesbecause: • I can’t afford to waste time writing the wrong software • I can’t afford to waste time on sub standard software
  6. 6. So it’s a no brainer right?
  7. 7. Why do you want to waste time on..• Writing user stories• Release planning• Sprint planning• Installing a continuous integration server• Writing unit tests• Peer code reviews• Automating functional tests• Training
  8. 8. User stories and the backlog are all aboutwriting the software that must be writtenand nothing else.
  9. 9. Release planning is the most efficient way Iknow to get a high level plan everyone on theteam buys into
  10. 10. Sprint planningThe most time efficient way to make a tasklevel plan.
  11. 11. Installing a continuous integration serverIf one manual release to staging takes 1hrover the course of a 3 month project with arelease to staging every 2 days +releases todev several times a day..= 40 to 80 hrs of deployments= 10 days wasted+ the time wasted getting it wrong+ is this bug a failed deployment or a real bug
  12. 12. Writing unit tests and TDDCatch as many bugs before they leave thedeveloper as you can. The longer a problemgoes undetected the more its costs to fix.Prevent developers over engineeringsolutions
  13. 13. Peer code reviews• Bus level redundancy - Share knowledge around the team• Catch poor quality code and lazy hacks early• Have two people sign the commit and be responsible for the code.
  14. 14. Automating functional testsA single manual test run takes 2-3hrs. Weneed to test every day over a 60 day project =22 days of testing. And we can’t fix any issuesuntil the tests are run. Even if we spend 15days creating tests we have still saved time.Plus the value delivered to the project ishigher.
  15. 15. High quality projects complete quickerLow quality projects never stop eating yourresources:• Post live fixes• Additional work to appease client dissatisfaction• Additional releases for free
  16. 16. Quality = speed
  17. 17. Questions

×