Agile Methodology

1
Agile Methodology Programming

• Ric Holt
• July 2009

2
Reaction to Pure Waterfall Model

• Around 1990, writing and discussion of more fine
  grained and more adaptive methodologies.
• Need for faster development, notably when spec is
  not well known and teams are small.

3
Agile Programming 2001Wikipedia

• Development methodology based on
• Iterative development
• Collaboration
• Self-organizing teams
• Goal New release at end of each interaction
• Ideally face-to-face team interactions
• Ideal team size 7 /- 1
• Daily meetings/interactions, perhaps with client

4
Definition of the term manifesto

• A public declaration of principles, policies, or
  intentions, especially of a political nature.

5
Agile Software Development Agile Manifesto
2001

• Individuals and interactions over processes and
  tools
• Working software over comprehensive documentation
  
• Customer collaboration over contract negotiation
• Responding to change over following a plan

6
Principles behind the Agile Manifesto

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.
6. The most efficient and effective method of
   conveying information to and within a
   development team is face-to-face conversation.

1. Working software is the primary measure of
   progress.
2. Agile processes promote sustainable development.
   The sponsors, developers, and users should be
   able to maintain a constant pace indefinitely.
3. Continuous attention to technical excellence and
   good design enhances agility.
4. Simplicity--the art of maximizing the amount of
   work not done--is essential.
5. The best architectures, requirements, and designs
   emerge from self-organizing teams.
6. At regular intervals, the team reflects on how
   to become more effective, then tunes and adjusts
   its behavior accordingly.

7
Extreme Programming

• A software methodology
• A type of agile programming
• Has short development cycles (called boxes)
  releases
• Advocates pair programming, ongoing unit
  testing, flat management structure, frequent
  communication among team with customer

8
Possible drawbacks of extreme programming Beck
1996

• Lack of overall specification
• (In)ability to scale up to large projects

9
The game of rugby --- similar to American football

• Scrum. Packs of opposing players push against
  each other for possession of the ball
• Once a team gets the ball, it attempts to
  sprint to the goal line.

10
The rugby scrum
11
The rugby sprint
wesleying.blogspot.com/2009/03/mens-club-rugb..
12
Scrum Development 1986

• Scrum incremental framework for managing
  complex work (such as new product development)
  commonly used with agile software development.

13
Three major roles in scrum

1. ScrumMaster, who maintains the processes
   (typically in lieu of a project manager)
2. Product Owner, who represents the stakeholders
   and
3. Team, a cross-functional group of about 7 people
   who do the actual analysis, design,
   implementation, testing, etc.

14
Daily Scrum (15 minute meeting)

• What have you done since yesterday?
• What are you planning to do by today?
• Do you have any problems preventing you from
  accomplishing your goal?

15
Burndown chart
http//www.xqual.com/resources/images/scrum_burndo
wn_chart.gif
16
Sprint Planning Meeting

• Plan next 15-30 days
• Select what work is to be done
• Prepare the Sprint Backlog that details the time
  it will take to do that work, with the entire
  team
• Identify and communicate how much of the work is
  likely to be done during the current sprint
• Eight hour limit

17
Sprint Review Meeting

• Review the work that was completed and not
  completed
• Present the completed work to the stakeholders
  (a.k.a. "the demo")
• Incomplete work cannot be demonstrated
• Four hour time limit

18
Sprint Retrospective

• All team members reflect on the past sprint.
• Make continuous process improvement.
• Two main questions are asked in the sprint
  retrospective What went well during the sprint?
  What could be improved in the next sprint?
• Three hour time limit

19
Scrum diagram
www.methodsandtools.com/archive/archive.php?id18