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.
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
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.
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.
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
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.
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.
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.
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.
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/