Our industry has a problem: We are not lacking software methodologies, programming languages, tools or frameworks but we need great software engineers. Great software engineer teams build quality-in and deliver great software on a regular basis. The technical excellence of those engineers will help you escape the "Waterfall sandwich" and make your organization a little more agile, from the inception of an idea till they go live. I will talk about my experiences from the last 15 years, including small software delivery teams until big financial institutions. Why would a company like to be "agile"? How can a company achieve that? How can you achieve Technical Excellence in your software teams? What developer skills are more important than languages, methods or frameworks? This will be an interactive session with a Q&A at the end.

1. Achieving Technical Excellence
in Your Software Teams
Peter Gfader
@peitor

2. Peter Gfader
The Agile Architect

3. https://www.meetup.com/
Software-Craftsmanship-Zurich/

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“

23. „Deployed“
VS
„Released“
https://beyond-agility.com/deployment-vs-release/

24. Conway‘s Law
organizations which design systems ... are constrained to
produce designs which are copies of the communication
structures of these organizations.
Wikipedia

25. From https://martinfowler.com/articles/microservices.html

26. Conway‘s Law
Extended

27. Via https://www.scrum.org/fredrik-wendt
Conway’s Law Extended

28. The Project Paradox

29. The Project Paradox
https://twitter.com/tofo/status/512666251055742977?s=11

30. What to do?
Delay decisions
Validate architecture with requirements and measure

31. What to do?

32. What Worked
«What do
Great Teams do?»

33. #TODO
Stop Talking „Agile“

34. Via @DavidEvans66

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?

40. # TODO https://www.scrum.org/resources/evidence-based-management-guide

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

50. http://blog.gfader.com/2011/10/broken-window-theory-in-real-world.html
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

63. https://twitter.com/mpetrinidev/status/1042805522603417600

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/

66. Mob Programming
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

72. #TODO Refactoring
https://github.com/NotMyself/GildedRose
https://github.com/jcbozonier/Refactoring-Katas

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

76. Refactoring
+
Tests
=
?

77. Refactoring
+
Tests
=
No Business Value
Waste?? Overhead??

78. Refactoring
+
Tests
=
?

80. Test-Driven Development (TDD)
Writing tests prior to writing the production code
REFACTOR GREEN
RED

81. http://gfader.tumblr.com/post/153724638564/tdd-as-i-think-of-it-november-2016-where-do

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

88. Proper
Root Cause
Analysis

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

104. Go Small
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“

115. Thank You!
https://twitter.com/peitor
https://www.linkedin.com/in/petergfader/
peter@beyond-agility.com
https://beyond-agility.com
Peter Gfader

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/

120. Find out more
beyond-agility.com/stop