The document discusses lessons learned from an agile team's experiences improving learning in an agile environment. It describes several practices the team implemented, including open seating to facilitate discussions, pair programming with varied levels of experience, programming on Sundays, brown bag sessions to present various topics, asynchronous discussion lists, blogging, attending and organizing conferences, and building relationships both during and after work. The key lessons are that learning is the base for adapting in agile environments, teaching and sharing knowledge should be mutual, everyone has something to teach, and companies should experiment with different practices to improve learning.

1. INCREASING LEARNING IN
AN AGILE ENVIRONMENT:
LESSONS LEARNED
IN AN AGILE TEAM
Mauricio Aniche (@mauricioaniche)
Guilherme Silveira (@guilhermecaelum)

2. MAURICIO ANICHE
@mauricioaniche

3. GUILHERME SILVEIRA
@guilhermecaelum

4. GUILHERME SILVEIRA
@guilhermecaelum

5. GUILHERME SILVEIRA
@guilhermecaelum

6. GUILHERME SILVEIRA
@guilhermecaelum

7. BRAZIL!

8. BRAZIL!

9. BRAZIL!

10. BRAZIL!

11. CAELUM

12. TRAINING

13. OPEN SOURCE

14. OPEN SOURCE

15. OPEN SOURCE

16. OPEN SOURCE

17. OPEN SOURCE

18. CONFERENCE ORGANIZERS

19. CONFERENCE ORGANIZERS

20. CONFERENCE ORGANIZERS

21. CONFERENCE ORGANIZERS

22. Caelum’s goal is to improve the
market’s knowledge.

23. DAILY WORK

24. it’s all about innovating
in order to teach

25. EXPERIENCE

26. EXPERIENCE
LEARN

27. EXPERIENCE
LEARN
ADAPT EVOLVE

28. EXPERIENCE
LEARN
ADAPT EVOLVE

29. EXPERIENCE
LEARN
ADAPT EVOLVE
AGILE

30. TEACHING
LEARN
ADAPT EVOLVE
AGILE

31. LEARNING
ALLOWS ADAPTATION
AND EVOLUTION,
THE BASE FOR AGILE

32. how do we teach
our coworkers?

33. LEARNING IS PART OF
OUR JOBS

34. STUDYING AS A TASK

35. STUDYING AS A TASK
when?

36. STUDYING AS A TASK
when?
what?

37. STUDYING AS A TASK
when?
what?
how?

38. STUDYING AS A TASK
when?
what?
how?
“the person is sometimes guided and sometimes
free to decide what to study”

39. IS IT POSSIBLE TO LEARN...

40. IS IT POSSIBLE TO LEARN...

41. IS IT POSSIBLE TO LEARN...

42. IS IT POSSIBLE TO LEARN...
E ?
T I M
H E
L T
AL

43. HOW TO
IMPROVE
LEARNING?

44. OPEN SPACES

45. You have no fixed position
There are no partitions/walls

46. easy to discuss topics

47. easy to discuss topics

48. easy to discuss topics

49. DISCUSSIONS BECOME
BLOG POSTS

50. The discussion which is interesting to the team,
will probably be interesting to others.

51. EVERYONE
TALKS

52. EVERYONE
TALKS

53. too much noise!

54. too much noise!

55. SILENT
THURSDAY

56. Leave the space open for people
to share knowledge.

57. programming

58. pair
programming

59. EXPERIENCED
WITH
NON-
EXPERIENCED

60. EXPERIENCED
WITH
NON-
EXPERIENCED

61. EXPERIENCED
WITH
EXPERIENCED

62. NON-
EXPERIENCED
WITH
NON-
EXPERIENCED

63. There are no fixed rules.

64. There are no fixed rules.
No pairing can also be good.

65. some variations
did not work

66. but some closed
pairing groups are formed...

67. MATRIX

68. MATRIX

69. PAIR
PROGRAMMING
MATRIX

70. PAIRING IN DIFFERENT
PROJECTS

71. anytime, anywhere

72. anytime, anywhere
at your own
discretion

73. anytime, anywhere
at your own
discretion
without hindering your current project

74. Pair programming is not unilateral
knowledge transfer.
It’s mutual knowledge sharing.

75. Sunday Morning

77. 

78. Programming Sunday

79. get developers
together

80. get developers
together
discuss
problems

81. get developers
together
discuss
problems
implement
them

82. frequently?

83. some things

84. NOT VERY FREQUENT

85. ALSO FOCUSED ON
PRODUCTIVITY

86. Get together to
practice open source.

87. dojo
sessions

88. Self organized.

89. Not everything lasts forever.

90. MANY DROPOUTS

91. SOMETIMES CONSIDERED
BORING

92. KATA FORMAT

93. Learn many different things.

94. BROWN BAGS

97. A R
L
U S
P Y
O A
P D
T A
S
O W
M O
N

98. Present any topic in any form.

99. Present any topic in any form.
didactics

100. Present any topic in any form.
didactics
live refactoring

101. Present any topic in any form.
didactics
live refactoring
empirical software
engineering

102. Present any topic in any form.
didactics
live refactoring
retrospective
empirical software methods
engineering

103. Present any topic in any form.
lambda calculus
didactics
live refactoring
retrospective
empirical software methods
engineering

104. Present any topic in any form.
lambda calculus
didactics
live refactoring
py calculus
retrospective
empirical software methods
engineering

105. Present any topic in any form.
lambda calculus
didactics
live refactoring
py calculus
retrospective
empirical software methods
engineering javascript

106. Present any topic in any form.
flex lambda calculus
didactics
live refactoring
py calculus
retrospective
empirical software methods
engineering javascript

107. Present any topic in any form.
flex lambda calculus
didactics
live refactoring
py calculus scala
retrospective
empirical software methods
engineering javascript

108. Present any topic in any form.
flex lambda calculus
didactics intense scala
live refactoring
py calculus scala
retrospective
empirical software methods
engineering javascript

109. Present any topic in any form.
flex lambda calculus
didactics intense scala
live refactoring
py calculus scala
retrospective
empirical software methods
engineering javascript
testing methods

110. Present any topic in any form.
flex lambda calculus
didactics intense scala
code shows live refactoring
py calculus scala
retrospective
empirical software methods
engineering javascript
testing methods

111. VERY MOTIVATED
DURING LUNCH

112. EVERYONE PARTICIPATES

113. RETROSPECTIVE

114. Everyone has something to teach.

115. INTERNAL DISCUSSION LISTS

116. PEOPLE FROM
OUTSIDE CAN
PARTICIPATE

117. FRIENDS FROM
OUTSIDE CAN
PARTICIPATE

118. EVEN ACADEMIC PAPERS
ARE MENTIONED

119. DECREASED DUE TO OUR
POPULAR FORUMS
posts

120. Asynchronous discussions allow
research prior to response.

121. N T
M E
O P
E L
E V
S D
O S
F

122. if it is bad code,
we refactor it.

123. if it is good code...

124. if it is good code...
we read and learn!

125. Our first contact with TDD and XP
was through open source in 2005.

126. Sharing code means
sharing knowledge.

129. MANY APPEAR
IN INTERNAL DISCUSSIONS

130. OUR BLOG IS POPULAR
(last 6 months)

131. ENGLISH BLOG

132. ENGLISH BLOG
STILL NOT THAT MUCH

133. Blogging exposes ideas and makes
the blogger reflect upon his subject.

134. CONFERENCES

135. CONFERENCES
AGILE BRAZIL
QCON
SCALA DAYS
DEVOXX
WWW
AGILE
XP
JAVAONE

136. in 2010 we sponsored all
brazilian software dev events
(that we were given the opportunity).

137. TALK TO PEOPLE++

138. share knowledge with new people,
friends and old students

139. LIFE
AND
WORK

140. build relationships
during and after
work hours

141. INTERNAL
TRAINING

142. INTERNAL
ONLINE
TRAINING

143. INTERNAL
ONLINE
TRAINING

144. INTERNAL+EXTERNAL
ONLINE
TRAINING
(SIGN THE LIST TO TRY IT)

145. ALL THESE PRACTICES MAY
NOT WORK FOR YOU

146. BUT YOU SHOULD
GIVE THEM A GO

147. BUT YOU SHOULD
GIVE THEM A GO
positive emotions
☺☺☺

148. summing up

149. how to improve
learning in your
company?

150. Learning is the base for adaptation.

151. Teaching is not unilateral
knowledge transfer.
It’s mutual knowledge sharing.

152. Sharing code means
sharing knowledge.

153. Blogging exposes ideas and makes
the blogger reflect upon his subject.

154. Everyone has something to teach.

155. Leave the space open for people
to share knowledge.

156. build relationships
during and after
work hours

157. share knowledge with new people,
friends and old students

158. Asynchronous discussions allow
research prior to response.

159. Sharing code means
sharing knowledge.

160. Get together to
practice open source.

161. There are no fixed rules.

162. offline and online

163. pick your practices

164. THANK YOU!
www.caelum.com.br
www.caelumobjects.com
guilherme.silveira@caelum.com.br - @guilhermecaelum
mauricio.aniche@caelum.com.br - @mauricioaniche