Agile Software Development for Software Developers

Agile Software Development for Software Developers

My Thundertalk: Agile Software Development for Software Developers

It explains the principles and technical foundations necessary to do agile software development.

37df158edd0f4ca5fc2fff2e87f43487?s=128

Christian Bäuerlein

November 28, 2019
Tweet

Transcript

  1. Agile Software Development

  2. Lots of developers don’t like the term agile.

  3. None
  4. None
  5. None
  6. None
  7. • How long should a daily scrum take? • How

    can I fit more work in my two weeks cycle? • What does is take go become a certified SCRUM master? What this talk is not about
  8. • How to build good software. What this talk is

    about
  9. History of development processes…

  10. The Waterfall

  11. The Waterfall No idea, if all of this makes sense

    and if we are doing well. Deadline
  12. The Waterfall Test-and-fix interval • Seems To take forever •

    Guaranteed to break time planning • Nobody is happy at this time
  13. None
  14. The Agile Manifesto

  15. None
  16. Kent Beck • Co-founded XP • “Smalltalk Best Practice Patterns”

    • “Test-Driven Development by Example” • Started the xUnit trend
  17. Martin Fowler • “Refactoring: Improving the Design of Existing Code”

    • “Patterns of Enterprise Application Architecture“ • Popularized the Dependency Injection pattern
  18. Bob Martin aka Uncle Bob • “Clean Code” • “The

    Clean Coder”
  19. Dave Thomas • “Programming Ruby” aka The Pick Axe •

    “The Pragmatic Programmer” • Coined the term “DRY” • runs The Pragmatic Bookshelf
  20. Note: Please compare the books listed here with your weekly

    “Which books should I read to become a better programmer” Twitter/Reddit/Hacker News thread. ;) These are very good programmers!
  21. So… what is this about?

  22. Let’s say you want to build a new software product

  23. The features

  24. There is always a limitation. Time, Money, People, …

  25. What features do you want?

  26. What features do you want? ALL OF THEM!

  27. You start building…

  28. But your estimations are bad, because estimations are always bad

    and you run out of time… DONE DONE DONE DONE
  29. So you are running out time (or whatever your limitation

    is) DONE DONE DONE DONE MAYBE DONE DONE? Next version? #FIXME Forgotten
  30. None
  31. You are here

  32. You still haven’t tested it! BUG BUG BUG BUG BUG

    BUG BUG BUG BUG BUG BUG
  33. You can’t have it all. Manage this reality!

  34. Agile

  35. Agile is about fast iterations

  36. Focusing on frequent delivery of visible value

  37. Software only delivers value when we ship it and put

    it to use! If we wait until everything is finished, it takes a long time until we get any value
  38. height = value, width = cost

  39. Which path makes more sense?

  40. Do the high-value & cheap ones first!

  41. Do plan, but be ready for change.

  42. Why: Because change!

  43. Focusing on frequent delivery of visible value What does it

    take? Got it!
  44. This is not All-or-nothing

  45. Releases! Feature by Feature

  46. • Let’s plan for multiple releases from the very beginning.

    Multiple releases are easier to manage and deliver value sooner. • We can respond to the changing needs and inputs of business/management
  47. “This still sounds a lot like a management process. I

    am a developer, is this really my concern?”
  48. Your role

  49. Focusing on frequent delivery of visible value

  50. You are always ready to ship!

  51. ØFrequent Delivery ØRelease Feature by Feature ØReady to ship at

    all times
  52. • If it takes two days to create a build…

    • If it takes three days of manual QA to create a build... • If it takes one special person to create the build… • If it takes this one five year old computer that no one dares to update, because this one version of the dependency does not compile on a new OS to create the build….
  53. You are always ready to ship!

  54. Defects

  55. Defects add unknown delay.

  56. Everything you build must rest on a solid foundation!

  57. None
  58. •We cannot work effectively in a world of defects •To

    be able iterate, the software needs to be nearly bug-free all the time •We need to check everything, all the time
  59. You must have control over your software.

  60. You must have confidence in your software.

  61. ØFrequent Delivery ØRelease Feature by Feature ØReady to ship at

    all times ØEnsure software works as expected
  62. The ultimate code quality measurement once you satisfied your current

    requirement: How easy are future changes?
  63. Refactoring Code refactoring is the process of restructuring existing computer

    code without changing its external behavior. – Wikipedia Refactoring happens within minutes, not within months. Again, in order to refactor efficiently, you need to be able to check everything all the time.
  64. ØFrequent Delivery ØRelease Feature by Feature ØReady to ship at

    all times ØEnsure software works as expected ØEnsure future changes are easy
  65. •New features •Architecture •Infrastructure •Hotfixes •Performance optimizations •…

  66. Either changing stuff is easy, this means it is good

    code. Or changing stuff is hard, this means you have a problem.
  67. It takes longer to find and fix defects than to

    prevent them.
  68. Hurrying will slow you down • Worse: The timing! It

    will slow you down when you least need it, close to the end of the project. • Dirty code slows you down. If code is clean, the next features go in smoothly. If it gets dirty, everything takes just a bit longer.
  69. Defects create defects Folgefehler: Your math teacher lied to you!

    If your code is faulty or has side-effects, new code building upon this code will be even more faulty with more side-effects. Fixing, maintaining or extending these layers of faulty code will take even more time!
  70. Staying healthy is critical!

  71. Focusing on frequent delivery of visible value

  72. The ability to quickly iterate on your code is a

    Technical capability
  73. If your tech is not agile, you can not be

    agile! Automated Builds Always be able to ship! Automated Testing Everything must work all the time! Refactoring Design must improve continually, to make future changes easy!
  74. Let’s talk about responsibility

  75. None
  76. Responsibility Would you let your [product owner, scrum master, whatever]

    decide on: • Code Editor • Programming Language • Design Patterns Probably not!
  77. So why let them decide on requirements of technical quality?

    The need for refactoring? The test coverage? Can this really part of their role? Do the really know? Can they really decide?
  78. So why let them decide on requirements of technical quality?

    The need for refactoring? The test coverage? Can this really part of their role? Do the really know? Can they really decide? No! Only you. You are the coder. You are the expert.
  79. Responsibility and authority are aligned • The team itself must

    decide how much work it can accomplish in the next cycle. • The team itself is responsible for the quality of the solution.
  80. None
  81. It’s hard

  82. It’s hard Producing good software is very very complicated.

  83. It’s hard Producing good software is very very complicated. It

    takes a lot of effort and care and passion.
  84. It’s hard Producing good software is very very complicated. It

    takes a lot of effort and care and passion. It takes experts like you to make sure that all of this is worthwhile.
  85. Thanks!

  86. Acknowledgements

  87. 40% off with promo code turkeysale2019 ~ 9 USD for

    the ebook
  88. Shitposting powered by • https://twitter.com/agile_memes • https://twitter.com/markdalgleish