Start Small, Stay SmallBuild great products by letting people to use their brains.

Any questions or ideas ? info@redgreenrefactor.eu

Dispel the myth

Great products require many people !

Dispel the myth

Big products require many people !

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.

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

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

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

It is like going from...

...to:

From To

100 5

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

Complexity

Predictive processes/frameworks

WaterfallPrince 2

Iterative Waterfall

Rational Unified Process

V-Model

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

Three pillars of Empirical Processes

•Transparency

•Inspection

•Adaptation

Or just

Frequent inspection and adaptation

From To

100 35

66%of delivered features are rarely or never used*.

*) Standish report.

From To

100 35

But to make it happen you need:

• Concurrent Engineering

• Collaborative Problem Solving

• Creativity

They all require Self-Organisation

from to

100 35

Self-Organisation will be a necessary condition to move

From To

35 5

If you do it right, you may get this as a bonus:

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.

Complex Adaptive Systems

Brain

Connections

Neurones

Local Interactions

Individuals

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

*) local interactions do not respect organisational boundaries.

Diversity and Valuesself-organisation top influencers

Individual’s View

Individual

Darkness PrincipleEach 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. RichardsonPicture taken from http://www.comicvine.com

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.

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

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.

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

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

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

creativity = unexpected

unexpectedconstructive

destructive

self-organisation and good teamgives

constructive creativity

self-organisation and bad teamgives

destructive creativity

Finally...

• Big team will most-likely be a bad team.

• Small team is not necessary a good team.

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?

What makes small team a good team?

• Stable core membership.

• Long-lasting – the connections need to be build.

• Small fluctuations may refresh the team.

People are not resources...

They cannot be plugged-in and out without decrease of productivity.

...and the teams are not factories.

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

The unit of scaling

You grow not by increasing the size of the team, but by adding another new team.

Start small

• Start with one great small team.

• Regardless of the perceived size of the product.

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.

Complexitythere is one more dimension hidden here

ComplexityPeople make simple complex

Stay small

• Grow organically.

• One team at a time.

• Postpone growing till it hurts.

• Re-hire if necessary.

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.

Great teams are Lean

The Two Pillars of Lean

• Continuous Improvement

• Respect for People (not Resources)

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.

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

Respect for people

'RQW�7URXEOH�<RXU�&XVWRPHU 4XDOLW\�

3UHGLFWDELOLW\�

'HYHORS�3HRSOH�DQG�7KHQ�%XLOG3URGXFWV

0DQDJHU�LV�D�OHDGHU��WHDFKHU��PHQWRU�

(QFRXUDJH�SHRSOH�WR�ILQG�URRW�FDXVHV�RIWKH�SUREOHP�UDWKHU�WKDQ�MXVW�ILQGLQJ�DTXLFN�IL[�

0DQDJHUV��:DON�WKH�7DON� �P\�PDQDJHU�FDQ�GR�P\�MRE�EHWWHU�WKHQ�PH�

7HDPV�DQG�,QGLYLGXDOV�(YROYH7KHLU�2ZQ�3UDFWLFHV�DQG,PSURYHPHQWV0DQDJHPHQW�FKDOOHQJHV�

7KH�WHDP�GHFLGHV�KRZ�WR�LPSURYH�

%XLOG�3DUWQHUV%XLOG�ORQJ�WHUP�UHODWLRQVKLS�EDVHG�RQ�WUXVW�

+HOS�\RXU�SDUWQHUV�WR�LPSURYH�

'HYHORS�7HDPV6PDOO��FROORFDWHG�WHDPV������SHRSOH��

7HDP�ZRUN��QRW�MXVW�VKDULQJ�WKH�VDPH�IORRU�

5HVSHFW�IRU�3HRSOH

Start Small, Stay SmallBuild great products by letting people to use their brains.

Any questions or ideas ? info@redgreenrefactor.eu

?

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/