Great products require many people? Dispel the myth! Start small, and stay small! Self-organisation flourishes in great small teams of passionate, dedicated developers. This presentation is a follow up of our presentation on Self-Organisation. Here we would like to demonstrate, that creative self-organisation is easier to achieve in small teams. We also advocate that it is best to start with one team only, regardless of perceived size of the product.

1. Start Small, Stay Small
Build great products by letting people to use their brains.
Any questions or ideas ?
info@redgreenrefactor.eu

2. Dispel the myth
Great products require many people !

3. Dispel the myth
Big products require many people !

4. SAGE - 1950s
• Semi-Automatic Ground Environment.
• Network of computer systems providing the
ground environment for the larger air defense
system with buildings, radars, and defense
aircraft.
• The earliest large-scale software intensive
product development.
• Hundreds of people.
• Way over budget and partly outdated when
finally delivered.

5. SAGE - 1950s
...find the ten best people and write the entire
thing themselves.
One of the directors of SAGE discussing
why programming had gotten out of
hands(*).
(*)Practices for Scaling Lean and Agile Development: Large, Multisite, and Offshore Product
Development with Large-Scale Scrum (Agile Software Development Series) [Paperback]
Craig Larman, Bas Vodde

6. FBI Sentinel: 2006–2012(*)
• Replace digital and paper processes with
purely digital workflows during investigations.
• Planned for four phases initially and estimated
for budget of $451M (March 2006, December
2009).
• By August 2010, FBI spent $405M delivering
only first two phases.
• 400 people.
• $35M and six more years needed if continued
with the traditional approach.
(*) Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, And Leave
Competitors In the Dust [Paperback]
Ken Schwaber and Jeff Sutherland

7. FBI Sentinel: 2006–2012(*)
• Entire Sentinel project moved to the basement of
the FBI building in Washington, DC.
• Sentinel staff reduced from 400 to 45 people, where
only 15 were programmers.
• Project completed within 12 months with cost
savings of more than 90% ($30M)
(*) Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, And Leave
Competitors In the Dust [Paperback]
Ken Schwaber and Jeff Sutherland

8. It is like going from...

9. ...to:

10. From To
100 5

11. In what follows we take investigate what have to
happen to get a great small team...

12. Complexity

14. Predictive processes/frameworks
Waterfall
Prince 2
Iterative Waterfall
Rational Unified Process
V-Model

15. Empirical Processes – Agile Umbrella
Lean
Scrum ◀
eXtreme Programming ◀
Kanban ◀
▷ Daily Scrum
▷ Sprint Planning
▷ Sprint Retrospective
▷ Test Driven Development
▷ Continuous Integration
▷ Pair Programming
▷ Limiting Work in Progress
▷ ...
Lean Tools Practices
Agile

16. Three pillars of Empirical Processes
•Transparency
•Inspection
•Adaptation

17. Or just
Frequent inspection and adaptation

18. From To
100 35

19. 66%of delivered features are rarely or never used*.
*) Standish report.

20. From To
100 35

21. But to make it happen you need:
• Concurrent Engineering
• Collaborative Problem Solving
• Creativity
They all require Self-Organisation

22. from to
100 35
Self-Organisation
will be a necessary
condition to move

23. From To
35 5
If you do it right,
you may get this
as a bonus:

24. Self–Organisation
= Local interactions
between people
Notice that self-organisation is not only
a “human” thing. Animals and even
plants also self-organise. Here we
focus on self-organisation of humans.

25. Complex Adaptive Systems

26. Brain

27. Connections
Neurones

28. Local Interactions
Individuals
*this is weak analogy - there are
no boundaries, there is no
system, but there are individuals
and there are interactions.

29. *) local interactions
do not respect
organisational
boundaries.

30. Diversity and Values
self-organisation top influencers

31. Individual’s View
Individual

32. Darkness Principle
Each element in the system is ignorant of the
behaviour of the system as a whole [...] If each
element ‘knew’ what was happening to the system
as a whole, all of the complexity would have to be
present in that element.
K.A. Richardson
Picture taken from http://www.comicvine.com

33. too high level of diversity will not
stop interactions, but may reduce
their usefulness in achieving our
goals. When the differences are
radical, collaboration may be
impeded.

34. when the views overlap, i.e. when
there is enough of common
ground in values, the local
interactions will be reinforced to a
level that - when combined with
diversity - may boost creativity

35. This set-theoretic representation gives
us slightly different view. It shows that
there is a fundamental common ground
for collaboration (green), but enough
diversity (other white circles) to
preserve healthy disagreement.

36. Diverse, but well-founded team
has better perception of the
reality then any individual
member.

37. Making someone managing such
a team will most-likely obscure its
bright view.

38. Novelty requires diversity.
Diversity will only bring
unexpected when differences
are respected and conflicts are
allowed.
If people follow simple rules
nothing novel and creative will
emerge from their self-
organisation.
Ralph Stacey

39. creativity = unexpected

40. unexpected
constructive
destructive

41. self-organisation and good team
gives
constructive creativity

42. self-organisation and bad team
gives
destructive creativity

43. Finally...
• Big team will most-likely be a bad team.
• Small team is not necessary a good team.

44. too high level of diversity will not
stop interactions, but may reduce
their usefulness in achieving our
goals. When the differences are
radical, collaboration may be
impeded.
Why big teams are usually bad?

45. What makes small team a good
team?
• Stable core membership.
• Long-lasting – the connections need to be build.
• Small fluctuations may refresh the team.

46. People are not resources...
They cannot be
plugged-in and out
without decrease of
productivity.

47. ...and the teams are not factories.

48. A good team is...
a carefully selected team.
Build ‘big’ systems by building a small group of great
people that can work in teams, and co-locate them in
one place. Only grow when it really hurts, taking time
to hire extraordinary new talent*.
(*)Practices for Scaling Lean and Agile Development: Large, Multisite, and Offshore Product
Development with Large-Scale Scrum (Agile Software Development Series) [Paperback]
Craig Larman, Bas Vodde

49. The unit of scaling
You grow not by increasing the size of the
team, but by adding another new team.

50. Start small
• Start with one great small team.
• Regardless of the perceived size of the product.

51. One team only
• Easier to create artifacts (like initial architecture).
• Easier to make right decisions in a short time.
• Easier to brainstorm, run meetings, easier to
communicate.
• Simply, the complexity drops by order(s) of
magnitude if you start with just one team at the
beginning.

52. Complexity
there is one more dimension hidden here

53. Complexity
People make simple complex

54. Stay small
• Grow organically.
• One team at a time.
• Postpone growing till it hurts.
• Re-hire if necessary.

55. Hiring is crucial
• HRs - in the context of complex systems, they are not able to hire
right people - face it.
• Engage the team - they will have to work with the guy.
• Forget brain-teasers.
• GPAs don’t predict anything about who is going to be a
successful employee.
• Ask for portfolio.
• Real-work assignment as a part of hiring procedure.

56. Great teams are Lean

57. The Two Pillars of Lean
• Continuous Improvement
• Respect for People (not Resources)

58. Continuous Improvement
• Go See (for yourself).
• Kaizen - choose techniques or practices as the
team, practice to understand, experiment to find a
better way, repeat.
• Challenge everything.
• Improve the flow.

59. An environment supporting continuous learning and
embracing change, cannot exist without true respect
for people.

60. Respect for people

61. Start Small, Stay Small
Build great products by letting people to use their brains.
Any questions or ideas ?
info@redgreenrefactor.eu

62. ?

63. This presentation was inspired by the works of many people, and I cannot possibly list them all. Though I did my very best to
attribute all authors of texts and images, and to recognize any copyrights, if you think that anything in this presentation should be
changed, added or removed, please contact me at marcin.czenko@redgreenrefactor.eu.
http://creativecommons.org/licenses/by-sa/3.0/