Agile 2006
?‫אז מה היה לנו‬


Introductory Lectures
Tracks:







Hands-on
Discovery Sessions
Tutorials
Research Papers
Experience Reports
Educators Symposium
Evening events
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)
Scrum

An iterative, incremental process for developing any
product or managing any work (yep, just like XP)
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
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Research Papers
http://agile2006.com/program/Program
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
AgileEVM – Earned Value Management in Scrum Projects
Earned Value and Agile Reporting
An Empirical Study of Using Planning Poker for User Story
Estimation
Executable Acceptance Tests for Communicating Business
Requirements: Customer Perspective
On Agile Performance Requirements Specification and Testing
Refactoring with Contracts
The Role of Story Cards and the Wall in XP teams: a
distributed cognition perspective
A Case Study on the Impact of Customer Communication on
Defects in Agile Software Development
Reflections on Reflection in Agile Software Development
Critical Personality Traits in Successful Pair Programming
What Lessons Can the Agile Community Learn from a
Maverick Fighter Pilot?
Research Papers
http://agile2006.com/program/Program
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
AgileEVM – Earned Value Management in Scrum Projects
Earned Value and Agile Reporting
An Empirical Study of Using Planning Poker for User Story
Estimation
Executable Acceptance Tests for Communicating Business
Requirements: Customer Perspective
On Agile Performance Requirements Specification and Testing
Refactoring with Contracts
The Role of Story Cards and the Wall in XP teams: a
distributed cognition perspective
A Case Study on the Impact of Customer Communication on
Defects in Agile Software Development
Reflections on Reflection in Agile Software Development
Critical Personality Traits in Successful Pair Programming
What Lessons Can the Agile Community Learn from a
Maverick Fighter Pilot?
RP: Reflections on Reflection in Agile
Software Development
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 customer’s 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)
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
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
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
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
Results
Reflections on the technique
of the reflection meeting
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?
A Recipe for Success


Write some (easy) tests
Note the Test Smells that show up




Refactor to remove obvious Test Smells



Code Smells – Visible Problems in Test Code
Behavior Smells – Tests Behaving Badly
Project Smells – Testing-related problems visible to a
Project Manager
Apply appropriate xUnit Test Patterns
Write some more (complex) tests
Repeat from Step 2 until:


All necessary tests written
No smells remain
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
Patterns

Expected Objects


Guard Assertions



Remove Test Duplication by factoring out common code
Remove conditional logic associated with complex verification logic
Test Doubles




Remove conditional logic associated with avoiding assertions
when they would fail
Custom Asserts


Use AssertEquals on whole objects rather than comparing
individual fields
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
Common Behavior Smells


Slow Tests
Erratic Tests



Fragile Tests




Interacting Tests:
When one test fails, a bunch of other tests fail for no
apparent reason because they depend on other tests’ side
effects
Unrepeatable Tests:
Tests can’t be run repeatedly without intervention
The 4 sensitivities
Assertion Roulette
Frequent Debugging
Manual Intervention
Patterns







Shared Fixture
Fresh Fixture
Standard Fixture
Minimal Fixture
Lazy Setup
Setup Decorator
SuiteFixture Setup
Common Project Smells

Developers Not Writing Tests

Symptoms: No tests can be found when you ask to see:




Buggy Tests
Production Bugs


Unit tests for a task
Customer tests for a User Story
Symptoms: Bugs are being found in production
High Test Maintenance Cost
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
Rename Column
The Process
Verify that a
refactoring is
needed
Deprecate the
Original
Schema
(optional)
Choose the
Right
Refactoring
[Not
Needed]
[Pass]
Write a
Unit Test
Run the tests
[Fail]
Change your
schema
Migrate
Data
(optional)
Update External
Access
Programs
[Fail]
Run the tests
[Work
continues]
[Finished]
Announce
The Refactoring
Version
Control Your
Work
Other Database Refactorings











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











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
Database Refactoring Plug-In: www.eclipse.org/epf
Philosophies of Agile Data Method






Data is one of several important aspects of softwarebased 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.
Exploratory Testing


Exploratory testing is simultaneous
learning, 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
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
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
Research Papers
http://agile2006.com/program/Program
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
AgileEVM – Earned Value Management in Scrum Projects
Earned Value and Agile Reporting
An Empirical Study of Using Planning Poker for User Story
Estimation
Executable Acceptance Tests for Communicating Business
Requirements: Customer Perspective
On Agile Performance Requirements Specification and Testing
Refactoring with Contracts
The Role of Story Cards and the Wall in XP teams: a
distributed cognition perspective
A Case Study on the Impact of Customer Communication on
Defects in Agile Software Development
Reflections on Reflection in Agile Software Development
Critical Personality Traits in Successful Pair Programming
What Lessons Can the Agile Community Learn from a
Maverick Fighter Pilot?
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
What does it really mean for a software
development organization to be agile?

“It may say agile on the box, but it doesn’t 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 ObservationOrientation-Decision-Action (OODA) loop faster than an
adversary
Observe
Unfolding
Circumstances
Orient
Decide
Act
Cultural
Traditions
Genetic
Heritage
Analyses &
Synthesis
New
Information
Previous
Experience
Observations
Decision
(Hypothesis)
Action
(Test)
Outside
Information
Agility: Execute your OODA loop more quickly than your adversary
Agility is a Cultural Phenomenon

Blitzkrieg’s principles:





People, ideas, technology…in that order!


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
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
Agility’s 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
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 organization’s objective is to survive on its own terms
 Software development is commerce and commerce is
about competition
Implications of the OODA loop for
the Agile community
1.
2.
3.
4.
5.
Agility is a time based strategy for operational
success and is not based on size
Agility is a relative concept, not an absolute
concept
Agility is an essential attribute for project success,
large or small
Agility depends on organizational culture (unity,
trust, intent, focus)
We are late to the party
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?
The End