Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

Start small, stay small!

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.

5.
SAGE - 1950s
...ﬁnd 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 workﬂows 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 ﬁrst 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.
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.

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

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

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

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

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

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

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

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

43.
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?

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

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

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

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

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

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

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

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

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