What is "Agile"? Why would someone like to be agile? What are the 3 pillars for agile software development? How can you achieve technical excellence in your software teams? Are developer skills more important than languages, methods or frameworks?

1. You can’t be Agile
if your code sucks
Peter Gfader
twitter.com/peitor

2. My Mission
#1 Agile??
#2 Code & Craftmanship

3. About me

4. Peter Gfader
peter.gfader@zuehlke.com
http://blog.gfader.com
twitter.com/peitor

5. Agile

6. What is Agile for you?

7. http://agilemanifesto.org/

10. The Agile Manifesto invites wimpy-ness
"… Individuals and interactions over processes & tools…"
Yayy!! I don't have to follow those stupid processes any more!
"… Working software over comprehensive documentation…"
W00t!! Dump the documentation! I LOVE this agile stuff!
"… Customer collaboration over contract negotiations…"
I'm done when I'm done and I never have to say when!
"… Responding to change over following a plan…"
No plans! No project managers! No architects!
Where do I sign up?
© Alistair Cockburn

11. What is Agile for you?

12. What is all this stuff?
XP
Lean
RUP
SAFe
Agile
© Henrik Knieberg

13. Thinking tools
Tool
a.k.a. ”mindsets” or ”philosophies”
”anything used as a means of
accomplishing a task or purpose.”
- dictionary.com
Physical tools
Lean
Agile
Systems Thinking
Theory of Constraints
Toolkits
a.k.a. ”frameworks”
Scrum RUP XP
Kanban
Process tools
a.k.a. ”organizational patterns”
Product Owner role
Pair programming
Visualize the workflow
5
Dev
3
H
Test
Release
D
To do
C
2
G
3
Done!
A
B
K
FLOW
© Henrik Knieberg

14. © Henrik Knieberg

15. The illusion of a ”bad tool”
The old
tool
was
better!
Don’t blame
the tool!
© Henrik Knieberg

16. Compare for
understanding, not
judgement
Key
point
© Henrik Knieberg

17. Compare for
understanding, not
judgement
Key
point
Tools can be
combined
© Henrik Knieberg

18. • Know your Goal
Take-away points
o Why
• Agile/Lean are tools, not goals
• Don’t limit yourself to one tool
• Experiment & enjoy the ride
o Don’t worry about getting it right from
start
© Henrik Knieberg
• We won’t

19. RUP
XP
Lean
SAFe
Agile
© Henrik Knieberg

20. The important thing isn’t the process.
© Henrik Knieberg

21. The important thing isn’t the process.
The important thing is the process for
improving your process.
© Henrik Knieberg

22. The important thing isn’t the process.
The important thing is the process for
improving your process.
Continuous Improvement
© Henrik Knieberg

23. 3 essential skills needed
regardless of process
Splitting the system into
useful pieces
Software
craftsmanship
Retrospectives
As a buyer
I want to save my shopping cart
so that I can continue shopping later
© Henrik Knieberg

24. 3 essential skills needed
regardless of process
Splitting the system into
useful pieces
As a buyer
I want to save my shopping cart
so that I can continue shopping later
Software
craftsmanship
Retrospectives

25. 3 essential skills needed
regardless of process
Splitting the system into
useful pieces
As a buyer
I want to save my shopping cart
so that I can continue shopping later
Software
craftsmanship
Retrospectives

26. Essential Skill:
Software craftsmanship

27. 1) Software is never written
once and never changed

28. [LARM03]

29. 2) How to slow down your
project?

32. Write crappy code
 Make code easier to read

33. Easy code to read
 Easy code to change
maintain

34. Why do you write bad code?

35. #1 reason for Bad code
We write bad code,
because we read bad code

36. Code Readings?
•
•
•
•
Code Reviews
Peer Reviews
Pair Programming
Open source

37. Good code is like a joke!
No need for explanation

38. #TODO: Code to read
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

39. #TODO: Review Code
•
•
•
•
In your team
With 1 peer
Open source
Brown bags – Lunch time discussion

40. Code Reviews
• Code, !Person
• Constructively propose changes
 Questions!

41. Code Reviews
• Code, !Person
• Constructively propose changes
 Questions!
• Review not only code
o Tests
o Build process
o ..

42. Code Reviews
• Code, !Person
• Constructively propose changes
 Questions!
• Review not only code
o Tests
o Build process
o ..
 Grow as a team

43. Instead of
“That lousy long method”
Say
“Why don’t you split that
method”
“I reviewed your code and
found 1,2,3 things to
change”
“Can you help me?”
“If you don’t want to do it. I
do it”
“Can I help you with this? I
think we can improve it”

44. #2 reason for Bad code
Nobody can write good code in 1 sit-in
-> Refactoring
it’s an art of designing code

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

46. The little issue with
Refactoring?

47. Development With and Without Testing
Without Tests
• Don’t know our own quality
• Unclear what works and what
doesn't
• Unintended consequences of
changes remain hidden
• We are never done
With Tests
• Change and refactor without
fear
• Add new features faster
• Confidence that we didn't
break anything
• We can actually be done
Done = Tested!

48. Refactoring
+
Tests
=
?

49. Refactoring
+
Tests
=
Waste?? Overhead??

50. Test-Driven Development (TDD)
• Writing tests prior to writing the production code
• Test-Driven Development is
o
o
o
o
A design practice
A powerful way to avoid defects in software
A feedback loop for validating code changes
A way to write tests
REFACTOR
RED
GREEN

51. Test-Driven Development (TDD)
Goal is not to write tests
but to write good code
RED
REFACTOR
GREEN

52. What is Quality

53. “Why should I care?
We have a QA department!”

54. **** ADD PIC ****

55. How do you measure
Quality?

57. First Law of Programming
“Lowering Quality Lengthens
Development Time”
http://c2.com/cgi/wiki?FirstLawOfProgramming

58. Only Quality lets us go faster!

59. http://manifesto.softwarecraftsmanship.org/

60. Who?

61. Quality?
• Measure of how well the software is
designed and implemented
• Subjective

62. Quality?
•
•
•
•
•
•
LOC
Code Coverage
Class Coupling
Cohesion
Code Duplication
Cyclomatic Complexity

63. Quality: How to measure?
•
•
•
•
•
•
•
Highly subjective
Highly qualitative
Is the code readable, understandable?
Is the code verbose?
Variable/method names that are meaningful
Simple code that works
Does it have tests? What’s the coverage?

64. Quality: How to measure?
• Trends

65. Quality: How to measure?
• Trends
• “Output” over time
o Velocity - Trend
o Business Value - Trend
o Bug – Trends
• #TODO: How do you measure Business value?

66. Ways to Improve Quality
• Avoid Silo Thinking
o
•
•
•
•
•
•
•
Its not “us” vs “them”
Start early
Don’t Compromise
Schedule time to lower your technical debt
Make it work; make it right (right away)
Requires monitoring and changing behavior
Be willing to help and be helped
Devise lightweight non-bureaucratic measures

67. Simple Design == High Quality?
•
•
•
•
Passes its tests
Minimizes duplication
Maximizes clarity
Has fewer elements
http://c2.com/cgi/wiki?XpSimplicityRules

68. #TODO Visualize
•
•
•
•
•
Bug Trends
Build Status
Performance Report
Technical Debt
Code Quality

69. Visualize Technical Debt
http://verraes.net/2013/07/managed-technical-debt/

70. Build Monitor

71. Checkin Frequently
• Focus your work on small tasks
• Easier to describe what you did in your check-in
comment
• Clear code history
• Easier merging -> if you really need to branch and merge
• Fast code reviews
• Never get merge hell -> only give it :-)
http://blog.gfader.com/2011/12/tfs-see-your-application-grow-like.html

72. Team Efforts
• Avoid Shortcuts
• Take collective ownership
Team should own the code
• Promote positive interaction
• Provide constructive feedback
• Constant code review

73. Guantanamo Code Tool
• All code is guilty until tested innocent
• Do you have problems maintaining high test coverage?
• Send the untested code to
Guantanamo!
http://docs.codehaus.org/display/ASH/Guantanamo

74. Agile – the bar is rising
http://blog.gfader.com/2013/05/the-1st-principle-of-agile-manifesto-30.html

75. Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software
1st principle of the Agile Manifesto

76. Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software
1st principle of the Agile Manifesto

77. Recap

78. The important thing isn’t the process
The important thing is the process for
improving your process

79. Essential skills needed
regardless of process
Splitting the system into
useful pieces
As a buyer
I want to save my shopping cart
so that I can continue shopping later
Software
craftsmanship
Retrospectives

80. #TODO TO READ
E. Goldratt “The Goal”
S.Freeman, N.Price GOOS

81. #TODO 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-conference2010/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/

82. Now you
1.
2.
3.
4.
Download presentation
Search for #TODO
Get it done
Send me a tweet “I’m done”

83. Continue the conversation
peter.gfader@zuehlke.com
twitter.com/peitor
http://blog.gfader.com