Agile 2006

1
Agile 2006
2
?? ?? ??? ????

• Introductory Lectures
• Tracks
• Hands-on
• Discovery Sessions
• Tutorials
• Research Papers
• Experience Reports
• Educators Symposium
• Evening events

3
Scrum

• Scrum is an agile process to manage and control
  development work
• Scrum is a wrapper for existing engineering
  practices
• Scrum is scalable from single projects to entire
  organizations (with over a thousand developers
  and implementers)

4
Scrum

• An iterative, incremental process for developing
  any product or managing any work (yep, just like
  XP)

5
What Is Agile Software Development?

• 2001 Manifesto for Agile Software Development
• Individuals and interactions over processes and
  tools
• Working software over comprehensive documentation
  
• Customer collaboration over contract negotiation
• Responding to change over following a plan
• Principles
• Satisfy the customer through early and continuous
  delivery of valuable software
• Welcome changing requirements
• And much more (http//www.agilemanifesto.org/)

Kent Beck Mike Beedle Arie van Bennekum Alistair
Cockburn Ward Cunningham Dave Thomas
Jon Kern Brian Marick Robert C. Martin Steve
Mellor Ken Schwaber Jeff Sutherland

• Martin Fowler
• James Grenning
• Jim Highsmith
• Andrew Hunt
• Ron Jeffries

6
Research Papershttp//agile2006.com/program/Progr
am

1. AgileEVM Earned Value Management in Scrum
   Projects
2. Earned Value and Agile Reporting
3. An Empirical Study of Using Planning Poker for
   User Story Estimation
4. Executable Acceptance Tests for Communicating
   Business Requirements Customer Perspective
5. On Agile Performance Requirements Specification
   and Testing
6. Refactoring with Contracts
7. The Role of Story Cards and the Wall in XP teams
   a distributed cognition perspective
8. A Case Study on the Impact of Customer
   Communication on Defects in Agile Software
   Development
9. Reflections on Reflection in Agile Software
   Development
10. Critical Personality Traits in Successful Pair
    Programming
11. What Lessons Can the Agile Community Learn from a
    Maverick Fighter Pilot?

7
Research Papershttp//agile2006.com/program/Progr
am

1. AgileEVM Earned Value Management in Scrum
   Projects
2. Earned Value and Agile Reporting
3. An Empirical Study of Using Planning Poker for
   User Story Estimation
4. Executable Acceptance Tests for Communicating
   Business Requirements Customer Perspective
5. On Agile Performance Requirements Specification
   and Testing
6. Refactoring with Contracts
7. The Role of Story Cards and the Wall in XP teams
   a distributed cognition perspective
8. A Case Study on the Impact of Customer
   Communication on Defects in Agile Software
   Development
9. Reflections on Reflection in Agile Software
   Development
10. Critical Personality Traits in Successful Pair
    Programming
11. What Lessons Can the Agile Community Learn from a
    Maverick Fighter Pilot?

8
RP Reflections on Reflection in Agile Software
Development
9
Reflections on Reflection in Agile Software
Development

• This paper analyzes the reflections of an agile
  team, developing a large-scale project in an
  industry setting
• The team uses an Iteration Summary Meeting
  practice, which includes four elements
• The customers summary
• Formal presentation of the system
• Review of metrics
• Reflection
• The proposed practice supports tracking past
  decisions
• It also incurs a lower overhead than existing
  alternative reflection practices (only 2.1 of
  the team's time, in contrast to 3.7 or 4.7 in
  other cases)

10
Reflections

• Reflection is the process according to which an
  individual (or a group) examines his/her/its
  actions during the accomplishment of the action
  or after it
• Reflective mode of thinking may improve the
  application of some of the XP practices
• When a pair is engaged in a pair programming
  session, the navigator reflects on the drivers
  coding

11
Research Settings

• The project is a business-critical enterprise
  information system, considered to be highly
  complex and intended for a large and varied user
  population.
• The agile software development method used in the
  project is based on Extreme Programming 2, with
  a few adaptations in line with the agile approach
  that were dictated by the project's size and the
  organization

• Regular reflection meetings and formal 2 weeks
  iteration summary meetings were conducted.
• Development team averaged 15 developers during
  this period

12
Research Method

• The main research method used in this paper is
  personal reflection of team members on the
  reflection
• Discuss a specific problem in the process
• Analyze, via written questionnaires, several
  months after the reflections in question took
  place

13
Agile Reflection Technique

• Only one specific problem is discussed at each
  reflection meeting
• The discussed problem should relate to the
  development process, not the developed product
• The subject is chosen in advance by the moderator
• The reflection cannot exceed one hour
• The whole team is required to attend the
  reflection
• The reflection may be an open discussion, or use
  some structured problem solving technique

• Team members are encouraged to speak their own
  opinions
• The moderator records important insights and
  proposed action items that surface during the
  meeting
• The moderator summarizes the meeting
• The decided action items are effective
  immediately
• The moderator publishes the main insights and
  action items to the teams soon after the
  reflection

14
Results
15
Reflections on the techniqueof the reflection
meeting
16
xUnit Test Patterns

• Improving Test Code and Testability Through
  Refactoring
• Expect to have just as much test code as
  production code!
• The Challenge How To Prevent Doubling Cost of
  Software Maintenance?

17
A Recipe for Success

• Write some (easy) tests
• Note the Test Smells that show up
• Code Smells Visible Problems in Test Code
• Behavior Smells Tests Behaving Badly
• Project Smells Testing-related problems visible
  to a Project Manager
• Refactor to remove obvious Test Smells
• Apply appropriate xUnit Test Patterns
• Write some more (complex) tests
• Repeat from Step 2 until
• All necessary tests written
• No smells remain

18
Common Code Smells

• Conditional Test Logic
• Tests containing conditional logic (IF statements
  or loops)
• Hard to verify correctness. Does it always test
  the same thing?
• A cause of Buggy Tests (Project Smell)
• Hard to Test Code
• Obscure Test
• Test Code Duplication
• Test Logic in Production

19
Patterns

• Expected Objects
• Use AssertEquals on whole objects rather than
  comparing individual fields
• Guard Assertions
• Remove conditional logic associated with avoiding
  assertions when they would fail
• Custom Asserts
• Remove Test Duplication by factoring out common
  code
• Remove conditional logic associated with complex
  verification logic
• Test Doubles
• Test Stubs return test-specific values
• Mock Objects also verify method calls and
  arguments
• Fake Objects provide same services in a lighter
  way
• Teardown
• Transaction Rollback

20
Common Behavior Smells

• Slow Tests
• Erratic Tests
• Interacting TestsWhen one test fails, a bunch
  of other tests fail for no apparent reason
  because they depend on other tests side effects
• Unrepeatable Tests Tests cant be run
  repeatedly without intervention
• Fragile Tests
• The 4 sensitivities
• Assertion Roulette
• Frequent Debugging
• Manual Intervention

21
Patterns

• Shared Fixture
• Fresh Fixture
• Standard Fixture
• Minimal Fixture
• Lazy Setup
• Setup Decorator
• SuiteFixture Setup

22
Common Project Smells

• Developers Not Writing Tests
• Symptoms No tests can be found when you ask to
  see
• Unit tests for a task
• Customer tests for a User Story
• Buggy Tests
• Production Bugs
• Symptoms Bugs are being found in production
• High Test Maintenance Cost

23
Refactoring Databases

• A database refactoring is a simple change to a
  database schema that improves its design while
  retaining both its behavioral and informational
  semantics

• A database schema includes both structural
  aspects such as table and view definitions as
  well as functional aspects such as stored
  procedures and triggers
• Important Database refactorings are a subset of
  schema transformations, but they do not add
  functionality

24
Rename Column
25
The Process
26
Other Database Refactorings

• Migrate Method From Database
• Migrate Method to Database
• Move Column
• Move Data
• Parameterize Method
• Rename Table
• Replace Column
• Replace One-To-Many With Associative Table
• Split Table
• Substitute Algorithm
• Use Official Data Source

• Merge Columns
• Add CRUD Methods
• Add Mirror Table
• Apply Standard Codes
• Consolidate Key Strategy
• Drop Column Constraint
• Drop View
• Introduce Calculated Column
• Introduce Common Format
• Introduce Read-Only Table
• Introduce Variable

Database Refactoring Plug-In www.eclipse.org/epf
27
Philosophies of Agile Data Method

• Data is one of several important aspects of
  software-based systems
• Enterprise issues should considered and acted
  upon by the development teams
• Enterprise Groups exist to nurture enterprise
  assets and to support other groups, such as
  development teams, within organization. These
  enterprise groups should act in an agile manner
• Unique situation for every project. One software
  process does not fit all and therefore the
  relative importance of data varies based on the
  nature of the problem being addressed.
• Work together
• Sweet spot. You should actively strive to find
  the path that works best for your overall
  situation.

28
Exploratory Testing

• Exploratory testing is simultaneouslearning,
  test design, and test execution
• Learning Focus
• Testing a new product
• Improving your model of product by investigating
  its elements
• Using and operating a product, and searching for
  bugs while also searching for new testing ideas
• Scanning or mapping a delivered artifact
  with focus on potential exploitation, unexpected
  interaction, or emergent behavior)
• Interacting with a product to test your model of
  it

29
Contrasting Approaches

• Scripted Testing
• Is directed from elsewhere
• Is determined in advance
• Is about confirmation
• Is about controlled tests
• Emphasizes predictability
• Emphasizes decidability
• Like making a speech
• Like playing from a score

• Exploratory Testing
• Is directed from within
• Is determined in the moment
• Is about investigation
• Is about improving test design
• Emphasizes adaptability
• Emphasizes learning
• Like having a conversation
• Like playing in a jam session

30
Coaching

• Coach a team advocate, a person who helps a
  team produce a desired effect
• Coaches aid change and provoke change
• Coaching has ethical responsibilities
• All coaching relies on some model of human
  behavior

• The job of a coach is to find teachable moments,
  and help team members release the tension
  productively

31
Research Papershttp//agile2006.com/program/Progr
am

1. AgileEVM Earned Value Management in Scrum
   Projects
2. Earned Value and Agile Reporting
3. An Empirical Study of Using Planning Poker for
   User Story Estimation
4. Executable Acceptance Tests for Communicating
   Business Requirements Customer Perspective
5. On Agile Performance Requirements Specification
   and Testing
6. Refactoring with Contracts
7. The Role of Story Cards and the Wall in XP teams
   a distributed cognition perspective
8. A Case Study on the Impact of Customer
   Communication on Defects in Agile Software
   Development
9. Reflections on Reflection in Agile Software
   Development
10. Critical Personality Traits in Successful Pair
    Programming
11. What Lessons Can the Agile Community Learn from a
    Maverick Fighter Pilot?

32
Coaching Techniques

• Conflict Identification
• Go Sideways
• Go Home
• Antennae Up
• Pair Coaching
• Ask the Room
• Make It Physical
• Active Listening
• Advance/Retreat
• Personal Encouragement / Discouragement

• Name It
• The Flounce
• Team Surgery
• Push in the Water
• Self-disintermediation
• Cheerleading
• Cultivate Respect

33
What does it really mean for a software
development organization to be agile?

• It may say agile on the box, but it doesnt feel
  agile
• Not every agile project is agile
• Not every plan driven project is not agile
• US Air Force Colonel John Boyd
• To win in a competitive environment we must
  operate at a faster tempo or rhythm than our
  adversaries
• He defined agility as the ability to operate the
  Observation-Orientation-Decision-Action (OODA)
  loop faster than an adversary

34
Observe
Decide
Act
Orient
Agility Execute your OODA loop more quickly
than your adversary
35
Agility is a Cultural Phenomenon

• Blitzkriegs principles
• Trust people feel safe taking the initiative
  rather than worrying how to justify their actions
• Skill and experience enable people to clearly
  observe their environment and develop creative
  solutions
• Intent opens the opportunity for people to take
  the initiative
• Vision gives people direction, in those
  situations where no firm guidance has been given
• People, ideas, technologyin that order!
• Agility depends on the tempo at which we can
  exploit the OODA loop, and it is culture, not
  methodologies or tools that determine our OODA
  loop speed
• Agilitys cultural dependency explains why a
  project using an agile methodology may not feel
  agile, and why a so called plan driven project
  may feel agile

36
Does a theory of competition apply to software
development?

• Yes!
• Uncertainty can have the same disorienting effect
  on a team as an explicit adversary
• The OODA loop is about getting into a position of
  advantage in an uncertain environment
• The OODA model is about groups of people working
  harmoniously together to accomplish a common
  purpose - even though everything is collapsing
  around them
• Our organizations objective is to survive on its
  own terms
• Software development is commerce and commerce is
  about competition

37
Implications of the OODA loop for the Agile
community

1. Agility is a time based strategy for operational
   success and is not based on size
2. Agility is a relative concept, not an absolute
   concept
3. Agility is an essential attribute for project
   success, large or small
4. Agility depends on organizational culture (unity,
   trust, intent, focus)
5. We are late to the party

38
Research Opportunities

• Good team culture quickens the decision cycle.
  The principles of the Blitzkrieg mutual trust,
  skill, intent, and vision describe the
  necessary talents for an agile organization
• Unfortunately, these are generally not talents
  that emerge spontaneously in an organization
• Cockpit Resource Management
• Could we design a similar program for software
  developers? (Developer Resource Management
  Program, perhaps)
• Implications for software engineering education?

39

• The End