• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Start small, stay small!
 

Start small, stay small!

on

  • 393 views

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

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.

Statistics

Views

Total Views
393
Views on SlideShare
349
Embed Views
44

Actions

Likes
2
Downloads
1
Comments
0

1 Embed 44

http://localhost 44

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Start small, stay small! Start small, stay small! Presentation Transcript

    • Start Small, Stay Small Build 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 Waterfall Prince 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 Values self-organisation top influencers
    • Individual’s View Individual
    • 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
    • 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
    • unexpected constructive destructive
    • self-organisation and good team gives constructive creativity
    • self-organisation and bad team gives 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.
    • Complexity there is one more dimension hidden here
    • Complexity People 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
    • Start Small, Stay Small Build 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/