Post on 13-Jan-2015
description
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/