3. Customer

4. Project Design Process

5. Teams

6. Summary

11. being naive, naive way

12. the czech way

13. not being able to say "No"

14. do not separate projects from company itself

15. not enough projects

17. select right customers

18. clear statement who's your customer

19. Michal Berg (eSports.cz)

20. learn to say "No" to customers, 80/20

21. project control ( you vs customer )

22. manipulation from customer

23. check your customer credit

25. Good products CANNOT fix bad strategy

26. Strategy determines:

27. market segment we'll compete IN

28. compete WITH

29. HOW we'll compete

31. internal economics

32. distribution channels

33. competition channels

34. do good job at setting the strategy

35. deeply understand the customer

36. customer reviews

38. Project Control Triangle

39. Schedule (Time)

40. Resources

43. Reality scenarios:

44. Fix Resources, Fix Time, Variable Scope

45. Fix Resources, Fix Scope, Variable Time

46. The best thing you can do is to fix your team which is part of the resources

47. Always try to add non-human resource if possible ( computation to speedup devel. )

49. Structure is the key to freedom

50. "The key is to standardize the lower levels of process architecture."

51. 2 ways of doing this standardization:

52. Modular structure

54. External interfaces

55. Object Oriented Programming

58. Information generation

59. Decentralized Control & Feedback

60. Queues

61. Automate

62. Development ( TDD, CIA, Paperless )

63. Business ( eMyth - Michael E. Gerber )

64. Other patterns

66. Discovery phase ( Inspired - Marty Cagan )

69. Information theory

72. Decentrealized control is better for quickly changing markets

73. Introduce Decision rules to allow lower parts of hierarchy to make decisions faster

74. Most dev teams use rule: "Do not ask for permission ask for forgiveness."

76. Good for leaders with high skills presured by time

77. Closed Feedback loop

78. Group Feedback

79. Change dynamics by adding/removing member

80. Personal Feedback

82. Observe time of item in the queue

83. For better queue fighting is to have multi-functional members of the team

84. Teach programmers to do a bit of desing and designer a bit of coding

86. ( eMyth - Michael E. Gerber )

87. Dev Automation

88. Testing ( CIA )

89. Servers ( Clouds )

90. Backups

92. Scrum

93. Kanban or Scrumban

94. Toyota System

95. Lean Startup

97. Team Structure

98. Collaboration

99. Motivation vs Inspiration

101. Teach them to teach other

102. Pair Programming/Work

103. People for People

104. We write code for people not computers.

105. Hire the best people you can

106. 3 types of people

107. Make excuses (Lazy)

108. Do whatever it takes (Kamikaze)

110. Size 7 +- 2 ( Complexity of Communication )

111. Women in the team

112. Architect = Consistency

113. Product Owner/Manager

114. "Project without PO is like Movie without director."

116. High respect for each other's competence on the topic of the collaboration

117. Have skills and permission to creatively bargain with each other over costs and benefits

118. Reality over Virtuality ( Whiteboard )

120. Story of Teacher and grades

121. Game Mechanics

122. Forsquare, Geolocation

123. Work vs Game play

124. 3D world simulation

126. Story of Pensioner and Kids

127. Specialized skills + Facilitation skills (pay attention to work) = Success

129. Quite place, Food, Maslow's hierarchy

130. Momentum

131. Default mode of our behaviour

132. Solving problem for need of solving problems

133. STOP

134. Step back

135. Think and decide

136. Organize

138. Begin with P.C. Triangle

139. Deliberately Desing your Design process

140. Modules, Patterns

141. Generate Info early

142. Work on your Feedback loops

143. Observe Queues

144. Automate