Cockburn:%20Agile%20Software%20Development

1
Cockburn Agile Software Development

• T-76.650
• 28.1.2002
• Jari Vanhanen

2
Goal of the book

• to undestand that it is impossible to name one
  best and correct way to develop software
• to lead to constructive ideas to deal with the
  above situation
• to build a vocabulary for software development
  that helps noticing things and talking about them

3
Software and games

• Considering software development as a game is a
  better metaphor than engineering or model
  building
• Software development is a group game, which is
• goal seeking
• finite
• cooperative
• Game of innovation and communication
• contains peoples ideas and communicating the
  ideas to colleagues and computer

4
Software and games

• Programmers and communication
• a stereotype of a programmer is noncommunicative
• programming has been work of individuals
• agile methodologies emphasize communication
• programmers like communicating about techical
  things
• surprisingly high acceptance of pair programming
• Gaming faster
• programming is limited by the ability to think
  through the problem and the solution
• like writing novels or writing laws
• Other games
• personal careers
• growth of the company
• may be in conflict with the project-game

5
Intermediate work products

• Shared experices to refer to
• reminds of an earlier thought or decision
• Support structures for new ideas
• incite new thoughts
• For the primary goal (delivering software) they
  have value only as they help the team move on
• measured for sufficiency, not for completeness or
  perfection
• reaching perfect communication is an impossible
  goal
• Preparing for the next game
• transfer enough knowledge to the next team
• when to produce?
• constantly (lot of rework)
• at the end (will they be created?)

6
Individuals

• Purely people factors predict project
  trajectories quite well, overriding choice of
  process or technology
• a well-functioning team of adequate people
  succeed almost regardless of the process or
  technology they are required to use
• Hard to design a system composed of humans
• humans are contradictory, depending on work,
  time, other people, etc.
• people differ in their ways to solve problems
• Diversity presents communication difficulty and
  personal friction but also allows for efficiency
• mixed teams often outperform homogeneous teams

7
Human failure modes

• People make mistakes
• reason for iterative (rework) and incremental
  (develop pieces) development
• Preferring to fail conservatively rather than to
  risk succeeding differently
• risk-averse if you might lose something you have
• risk-accepting if you are losing something and
  might regain it
• inventing rather than researching
• educational background
• being incosistent creatures of habit
• resist learning new habits, but tend towards
  inconsistency

8
How methodologies deal with human weaknesses

• Discipline
• create mechanisms that hold strict behavioral
  standards in place
• high-discipline methodologies are fragile
• Cleanroom
• PSP
• XP
• strict adherence to ineffective practices leads
  to ineffective team

• Tolerance
• design the methodology to be tolerant of
  individual variations
• team members form consensus of the minimum
  compliance needed
• works if people care about citizenship issues and
  generally take pride in their work
• tolerant methodologies
• ASD
• Crystal family

9
Working better in some ways than others

• Concrete
• Tangible
• paper prototypes
• CRC cards
• Something to alter
• examples or work products
• Watching and listening
• arrange the room setup for learning
• Supporting concentration AND communication
• flow

• Personality-matched work assignments
• Talent
• skills can be improved, but talent can not
• Rewards that preserve joy
• rewards reduce the intrinsic joy and quality of
  otherwise fun activity
• pride-in-work
• pride-in-accomplishment
• order of tasks in project
• pride-in-contribution
• Clear and frequent feedback

10
Communication

• Discovering that someone knows something useful
• Transferring the knowledge
• Delays and lost-opportunity costs
• proximity
• knowing that someone is present
• seeing what others are doing
• Osmotic communication
• useful background sounds and drafts
• Information radiators
• information must change
• easy to view the display

11
Modalities in communication

• physical proximity
• three-dimensionality
• smell
• kinesthetics
• touch
• sound
• visuals
• cross-modality timing
• low latency
• trust and learning
• use of a shared, persistent information radiator

• remove almost everything and the result is a
  paper
• you arent close to the writer
• you cant see the writer
• you cant hear the writer
• you can ask question from the writer
• ...
• videotaped documentation

12
Elements of a methodology
reviews publications declarations
13
Scope of a methodology

• Often two seemingly incompatible methodologies
  target different parts of the lifecycle or
  different roles
• XP vs. GUI design

14
Conceptual terms

• Methodology
• size
• number of control elements
• ceremony
• precision and tolerance in the methodology
• weight
• sizeceremony
• visibility
• how easily outsiders see if the methodology is
  followed
• Problem size
• number of elements and their cross-complexity
• Project size
• number of people

• System criticality
• damage from undetected defects
• Work products
• Precision
• How much to say about a topic?
• Accuracy
• How correct you are?
• Relevance
• Whether or not to speak about a topic?
• Tolerance
• How much variation is permitted?
• Scale
• rolling items together
• Stability
• How likely is it to change?

15
Publishing a methodology

• Pictorial view
• e.g. Role-Deliverable-Milestone view
• birth, review, death
• most people only want to see the part that
  affects them
• misses practices, standards, and other forms of
  collaboration

16
Publishing a methodology

• Textual view
• describes techniques, activities, meetings, ...
• large
• e.g. XP 200-gt1000 pages
• documentation vs. understanding
• real methodology is tacit knowledge
• understanding does not presuppose having
  documentation
• impractical to keep up-to-date with the needs of
  the teams
• methodology needs to change constantly
• practices needed to transfer good habits to other
  teams

• Reducing size of the text
• provide examples of work products
• replace technique guides with pointers to books
  and courses
• organize the text by role
• use process miniature
• play-act a release of a project in a very short
  period of time
• replay from time to time

17
Methodology design principles

• Common errors
• One size for all projects
• corporations common methodology ...
• Intolerant
• a methodology is a straight-jacket
• should not be any tighter than absolutely needed
• e.g. many techniques work quite well and
  different ones suit different people at different
  times

• Heavy
• heavier is safer for managers?
• when to trust people
• what constraints add more burden than safety
• Embellished
• unnecessary rules, practices, and ideas
• have directly affected people review the proposal
• Untried
• Used once
• generalization?

18
Principles for designing methodologies

• Interactive, face-to-face communication is the
  cheapest and fastest channel for exchanging
  information.
• prefer using warmer communication channels in
  software evelopment
• e.g. videotaped design documentation
• more difficult as the project size increases
• emphasize small groups and personal contact if
  productivity and cost are key issues

19
Principles for designing methodologies

• Excess methodology weight is costly.
• intermediate work products might add unnecessary
  costs to a small team
• a small team can succeed with a larger problem by
  using a lighter methodology
• of course you cant remove everything
• a team operating from peoples strenghts -
  communication and citizenship - can do with a lot
  less methodology than most managers expect

20
Principles for designing methodologies

• Larger teams need heavier methodologies.

Small team
Large team
21
Principles for designing methodologies

• Greater ceremony is appropriate for projects with
  greater criticality.
• cost of leaving a fault in a system
• criticality categories in Crystal family
• loss of comfort
• loss of discretionary monies
• loss of essential monies
• loss of life

22
Principles for designing methodologies

• Increasing feedback and communication reduces the
  need for intermediate deliverables.
• an intermediate deliverable is one that is passed
  across decision boundaries within the team
• deliver a working piece of the system quickly
• feedback
• reduce the team size and put people close
  together
• facilitate face-to-face communication

23
Principles for designing methodologies

• Discipline, skills, and understanding counter
  process, formality, and documentation
• discipline involves a person choosing to work in
  a way that requires consistency
• process involves a person following instructions
• discipline is more powerful
• knowledge that becomes documentation is only a
  small part of what there is to know
• transfer the heads that hold the information
• no degree of formality replaces skill
• exploratory vs. optimizing projects
• finding vs. pumping oil wells

24
Principles for designing methodologies

• Efficiency is expendable in nonbottleneck
  activities.
• minimize rework in bottleneck activity
• you can add inefficiency to preceeding activities
  in order to get their outputs more complete and
  stable

25
Consequences of the principles

• Adding people to a project is costly
• Team size increases in large jumps
• Teams should be improved, not enlarged
• Different methodologies for different projects
• number of people, system criticality, project
  priorities
• Lighter methodologies are better until they run
  out of steam
• Methodologies should be stretched to fit

26
Why methodology at all

• Introducing new people to the process
• Delineating responsibilities
• Impressing the sponsors
• Demonstrating visible process
• Curriculum for education

27
Light but sufficient

• Primary goal is to deliver software
• Secondary goal is to set up for the second game
• How to allocate resources to each goal?
• How much of the knowledge to document?

• Recommendations for documentation
• just enough required to communicate with the
  readers
• replace typing with faster communications media
• visits in person
• video clips
• remember, there will be new persons requiring
  more documentation
• run documentation as a parallel, resource
  competing thread of the project

28
Sweet spots of software development

• 2-8 people in one room
• information moves fastest
• Onsite usage expert
• minimized feedback time of the solution
• One-month increments
• feedback of the product and the process
• Fully automated regression tests
• confidence to changing and improving the system

29
Agile software development manifesto

• Signed by authors of ASD, XP, Scrum, Crystal,
  FDD, DSDM, and pragmatic programming
• Agree at the first level
• need to respond to change
• Agree at the second level
• individuals and interactions over processes and
  tools
• working software over comprehensive documentation
• customer collaboration over contract negotiation
• responding to change over following a plan
• Agree at the third level
• 12 more detailed statements
• Dont agree at the fourth level
• detailed project tactics

30
References

• Cockburn. Agile Software Development. Addison
  Wesley 2001.
• Glass. Agile versus Traditional. In Cutter
  ITJournal December 2001.
• http//www.cutter.com/itjournal/itj0112.pdf
• Boehm. Get Ready for Agile Methods, with Care.
  IEEE Computer January 2002.
• http//ieeexplore.ieee.org