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. 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 Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries What Is Agile Software Development? 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

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

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

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

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. 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 Agile Reflection Technique

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

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. 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 Other Database Refactorings 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. 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 Contrasting Approaches

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/Program • 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?

32. 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 Coaching Techniques

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

34. UnfoldingCircumstances CulturalTraditions GeneticHeritage Analyses &Synthesis Decision(Hypothesis) Action(Test) Observations PreviousExperience NewInformation OutsideInformation Observe Orient Decide Act Agility: Execute your OODA loop more quickly than your adversary

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

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 organization’s 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 • 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

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