Agile Software Development

1
Agile Software Development

• Jim Moore
• Symantec Software

2
The Value of Planning

• Every plan gets thrown out on the first day of
  battle. Plans are useless. Planning is
  everything.
• -General Dwight D. Eisenhower
• Sadly, traditionally software development
  processes have focused on the artifacts of
  planning, not on the value that the process
  itself provides.
• To respond effectively to a rapidly changing
  world, the planning process must be a part of
  the implementation process and vice-versa.

3
Principles of Agile Development
4
Manifesto for Agile Software Development

• We are uncovering better ways of developing
  software by doing it and helping others do it.
  Through this work we have come to value
• Individuals and interactions over processes and
  tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
• That is, while there is value in the items on the
  right, we value the items on the left more.

5
Individuals and Interactions over Processes and
Tools

• Focus on good people who work well together.
• A good team with no process (or, worse, a bad
  one) is better than a bad team with a good
  process
• Ideally the team should be made up of
  generalizing specialists people who
  specialize in something, but are conversant in
  all the disciplines the team needs.

6
Individuals and Interactions Principles

• Build projects around motivated individuals. Give
  them the environment and support they need, and
  trust them to get the job done.
• The most efficient and effective method of
  conveying information to and within a development
  team is face-to-face conversation.
• At regular intervals, the team reflects on how to
  become more effective, then tunes and adjusts its
  behavior accordingly.

7
Working Software overComprehensive Documentation

• Were not paid to develop documentation, were
  paid to develop software.
• Of course that doesnt mean that documentation is
  unimportant, but it has to be considered relative
  to its cost in delivering functionality (ie,
  software).

8
Working Software Principles

• Deliver working software frequently, from a
  couple of weeks to a couple of months, with a
  preference to the shorter timescale.
• Working software is the primary measure of
  progress.

9
Customer Collaboration overContract Negotiation

• The primary purpose of collaboration is to work
  with the customer to make sure that they are
  involved in delivering the final product they
  need. The primary purpose of a contract is to
  cover your posterior
• Change management is all-too-often a euphemism
  for change prevention.

10
Customer Collaboration Principles

• Business people and developers must work together
  throughout the project.
• Our highest priority is to satisfy the customer
  through early and continuous delivery of valuable
  software.

11
Responding to Change overFollowing a Plan

• A changed requirement late in the lifecycle is a
  competitive advantage as long as you can act on
  it.
• If you froze requirements 18 months ago and
  deliver tomorrow, your software is delivering on
  the business needs of 18 months ago.
• Note This does not apply if nothing in the
  business ever changes, or if youre a deity with
  a 100 accuracy rate in predicting the future

12
Responding to Change Principles

• Welcome changing requirements, even late in
  development. Agile processes harness change for
  the customer's competitive advantage.
• Continuous attention to technical excellence and
  good design enhances agility.

13
Miscellaneous Principles

• Simplicity the art of maximizing the amount of
  work not done is essential.
• The best architectures, requirements, and designs
  emerge from self-organizing teams.
• Agile processes promote sustainable development.
  The sponsors, developers, and users should be
  able to maintain a constant pace indefinitely.
• Also known as the 40 Hour Week Rule.

14
Pain Points Caused by Doing This

• Because its highly empirical, a lot of things
  become evident very quickly that otherwise would
  not, such as
• How far behind you are on delivering the product
• How poorly your tests have been developed
• That the customer like to think in terms of
  requirements rather than prioritizing business
  value
• That not having sufficient documentation is
  hampering bringing people on
• That youre spending too much time documenting
  rather than delivering direct business value
• How poorly you actually understand the
  requirements that the customer gave
• etc.
• Its a very, very painful process

15
Practices of Agile Development
16
Some of the Methodologies

• The most popular methodologies are
• XP (eXtreme Programming)
• Scrum
• Crystal
• FDD (Feature Driven Development)
• DSDM (Dynamic Systems Development Method)
• AUP (Agile Unified Process)
• Some, like XP, focus almost solely on development
  with few management practices. Others, like
  Scrum, focus in the opposite direction. (Its
  common to see hybrids like XBreed.) Some, like
  AUP, prescribe the whole package.

17
Which Methodology Works Best?

• If you have a customer thats willing to work
  closely with the developers, the business needs
  product more than it needs documentation, and the
  developers are all smart, disciplined, motivated
  and team-players XP.
• If you have a customer thats not able to work
  closely with the developers, the business needs
  predictability more than it needs product, and
  the team is comprised primarily of labor
  RUP/AUP/DSDM.
• Most projects are in between.

18
Common Practices

• Short iterations (1 week to 1 month)
• Continuous communication integration
• Designs driven by testability
• User Stories
• Dont over-design (YAGNI), refactoring when
  needed
• Travel Light

19
Scrum Cycle
20
Short Iterations

• Usually 1 week (eg, XP or Evo) to 1 month (eg,
  Scrum)
• During an iteration, requirements are usually
  fixed
• This enables developers to have stability while
  the business gets the ability to respond to
  change
• The highest priority things are always worked on
  first
• This means that at any point in time, youre
  delivering the maximum possible business value
• By extension, this also means that you avoid
  things that dont have the highest business value
• Estimating things much beyond a week is iffy

21
Continuous Communication Integration

• Follows the general Principle of Least Surprise
• Teams are self organizing
• Have the responsibility and ability to identify
  and remove roadblocks
• Autonomous sets its own policies and procedures
  within the context of the larger organizations
• Everyone on the team knows what everyone else is
  doing
• Use Big Visible Charts

22
Designs Driven by Testability

• In order to be flexible and know that changes you
  make later wont break things, its vital that
  the system tells you immediately if something no
  longer works
• In general, something isnt a requirement unless
  it can be tested
• Helps both the customer and the developer think
  clearly about what is needed

23
User Stories

• Similar to use cases and functional
  requirements documents, but not -)
• The basic idea is to quickly (a sentence a
  paragraph) give description of whats needed
• The point is to encourage collaboration over
  contracts while still providing the written
  record of what is needed

24
Dont Over-Design

• Business needs change, so requirements change
• Youre name isnt YHWH dont over-estimate how
  well you can predict the future
• Of course if you know something is likely going
  to be needed, take it into account. But dont
  sacrifice present needs for future ones, because
  to quote Yoda constantly in motion is the
  future

25
Travel Light

• Do the simplest thing possible, using the
  simplest tools possible
• That may mean using Rational Rose and CMM to do a
  global messaging application in C
• That may also mean using index cards, REST and
  Ruby
• Not overburdening the system, tools and processes
  enables you to more easily respond to change

26
Scrum Cycle (review)
27

QUESTIONS
ANSWERS
28
Resources

• http//agilealliance.com/
• http//agilemodeling.com/
• http//www.controlchaos.com/
• http//www.itconversations.com/shows/detail355.htm
  l
• http//www.itconversations.com/shows/detail350.htm
  l
• http//www.itconversations.com/shows/detail175.htm
  l