Summary

When Agile was first starting out, it was possible to be the only developer on the team who knew anything about Agile (aka "Extreme Programming" at the time). Some team leads did not want to change the development environment.

The following is a rough, "stealth" way to do Agile in that environment. Or for those personal projects that you want solid reliability.

Note: I used Agile terminology below. But when speaking to outside people it may be best to use the more common terminology, for example:

  • story => requirement
  • iteration => periodic delivery period

Agile for One

  • Setup the development environment (done once)

    • set up your build environment
    • Set up your UT driver as an add-in for the IDE
    • set up your AT driver
    • set up deployment/acceptance area (i.e. a place where the customer can try out the latest and greatest code)
  • Initial meeting with customer

    • Gather requirements (stories) from customer
    • set up 2 week delivery period (iteration)
    • set up expectations on how development is going to occur

      • indicate that you'd like to give a "status report" every two weeks
      • indicate that you're willing to accept new stories as they become apparent
      • indicate that you're willing to change the order the stories are done as the need becomes apparent
      • indicate that you're more willing to change the story list or order of stories at "status report" time
    • For each iteration until project is done

      • For each Story until all Stories are done

        • Write the AT
        • Break the Story down into Tasks
        • For each Task until the AT runs successfully
          • Write the UT
          • Code until the UT passes
          • Refactor Mercilessly
          • Write any other UT for "fleshing out" the Task; code & refactor mercilessly
          • run the AT
        • Run all UTs & ATs to check nothing else has broken
        • Check the code in and compile the system
        • (optional) Re-run all Unit Tests & Acceptance tests
        • If during this process the customer comes in with a change, adjust stories in current iteration as necessary.
      • Deliver the stories

        • Calculate your velocity for this iteration
        • calculate which stories you can complete next iteration using your velocity
        • copy executables, etc. to the deployment area
        • write a note or contact the customer
          • indicate what has been changed since the last deployment (i.e. list the stories you completed)
          • give instructions on how he/she invokes the system
          • indicate which stories you'll complete next iteration reminding the customer that these were next in line
          • get feedback asking if the story order is correct, or if there are any missing stories

- John Arrizza