$30 off During Our Annual Pro Sale. View Details »

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.

Christian Bäuerlein

November 28, 2019
Tweet

More Decks by Christian Bäuerlein

Other Decks in Programming

Transcript

  1. Agile Software Development

    View Slide

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

    View Slide

  3. View Slide

  4. View Slide

  5. View Slide

  6. View Slide

  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

    View Slide

  8. • How to build good software.
    What this talk is about

    View Slide

  9. History of development processes…

    View Slide

  10. The Waterfall

    View Slide

  11. The Waterfall
    No idea,
    if all of this makes sense
    and if we are doing well.
    Deadline

    View Slide

  12. The Waterfall
    Test-and-fix interval
    • Seems To take forever
    • Guaranteed to break time planning
    • Nobody is happy at this time

    View Slide

  13. View Slide

  14. The Agile Manifesto

    View Slide

  15. View Slide

  16. Kent Beck
    • Co-founded XP
    • “Smalltalk Best Practice Patterns”
    • “Test-Driven Development
    by Example”
    • Started the xUnit trend

    View Slide

  17. Martin Fowler
    • “Refactoring: Improving the
    Design of Existing Code”
    • “Patterns of Enterprise
    Application Architecture“
    • Popularized the
    Dependency Injection pattern

    View Slide

  18. Bob Martin aka Uncle Bob
    • “Clean Code”
    • “The Clean Coder”

    View Slide

  19. Dave Thomas
    • “Programming Ruby” aka The Pick Axe
    • “The Pragmatic Programmer”
    • Coined the term “DRY”
    • runs The Pragmatic Bookshelf

    View Slide

  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!

    View Slide

  21. So… what is this about?

    View Slide

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

    View Slide

  23. The features

    View Slide

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

    View Slide

  25. What features do you want?

    View Slide

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

    View Slide

  27. You start building…

    View Slide

  28. But your estimations are bad, because estimations are
    always bad and you run out of time…
    DONE
    DONE
    DONE
    DONE

    View Slide

  29. So you are running out time
    (or whatever your limitation is)
    DONE
    DONE
    DONE
    DONE
    MAYBE
    DONE
    DONE?
    Next version?
    #FIXME
    Forgotten

    View Slide

  30. View Slide

  31. You are
    here

    View Slide

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

    View Slide

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

    View Slide

  34. Agile

    View Slide

  35. Agile is about
    fast iterations

    View Slide

  36. Focusing on
    frequent delivery of
    visible value

    View Slide

  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

    View Slide

  38. height = value, width = cost

    View Slide

  39. Which path makes more sense?

    View Slide

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

    View Slide

  41. Do plan, but be ready for change.

    View Slide

  42. Why: Because change!

    View Slide

  43. Focusing on
    frequent delivery of
    visible value
    What does it take?
    Got it!

    View Slide

  44. This is not
    All-or-nothing

    View Slide

  45. Releases!
    Feature by Feature

    View Slide

  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

    View Slide

  47. “This still sounds a lot like a management
    process. I am a developer, is this really my
    concern?”

    View Slide

  48. Your role

    View Slide

  49. Focusing on
    frequent delivery of
    visible value

    View Slide

  50. You are always
    ready to ship!

    View Slide

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

    View Slide

  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….

    View Slide

  53. You are always
    ready to ship!

    View Slide

  54. Defects

    View Slide

  55. Defects add
    unknown delay.

    View Slide

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

    View Slide

  57. View Slide

  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

    View Slide

  59. You must have control
    over your software.

    View Slide

  60. You must have confidence
    in your software.

    View Slide

  61. ØFrequent Delivery
    ØRelease Feature by Feature
    ØReady to ship at all times
    ØEnsure software works as
    expected

    View Slide

  62. The ultimate code quality measurement once
    you satisfied your current requirement:
    How easy are future changes?

    View Slide

  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.

    View Slide

  64. ØFrequent Delivery
    ØRelease Feature by Feature
    ØReady to ship at all times
    ØEnsure software works as
    expected
    ØEnsure future changes are easy

    View Slide

  65. •New features
    •Architecture
    •Infrastructure
    •Hotfixes
    •Performance optimizations
    •…

    View Slide

  66. Either changing stuff is easy,
    this means it is good code.
    Or changing stuff is hard,
    this means you have a problem.

    View Slide

  67. It takes longer to find
    and fix defects than to
    prevent them.

    View Slide

  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.

    View Slide

  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!

    View Slide

  70. Staying healthy
    is critical!

    View Slide

  71. Focusing on
    frequent delivery of
    visible value

    View Slide

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

    View Slide

  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!

    View Slide

  74. Let’s talk
    about
    responsibility

    View Slide

  75. View Slide

  76. Responsibility
    Would you let your
    [product owner, scrum master, whatever] decide on:
    • Code Editor
    • Programming Language
    • Design Patterns
    Probably not!

    View Slide

  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?

    View Slide

  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.

    View Slide

  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.

    View Slide

  80. View Slide

  81. It’s hard

    View Slide

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

    View Slide

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

    View Slide

  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.

    View Slide

  85. Thanks!

    View Slide

  86. Acknowledgements

    View Slide

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

    View Slide

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

    View Slide