Agile Development and Extreme Programming

CS3300Fall 2015

The Environment

• Failed Projects

• Canceled Projects

• Can’t adapt to requirements changes

• Good programmers quit due to constant death march

• Producing mountains of paper, but not mountains of code

• Big designs were often shelf-ware

Agile Manifesto

• Individuals and interactions -- over processes and tools

• Working software -- over comprehensive documentation

• Customer collaboration -- over contract negotiation

• Responding to change -- over following a plan

While there is value in the things on the right, We value the things on the left more

Agile Principles

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Agile Principles

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity--the art of maximizing the amount of work not done--is essential.

Agile Principles

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Vision

• The vision statement documents three things: what the project should accomplish, why it is valuable, and the project's success criteria.

• I would watch out for 'Agile Thrashing.' In other words, your team makes steady progress, but when you look back at the work they've done, it doesn't form a coherent whole. You end up shot-gunning a bunch of little ideas rather than making progress on any big ideas.

• Our design project???

Release Planning

• Frequent smaller releases

• Scope-Based Release: Define the features in advance, but not the timeline.

• Timeboxed Release: Define the times of releases, but the not the features.

• Agile generally prefers timeboxed

• Never try to do both schedule and time in the release.

Release Planning (continued)

Minimum Marketable Features : the smallest set of functionality that provides value to your market, whether that market is internal users (as with custom software) or external customers (as with commercial software). MMFs may provide value in many ways, such as competitive differentiation, revenue generation, and cost savings.

What are some MMF’s for our project?

How might we group those into release targets for official releases?

Iteration Planning Releases span several weeks, we need a way to track progress –

the iteration Each iteration is one week, they form the heartbeat of the

project. At end of each iteration, we compare reality to the plan Iteration Schedule:

Demo previous iteration

Hold retrospective (post-mortem)

Plan the iteration

Commit to story delivery

Develop the stories

Prepare the iteration release

Done Done (Sample Completion Criteria)

Tested (all unit, integration, and customer tests finished)

Coded (all code written)

Designed (code refactored to the team's satisfaction)

Integrated (the story works from end to end—typically, UI to database—and fits into the rest of the software)

Builds (the build script includes any new modules)

Installs (the build script includes the story in the automated installer)

Migrates (the build script updates database schema if necessary; the installer migrates data when appropriate)

Reviewed (customers have reviewed the story and confirmed that it meets their expectations)

Fixed (all known bugs have been fixed or scheduled as their own stories)

Accepted (customers agree that the story is finished)

Essay = The Agile Disease• From a rant:

Firstly, beware following any kind of methodology. All methodologies imply a prescribed approach, a single-minded, fixed set of processes that removes flexibility and rationality. But in software, they’re fundamentally designed for mediocre developers who can’t think for themselves. They’re designed by consultants who won’t be around for long.

A specific danger of the Agile processes is doing the easy parts and not the hard parts.

Agile gives you an excuse for not introducing a little rigour and discipline into your project.

More from rant

• Having daily stand-up meetings is ludicrous; it exists simply to protect against the dysfunction of team members that never talk to one another.

• From a response: You are correct on most points. It is not for you or for me. The fact that it helps some people is both good, and saddening. The only thing that really works is the Personal Software Process by Watts Humphrey. It is difficult to implement and hard to stick with.

Agile Techniques / Methods

• Rup Dx

• SCRUM

• Extreme Programming

• Lean / Kanban

• Crystal

• Rapid Application Delivery (RAD) and Dynamic Systems Development Strategy (DDSM)

• Feature Driven Development

Extreme Programming

Lifecycle

Extreme Programming (XP) Rules• Planning

• User stories are written

• Release planning creates the release schedule.

• Make frequent small releases.

• The project is divided into iterations.

• Iteration planning starts each iteration.

User Stories

• Lighter weight than requirements or use cases

• Placeholders for customer negotiation, don’t contain full information

• Estimated with story points (abstract measure)

• Phrased like:

• Quarterly Report Preparation

• As a manager, I want to generate a quarterly report so that I can send it to my boss.

• Progress tracked by burndowns and by velocity

XP Release and Iteration Planning• Stories are put on cards or stickies

• Stories are estimated (4-10 per iteration)

• Stories are grouped by priority in conjunction with the customer

• Stories are assigned to releases (Release Board)

• First release is then broken up into iterations (1-3 weeks)

• Stories in first iteration are moved to iteration board

• Developers take stories and break them up into tasks (different color stickies)

• Task should take 1 – 3 days

• Developers pick stories to work on and begin rest of XP process.

XP Rules

• Management

• Give the team a dedicated open work space.

• Set a sustainable pace.

• A stand up meeting starts each day.

• The Project Velocity is measured.

• Move people around.

• Fix XP when it breaks.

XP Rules

• Design

• Simplicity.

• Choose a system metaphor.

• Use CRC cards for design sessions.

• Create spike solutions to reduce risk.

• No functionality is added early.

• Refactor whenever and wherever possible.

XP Rules

• Coding

• The customer is always available.

• Code must be written to agreed standards.

• Code the unit test first.

• All production code is pair programmed.

• Only one pair integrates code at a time.

• Integrate often.

• Set up a dedicated integration computer.

• Use collective ownership.

Pair Programming

• Many studies – albeit most are in academia

• Laurie Williams – 15% more effort, but produces results more quickly and with 15% fewer defects.

• One person driver, one is navigator

• Reinforce good habits

• Switch partners often

• Be comfortable

• Ask questions

• If things get really quiet, then there is a problem

• Collaborate, don’t critique

XP Rules

• Testing

• All code must have unit tests.

• All code must pass all unit tests before it canbe released.

• When a bug is found tests are created.

• Acceptance tests are run often and the scoreis published.

Boosting Velocity

• Pay down technical debt

• Improve customer involvement

• Support Energized work (kill overtime)

• Offload programmer duties

• Provide better resources

• Add more programmers

• But Fred Brooks – “adding programmers to a late project only makes it later”

Retrospectives (Post-Mortem)• Start with prime directive:

• Write headings: Enjoyable, Frustrating, Puzzling, Same, More, Less

• Everyone writes down 4-5 things about iteration

• Grouping

• Choose 1 category

• Develop objectives for next iteration improvement

James Shore Book of Agile

Regardless of what we discover today, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

Risk Mitigation with XP• Schedule Slips: short release cycles (every few months), works

on highest priority tasks first, demos to customer at end of each iteration

• Project Canceled: customer helps plan release

• System goes sour: maintain extensive tests, run daily

• Defect rate: test from both programmer and customer

• Business misunderstood: customer is part of team. Continual refinement of spec

• Business changes: short release cycles

• False feature rich: only highest priority tasks are worked on

• Staff turnover: programmers involved in estimation, work together, limited death march schedules.

The Extreme in XP

• Pair Programming

• Frequent integration

• Test-Driven development

• Iteration/Release Planning

What does Bob like::

• Code reviews – but maybe not pair program always

• Frequent integration

• Automated unit tests (but maybe not TDD)

• Collective ownership

• 40 hour week

• Estimation/release/iteration planning

What does Bob not like:

• Metaphor instead of architecture