This document discusses the challenges and misconceptions surrounding collaborative software development, emphasizing the importance of people over technology. It presents five impractical aspects of Agile methodologies, including the need for customer involvement, test-driven development, quality over schedule, pair programming, and code katas. The author advocates for a focus on quality, continuous improvement, and the necessity of engaging with customers to achieve effective software projects.

1. o th er
D a nd
TD
min g,
in g s
ir P ro gram
c a l th
Pa
rac ti
im p
by @_md

2. I coach teams into
collaborative software development

3. software is about people

4. software is not as much about Øs and 1s
Ø111ØØØ1ØØ111ØØØ1ØØ111ØØ111111ØØ111Ø111ØØ
Ø1ØØ111ØØØ1ØØ111ØØØ1ØØ111ØØØ1ØØ111ØØØ1Ø
Ø111ØØ111111ØØ1111111ØØØ1ØØ111ØØ1Ø1111ØØ111

5. as it is about Xs and Ys

6. {
use it
it’s people who

7. {
use it
develop it
it’s people who

8. {
use it
develop it
it’s people who order it

9. {
use it
develop it
it’s people who order it
accept it
...

10. coding is not as hard as collaborating

11. 1 impractical thing #1
Listen to your customer

12. Customers don’t know what they want
Customers change their mind all the time
Customers are too busy to get involved
i mp ra ct ic a l
If I listen... BANG! Scope creeps in!
Customers want everything!
I keep adding and removing must haves

13. http://www.photoree.com/photos/permalink/137988-22339026@N00
why do I need to listen?
can I please just sit and write my code?

15. http://www.flickr.com/photos/samsungtomorrow/8096115179/

16. “Nobody wants a washing machine just to
have a machine, but to have clean clothes.”
– Jon Sundbo

17. When to listen?

18. Continuously

19. project mission sprint planning sprint vision sign off retrospective

20. project mission sprint vision sprint planning sign off retrospective
First create a project mission
based on business goals...
not scope!

21. http://impactmapping.org

22. impact map WHAT
HOW
WHAT
WHO
WHY HOW
WHAT
WHO
HOW
WHAT
[Adzic 2012]

23. project mission sprint vision sprint planning sign off retrospective
Include a sprint vision (example) workshop
in every iteration, prior to sprint planning

24. Goal of sprint vision (example) workshop
To define sprint vision and acceptance criteria

25. As an <actor>
I can <behaviour>
So that <value>
Given <pre-condition>
When <act>
product backlog
Then <expectation>

26. What if the customer isn’t available?

27. proxy

28. project mission sprint vision sprint planning sign off retrospective
Write the form for
the comment area
1/2 d
product backlog
sprint backlog

29. project mission sprint vision sprint planning sign off retrospective

30. project mission sprint vision sprint planning sign off retrospective

31. 2 impractical thing #2
Test Driven Development

32. How can I test something I haven’t done yet?
It takes time to learn TDD
The team is not confident they can do it
i mp ra ct ic a l
It’s legacy. The code is untestable
Customer is not paying for tests
My manager doesn’t give me time to test

33. requirements
analysis
design
code
test
deploy

34. requirements
analysis
9
m
on
th
design
code
s
test
deploy

36. most of the cost in software comes from
feedback delay

37. user stories
conversation
test
design code
deploy increment

38. user stories
conversation
test
20 min
design code
deploy increment

39. test
refactor code

40. test
Arrange
Act
Assert

41. test
Arrange
Write the code
Act you wish you had
Assert

42. code
Change the message or get it green, not right

43. refactor
Now get it right. Without modifying behaviour.

44. refactor
1. All tests run and pass
2. Remove duplication
3. Remove opacity
4. Remove complexity

45. results in code
1. Testable
2. Modular
3. Expressive
4. Simple

46. lack of tests breaks inner quality
1. Viscosity
2. Immobility, Rigidity, Fragility
3. Unreadable
4. Complex

47. THE CODE IS TERRIBLE!!
WE NEED ONE SPRINT TO REFACTOR

48. Refactoring: changing the structure
not the external behaviour
– Fowler, 99

49. There is no refactoring without tests
There is no testing without refactoring

50. “Code is a representation of design”
– Jack W. Reeves

51. refactoring === design

52. Agile without TDD*
is like cinema without popcorn
*or similar practice

53. 3 impractical thing #3
Focus on Quality over Schedule

54. There is no time for quality
The budget doesn’t cover quality
It’s a very simple project
i mp ra ct ic a l
We’ve done it thousand times
Quality is vague, deadlines are real!
Do the needful now. We’ll come back to it later

55. Outer Quality
Quality is like onions
Inner Quality
http://www.flickr.com/photos/monteregina/4103317832/

56. Outer Quality
Works as expected Built efficiently
Looks like expected Focused on goals

57. Inner Quality
Testable Modular
Expressive Simple

58. Lack of Outer Quality Causes...

59. http://www.flickr.com/photos/hayeycart/5900737110/
Rework Going over budget
Bugs Low Morale
Missing deadlines Project abortion
Unusable systems Relationships deteriorate

60. But what causes poor Outer Quality?

61. Lack of automated acceptance tests
Lack of customer involvement
Team not focused on Project Mission
Lack of Inner Quality

62. Lack of automated acceptance tests
Lack of customer involvement
Team not focused on Project Mission
Lack of Inner Quality

63. Focus on schedule
Fear
Low morale Haste
Re-work

64. Focus on quality
Align with goals
Pride Do the right
thing
Achieve

65. How do you ensure Outer Quality?

66. Example workshops
Automate acceptance tests
Have a sprint vision statement
Sign off during Sprint

67. How do you ensure Inner Quality?

68. TDD
CI (tests, static analysis) from day one
Pair Programming or at least Peer Review

69. 4impractical thing #4
Pair Programming

70. 2 resources 1 task? do the math!
Why isn’t everyone else doing it?
They will just chat and not get anything done
i mp ra ct ic a l
I do all the work the other guy just looks
How do you track the time per task?
Geeks don’t want to talk to other people

71. 2 developers
sharing a screen
working on the same task

72. What is Pair Programming about?

74. Addiction
Company Feedback
Jon Jagger’s Principles of Improvement
Visibility Provocation
Success

75. Pair programming is about improving faster

76. One of the few proven agile practices
“Strengthening the case
for pair programming”
bit.ly/pair-case

77. Should pairs be kept together?

78. Who to pair with who?

79. Important stuff
✓ Focus on the code
✓ Use the test list
✓ Don’t “I-show-you” your pair
✓ Time box decisions

80. How do I learn this?

81. 5
impractical thing #5
Code Katas

82. Who’s paying for that?
What? Write code and delete it? What?
I am already working 9 to 5
i mp ra ct ic a l
Solving a problem that has already been solved?
I am committed to a sprint
I have a release, can’t join you today

83. “Adults don’t think their way into a new way of acting.
They act their way into a new way of thinking” –
Richard Pascale

84. ✓ 1 hour every week
✓ developers go to a meeting room
✓ do TDD in pairs
✓ 20 mins each round
✓ at the end of each round:
✓ delete the code and swap pairs

85. http://lmgtfy.com/?q=code+kata

86. “We have a great tool in this language. We can kill
it by making a mess. We can kill it by being
arrogant. We can kill it by ignoring the enterprise.”

88. “Be daring, be different, be impractical, be anything
that will assert integrity of purpose and imaginative
vision against the play-it-safers, the creatures of the
commonplace, the slaves of the ordinary.”
ImpracticalQuote

89. Marcello Duarte
I work here
I contribute here
I tweet here @_md

90. Thank you !

91. Questions or Comments?
joind.in/8110 slidesha.re/13sYRzS
looking for a new challenge? inviqa.com/careers