Download as PDF, PPTX
Uploaded byPeter Gfader
Achieving Technical Excellence in Your Software Teams - from Devternity
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.
More Related Content
Similar to Achieving Technical Excellence in Your Software Teams - from Devternity
Achieving Technical Excellence in Your Software Teams - from Devternity
- 1. Achieving Technical Excellence inYour Software Teams Peter Gfader @peitor
- 2. Peter Gfader The AgileArchitect
- 3.
- 4. Achieving Technical Excellence inYour Software Teams
- 5. Achieving Technical Excellence inYour Software Teams
- 6. We are SuperHeroes Build elegant systems Manage the customer Manage projects Know the tech stuff Smartest guy/gal on planet Write amazing clean code We
- 7.
- 12. It takes waytoo 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 Theirproblems to be understood and solved
- 16. Build Right It BuildIt Right Right Time
- 17. The Right Product,Right and Fast
- 18. Achieving Technical Excellence inYour Software Teams
- 19. Technical Excellence „Working Software atthe End of Every Sprint“
- 20. Technical Excellence „Working ProductIncrement Deployed on Every Push“
- 21. Technical Excellence „Working ProductIncrement Deployed on Every Push“
- 22. Technical Excellence „Working ProductIncrement Deployed on Every Push“
- 23.
- 24. Conway‘s Law organizations whichdesign systems ... are constrained to produce designs which are copies of the communication structures of these organizations. Wikipedia
- 25.
- 26.
- 27.
- 28.
- 29.
- 30. What to do? Delaydecisions Validate architecture with requirements and measure
- 31.
- 32. What Worked «What do GreatTeams do?»
- 33.
- 34.
- 35. „Scrum says“ „This isnot 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?“ Howcan we discover and deliver Value faster? What is Value in our Organization? Product? https://beyond-agility.com/stop/
- 37. What Worked Great Teamstalk and Focus on Value and Not Output.
- 38. What Worked Great Teamsdeliver Value and Not just Output.
- 39. How to quantifyValue?
- 40.
- 41. Value Metrics #TODO Evidence-BasedManagement 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 InQuality
- 44.
- 45. How to slow down yourteams?
- 48. Why do wewrite bad code?
- 49. 1. Hypothesis ForBad Code Broken Window Theory
- 50.
- 51. 2. Hypothesis ForBad Code We write bad code, because we read bad code
- 52. Write crappy code? Youhave never seen good code! Santa Claus. Osterhase.
- 53. Write crappy code? Youhave never seen good code! Read good code → Make code easier to read
- 54. Easy code toread → Easy code to change → Easy to maintain
- 55. Code Readings? • CodeReviews • Peer work reviews • Pair Programming • Mob Programming • Pre Commit • Gerrit • Pull Requests
- 56. Code Readings? • PeerReviews • Whole Team Code Reviews • Pair Programming • Mob Programming • Pre Commit • Gerrit • Pull Requests • Open source (Read? Write?)
- 57. #TODO Tips CodeReviews • 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 mustbe Jon’s code” “That ugly long method” “I reviewed your code and changed it to make it better” #Todo
- 61.
- 63.
- 64. #TODO Strong Style PairProgramming "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 • Wholeteam • Work on same thing • Same time • Same space • Same computer http://mobprogramming.org/
- 66.
- 67. #TODO: Review Code •In your team • With 1 peer • Open source • Brown bags – Lunch time discussion
- 68. #TODO: Code toread 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 islike a joke! No need for explanation
- 70. 3. Hypothesis ForBad Code “Nobody can write good code in 1 sit-in.” There is no “Right the 1st time”
- 71. 3. Hypothesis ForBad Code Nobody can write good code in 1 sit-in -> Refactoring
- 72.
- 73. The little issuewith Refactoring?
- 74. Unclear what works andwhat doesn’t We are never done. Without Tests
- 75.
- 76.
- 77.
- 78.
- 80. Test-Driven Development (TDD) Writingtests prior to writing the production code REFACTOR GREEN RED
- 81.
- 82. → Outside worldand 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 withthe end in mind
- 85. #Todo Find yourpeers https://www.meetup.com/topics/software-craftsmanship/
- 86. All fine... Butwe are here
- 87. 4 Things 1. ProperRoot Cause Analysis 2. Get to Done 3. Go Small 4. 0 Bug Policy
- 88.
- 89. Proper Root CauseAnalysis 1. Gather Data on Sprint Board
- 90. Proper Root CauseAnalysis 2. Cluster and Analyse in Retrospective 5Whys
- 91. Proper Root CauseAnalysis 3. Delegate to Team Dive deeeeeep
- 92. Proper Root CauseAnalysis 4. How to prevent this in future?
- 93. Proper Root CauseAnalysis 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 Doyou have a Definition Of Done? https://www.digicomp.ch/blog/2019/05/22/5-praktiken-die-bei-der-agilen-software-entwicklung-helfen
- 96.
- 97. Get to Done Doyou 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.
- 103. Go Small 1 PieceFlow As A Team https://www.digicomp.ch/blog/2019/06/24/wieso-das-management-development-teams-nicht-vertraut
- 104.
- 105.
- 106. 0 Bug Policy 1.Write a failing Test for every Bug (before you fix the bug) 2. Automate
- 107.
- 108. How to sellto Managers? Investment
- 109. How to sellto 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.
- 112. Work on yourfitness & Be ready Start practicing
- 113. Work on yourfitness & 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 youto 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“
- 115.
- 116.
- 117. • Steve Denning3 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 ofAgile 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/
- 120.