Achieving Technical Excellence in Your Software Teams - from Devternity
4 likes690 views
The document discusses achieving technical excellence in software teams, emphasizing the importance of delivering value over merely focusing on output. It highlights practices such as proper root cause analysis, maintaining a zero-bug policy, and using techniques like pair programming and code reviews to improve code quality. The content advocates for agile principles and continuous improvement to better meet customer needs and enhance team performance.
Achieving Technical Excellence in Your Software Teams - from Devternity
- 1. Achieving Technical Excellence in Your Software Teams Peter Gfader @peitor
- 2. Peter Gfader The Agile Architect
- 4. Achieving Technical Excellence in Your Software Teams
- 5. Achieving Technical Excellence in Your Software Teams
- 6. We are Super Heroes Build elegant systems Manage the customer Manage projects Know the tech stuff Smartest guy/gal on planet Write amazing clean code We
- 7. But…
- 12. It takes way too long
- 14. Customers don’t care • Architecture • Lean or Clean Code • React vs Angular vs Aurelia vs vanillaJs • Refactorings and your keyboard shortcuts • Your Fancy Feature Branching Strategy • Technologies • Your Scrum or my Kanban • Dependencies • Your Feelings
- 15. Customers really care Their problems to be understood and solved
- 16. Build Right It Build It Right Right Time
- 17. The Right Product, Right and Fast
- 18. Achieving Technical Excellence in Your Software Teams
- 19. Technical Excellence „Working Software at the End of Every Sprint“
- 20. Technical Excellence „Working Product Increment Deployed on Every Push“
- 21. Technical Excellence „Working Product Increment Deployed on Every Push“
- 22. Technical Excellence „Working Product Increment Deployed on Every Push“
- 24. Conway‘s Law organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations. Wikipedia
- 30. What to do? Delay decisions Validate architecture with requirements and measure
- 31. What to do?
- 32. What Worked «What do Great Teams do?»
- 35. „Scrum says“ „This is not Agile“ „Let‘s do this in an agile way“ „XP recommends …“ „In the SAFe book its written“ „This is not Lean enough“ „You must be co-located for XP“ „Let’s make this transparent by putting it in wall” “We are iterative and adaptive” “Great showcase and demo” „Customer“ „User“ „Risk“ „Market“ „Competition“ „Value“ „Product“ „Sponsor” „Money” #moreContent Stop Start https://beyond-agility.com/stop/
- 36. „How do we become agile?“ How can we discover and deliver Value faster? What is Value in our Organization? Product? https://beyond-agility.com/stop/
- 37. What Worked Great Teams talk and Focus on Value and Not Output.
- 38. What Worked Great Teams deliver Value and Not just Output.
- 39. How to quantify Value?
- 41. Value Metrics #TODO Evidence-Based Management Metrics https://www.scrum.org/resources/evidence-based-management-guide Metrics for Pirates AARRR https://www.slideshare.net/dmc500hats/startup-metrics-for-pirates- long-version Googles HEART https://www.dtelepathy.com/ux-metrics/
- 42. #TODO Start Investing In Quality
- 44. Quality
- 45. How to slow down your teams?
- 48. Why do we write bad code?
- 49. 1. Hypothesis For Bad Code Broken Window Theory
- 51. 2. Hypothesis For Bad Code We write bad code, because we read bad code
- 52. Write crappy code? You have never seen good code! Santa Claus. Osterhase.
- 53. Write crappy code? You have never seen good code! Read good code → Make code easier to read
- 54. Easy code to read → Easy code to change → Easy to maintain
- 55. Code Readings? • Code Reviews • Peer work reviews • Pair Programming • Mob Programming • Pre Commit • Gerrit • Pull Requests
- 56. Code Readings? • Peer Reviews • Whole Team Code Reviews • Pair Programming • Mob Programming • Pre Commit • Gerrit • Pull Requests • Open source (Read? Write?)
- 57. #TODO Tips Code Reviews • Code, !Person • Constructively propose changes → Questions!
- 58. Code Reviews • Code, !Person • Constructively propose changes → Questions! • Review not only code o Tests o Build process o ..
- 59. Code Reviews • Code, !Person • Constructively propose changes → Questions! • Review not only code o Tests o Build process o .. → Grow as a team
- 60. Instead of “This must be Jon’s code” “That ugly long method” “I reviewed your code and changed it to make it better” #Todo
- 61. Pair Programming
- 64. #TODO Strong Style Pair Programming "For an idea to go from your head into the computer it MUST go through someone else's hands" http://llewellynfalco.blogspot.com/2014/06/llewellyns-strong-style-pairing.html
- 65. Mob Programming • Whole team • Work on same thing • Same time • Same space • Same computer http://mobprogramming.org/
- 67. #TODO: Review Code • In your team • With 1 peer • Open source • Brown bags – Lunch time discussion
- 68. #TODO: Code to read in the Team https://github.com/nsubstitute/NSubstitute https://github.com/techtalk/SpecFlow https://github.com/sf105/goos-code https://github.com/machine/machine.specifications https://github.com/BjRo/xunitbddextensions https://github.com/dtchepak/DaveSquared.StringsTheThing And more on the internetz.... Good code is like a joke!
- 69. Good code is like a joke! No need for explanation
- 70. 3. Hypothesis For Bad Code “Nobody can write good code in 1 sit-in.” There is no “Right the 1st time”
- 71. 3. Hypothesis For Bad Code Nobody can write good code in 1 sit-in -> Refactoring
- 73. The little issue with Refactoring?
- 74. Unclear what works and what doesn’t We are never done. Without Tests
- 75. Change and refactor without fear. With Tests
- 77. Refactoring + Tests = No Business Value Waste?? Overhead??
- 80. Test-Driven Development (TDD) Writing tests prior to writing the production code REFACTOR GREEN RED
- 82. → Outside world and code do not match → Implemented requirements unclear → Code not understandable TDD Outside In
- 83. Test Driven Development TDD = Testing technique? TDD = Design technique? TDD = Learning technique? TDD = Thinking technique?
- 84. Habit 2/7 Begin with the end in mind
- 85. #Todo Find your peers https://www.meetup.com/topics/software-craftsmanship/
- 86. All fine... But we are here
- 87. 4 Things 1. Proper Root Cause Analysis 2. Get to Done 3. Go Small 4. 0 Bug Policy
- 89. Proper Root Cause Analysis 1. Gather Data on Sprint Board
- 90. Proper Root Cause Analysis 2. Cluster and Analyse in Retrospective 5Whys
- 91. Proper Root Cause Analysis 3. Delegate to Team Dive deeeeeep
- 92. Proper Root Cause Analysis 4. How to prevent this in future?
- 93. Proper Root Cause Analysis 5. Maximize learning From individuals to team (s) to organizational learning
- 94. 5 Steps - Proper Root Cause Analysis 1. Gather Data 2. Retrospective 3. Delegate to Team -> Deep Dive 4. Prevent this in the future 5. Maximize learning
- 95. Get to Done Do you have a Definition Of Done? https://www.digicomp.ch/blog/2019/05/22/5-praktiken-die-bei-der-agilen-software-entwicklung-helfen
- 96. Get To Done
- 97. Get to Done Do you have a Definition Of Done? https://www.digicomp.ch/blog/2019/05/22/5-praktiken-die-bei-der-agilen-software-entwicklung-helfen
- 98. Get to Done • Do you have a Definition Of Done?
- 99. Get to Done • Do you have a Definition Of Done?
- 100. Get to Done • Get rid of your Definition Of Done
- 101. Get to Done • Get rid of your Definition Of Done
- 102. Go Small
- 103. Go Small 1 Piece Flow As A Team https://www.digicomp.ch/blog/2019/06/24/wieso-das-management-development-teams-nicht-vertraut
- 105. 0 Bug Policy
- 106. 0 Bug Policy 1. Write a failing Test for every Bug (before you fix the bug) 2. Automate
- 107. 0 Bug Policy
- 108. How to sell to Managers? Investment
- 109. How to sell to Managers? Investment Well crafted & tested code is expensive.
- 110. Investment Well crafted & tested code is expensive. Fixing bad code is very, very, very, very expensive.
- 111. Now You!
- 112. Work on your fitness & Be ready Start practicing
- 113. Work on your fitness & Be ready Start practicing “We don’t have a knowledge problem. We have a practice problem. Can you do what you preach?”
- 114. What hinders you to Add to your Definition of Done • Deployed to Production • Released to (10%) Alpha Users • Released to All „Metric X increased by Y% for customer segment Z“
- 116. References Your Todo List ☺
- 117. • Steve Denning 3 Laws of Business Agility https://www.infoq.com/presentations/3-laws-business-agility • Steve Denning – Why Agile https://businessagility.institute • Future Leadership Training • Haier HBR – The end of bureaucracy https://hbr.org/2018/11/the-end-of-bureaucracy • Book: The Leader's Guide to Radical Management http://www.stevedenning.com/Books/radical-management.aspx References
- 118. References • Pragmatics of Agile Development http://www.agiledeveloper.com/presentations/pragmatics_of_agile_development.pdf • Kanban VS Scrum http://www.infoq.com/minibooks/kanban-scrum-minibook • Agile Software Development http://www.agiledeveloper.com/presentations/AgileSoftwareDevelopment.zip • A Thinking Tool called Agile https://sites.google.com/site/leanagileandscrum/lean-agile-scrum-conference- 2010/presentations-las-2010/00_Kniberg_Keynote.pdf?attredirects=0&d=1 • The Four Elements of Simple Design http://www.jbrains.ca/permalink/the-four-elements-of-simple-design • http://agilemanifesto.org/ • http://manifesto.softwarecraftsmanship.org/
- 119. Picture References • https://gratisography.com/ • https://businessagility.institute • https://twitter.com/peitor • https://craigsmith.id.au/2015/12/03/yow-2015-40-agile-methods-in-40-minutes/