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/)

Martin FowlerJames GrenningJim HighsmithAndrew HuntRon Jeffries

Kent BeckMike BeedleArie van BennekumAlistair CockburnWard CunninghamDave Thomas

Jon KernBrian MarickRobert C. MartinSteve MellorKen SchwaberJeff Sutherland

Research Papershttp://agile2006.com/program/Program

1. AgileEVM – Earned Value Management in Scrum Projects2. 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?

Research Papershttp://agile2006.com/program/Program

1. AgileEVM – Earned Value Management in Scrum Projects2. 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?

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

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

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

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

Common Behavior Smells Slow Tests Erratic 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

Fragile Tests 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:

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

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 ProcessVerify that a

refactoring is needed

Run the tests

Change your schema

MigrateData

(optional)

[Fail]

[Pass]

[Not Needed]

[Finished]

[Work continues]

Choose theRight

Refactoring

Write aUnit Test

Deprecate the OriginalSchema

(optional)

Update ExternalAccess

Programs

Run the tests

AnnounceThe Refactoring

VersionControl Your

Work

[Fail]

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

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 Papershttp://agile2006.com/program/Program

1. AgileEVM – Earned Value Management in Scrum Projects2. 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?

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

Orientation-Decision-Action (OODA) loop faster than an adversary

Observe Decide ActOrient

Agility: Execute your OODA loop more quickly than your adversary

Action(Test)

Decision(Hypothesis)Observations

UnfoldingCircumstances

OutsideInformation

CulturalTraditions

GeneticHeritage

NewInformation

PreviousExperience

Analyses &Synthesis

Agility is a Cultural Phenomenon Blitzkrieg’s 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, technology…in 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

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 community1. Agility is a time based strategy for operational

success and is not based on size2. Agility is a relative concept, not an absolute

concept3. Agility is an essential attribute for project success,

large or small4. Agility depends on organizational culture (unity,

trust, intent, focus)5. 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