KEMBAR78
Agile Development Overview (with a bit about builds) | KEY
This is my Tech Talk Presentation.
    My Tech Talk Presentation is amazing.

Agile Development Overview
         With a little emphasis on
         Continuous Integration
Agile Development

• a.k.a. "eXtreme Programming" (XP)
• a.k.a. "Scrum"
• a.k.a. “Lean Development”
• All share similar practices, so generally
  grouped as “Agile Methodologies”
talk ingredients

• 2 bits on theory
• 2 bits on practice
• 2 tangential asides
talk sequence

• A little theory/values/principles
• Some practices
• A bit more theory/values/principles
• A little more about Continuous Integration
  (automated builds)
Lets talk about methodology:
    “waterfall” vs. “agile”
waterfall sequence

• specify
• design
• implement
• test
• deploy
Why Waterfall is easy:

• easy to plan
• easy to fund
• easy to predict (like planning)
• easy to plug into Microsoft Project
For many things, Waterfall is great.

Like building new buildings, dams, U2 concerts, weddings,
                     etc. this is fine.
For software, a formal waterfall
  can be difficult because it:

• doesn't like to re-specify
• doesn't like to re-design
• doesn't like to re-implement
• doesn't like to re-test
• doesn't like to re-deploy
"doesn't like" = more money, more time, poor results
"poor results" = “You gave us what we asked for, but it isn't
                      what we want.”
This happens a lot.
Tangential Aside #1
IT work is fun & well paid.
Ok, not always, fun.
But often engaging in a particularly nice way.
I have friends who are journalists, teachers, legal aid
                 lawyers, and accountants.

Their work is significant, inspiring, and important, but often
                financially very challenging.

                 I struggle with why this is.
I also have friends who are investment bankers, business
              owners, and corporate lawyers.

They make heaps, and the significance of their work is up
                    for discussion.

                I struggle with this too.
Ahem, my point...
is that IT work as a career is quite well paid, thanks very
                          much.

Particularly considering how much fun it is (if you are so
                         inclined).
The converse of this is that businesses see IT work as
             tremendously expensive.
It is also mysterious, risky, and career threatening to run an
                 IT project within a business.
(And they see IT people making money and having fun, and
                   this doesn't help.)
As IT people we need to respect this.
One way is to simply cease having, or appearing to have,
                         fun.

 Which is what many of the major consulting firms do.

            They charge quite a lot for this.
Another way to fix the situation is to use processes that
  strive to deliver actual value as quickly as possible.

          This is what a lot of Agile is about.
end tangential aside #1
Four XP values:

Communication

  Simplicity

  Feedback

   Courage
A dozen Common Agile Practices in no particular order
Morning Standup

 (communication)

       1
Iterations

a.k.a. “Scrums”, or “Sprints”


   (simplicity, feedback)

             2
Continuous Integration

  automated build (& test)

        (feedback)

             3
Test Driven Development (TDD)

       (feedback, courage)

               4
Retrospectives

(communication)

      5
Story Cards/Story Wall


 (communication, feedback)

            6
Velocity

(feedback)

    7
Pair Programming


 (communication, ?)

         8
Technical Debt


(simplicity?, courage?)

          9
Refactoring


 (courage)

    10
Showcases


(communication, feedback)

           11
Iteration Planning

a.k.a “The Planning Game”

(simplicity, communication)

            12
Some of these techniques need each other

               examples:

         Refactoring needs TDD

   TDD needs Automated build & test
Some of these techniques standalone, and can add value
             regardless of methodology.

                 Retrospectives &
               Continuous Integration
                      are two
Lets talk about a bit more
Agile values/theory/manifesto/dogma
“Agile Values”

•   Individuals and interactions over processes and tools

•   Working software over comprehensive documentation

•   Customer collaboration over contract negotiation

•   Responding to change over following a plan
The Agile Manifesto : Twelve principles
•   Customer satisfaction by rapid delivery of useful software

•   Welcome changing requirements, even late in development.

•   Working software is delivered frequently (weeks rather than months)

•   Working software is the principal measure of progress

•   Sustainable development, able to maintain a constant pace

•   Close, daily cooperation between businesspeople and developers

•   Face-to-face conversation is the best form of communication (co-location)

•   Projects are built around motivated individuals, who should be trusted

•   Continuous attention to technical excellence and good design

•   Simplicity

•   Self-organizing teams

•   Regular adaptation to changing circumstances
Just so you know,
I am a Scrum Master.
David Benjamin
                           September 7th 2007




                           [ MEMBER: 000017685 ] [ EXPIRES: 2011-04-01 ]


                                                                              Tom Mellor
Certified Scrum Trainer                                                    Chairman of the Board
There are books

• Kent Beck, “Extreme Programming
  Explained”
• Mary & Tom Poppendieck, “Lean Software
  Development”
• and oh so many more
Tangential aside #2
I mentioned “Amiga” which was a computer that existed
                 briefly in the 1980’s

   Please allow me to discuss two perception issues.
1. "Anything that is in the world when you're born is
normal and ordinary and is just a natural part of the way
                    the world works".

2. "Anything that's invented between when you're fifteen
and thirty-five is new and exciting and revolutionary and
           you can probably get a career in it".

3. "Anything invented after you're thirty-five is against the
 natural order of things and the beginning of the end of
                civilization as we know it".

                    -- Douglas Adams
In the IT profession, describing or telling
personal anecdotes about technology that is...


•   less than 2 years old - is cool and shows you are hip.

•   between 2 and 5 years old - is acceptable and safe.

•   between 5 and 10 years old - is risky and should be only
    mentioned vaguely, as if you read about it someplace or
    heard people talking.

•   more than 10 years old - don't talk about it. If you make
    the mistake and do, back away from it and pretend its an
    old joke of your fathers.
In reality, both jokes are perception issues.
Try to rise above them and make sensible decisions about
                    what is useful and good
          and what is either past its use-by date,
                      or strongly hyped.
End of tangential aside #2
Right, we were finishing up talking about agile values a
                    second time.

                  One more thing:

  As with many things these days, the community is
       surprisingly small and very accessible.

                       Tune in!
Automated Build
Build breaks can have a lot of hidden,
         but very immediate,
                costs.
Discovering integration or installation problems late
             can force a lot of rework,
                  and sometimes,
                breathtaking hacks.
Automated build can be as simple as a script launched
                 every 10 minutes.
build logic
•   has someone checked stuff in? (no -> quit, yes -> continue)

•   check out or update all the source

•   build the code

•   run tests (if any)

•   build the installers (if any)

•   light the green light.

•   any failures? light the red light.
“Green light” means

• all code is compiling/building
• all tests are passing
• there are installers available on the build
  box
Most teams say, "When the light is red, nobody should
       commit changes until the build is fixed."
If your test coverage is good,
 the build can give the team a lot of confidence
to do major refactoring late in the project cycle.

                   Courage.
If you need to do frequent releases,
              under pressure,
having the installer come off the build box
          removes a lot of risk...

                 and fear.
Build Tools

• Hudson
• CruiseControl
• Bamboo
• others (commercial & open source)
Note: It is important to make sure no
          "special magic" exists on the buildbox
         and that the build can be run quite easily
                    on any dev machine.

  This makes sure the whole build process is checked in.

It makes sure that someone (the source) always knows how
                    to build an installer.
Questions?
Thanks!

Agile Development Overview (with a bit about builds)

  • 1.
    This is myTech Talk Presentation. My Tech Talk Presentation is amazing. Agile Development Overview With a little emphasis on Continuous Integration
  • 2.
    Agile Development • a.k.a."eXtreme Programming" (XP) • a.k.a. "Scrum" • a.k.a. “Lean Development” • All share similar practices, so generally grouped as “Agile Methodologies”
  • 3.
    talk ingredients • 2bits on theory • 2 bits on practice • 2 tangential asides
  • 4.
    talk sequence • Alittle theory/values/principles • Some practices • A bit more theory/values/principles • A little more about Continuous Integration (automated builds)
  • 5.
    Lets talk aboutmethodology: “waterfall” vs. “agile”
  • 6.
    waterfall sequence • specify •design • implement • test • deploy
  • 7.
    Why Waterfall iseasy: • easy to plan • easy to fund • easy to predict (like planning) • easy to plug into Microsoft Project
  • 8.
    For many things,Waterfall is great. Like building new buildings, dams, U2 concerts, weddings, etc. this is fine.
  • 9.
    For software, aformal waterfall can be difficult because it: • doesn't like to re-specify • doesn't like to re-design • doesn't like to re-implement • doesn't like to re-test • doesn't like to re-deploy
  • 10.
    "doesn't like" =more money, more time, poor results
  • 11.
    "poor results" =“You gave us what we asked for, but it isn't what we want.”
  • 12.
  • 13.
  • 14.
    IT work isfun & well paid.
  • 15.
    Ok, not always,fun. But often engaging in a particularly nice way.
  • 16.
    I have friendswho are journalists, teachers, legal aid lawyers, and accountants. Their work is significant, inspiring, and important, but often financially very challenging. I struggle with why this is.
  • 17.
    I also havefriends who are investment bankers, business owners, and corporate lawyers. They make heaps, and the significance of their work is up for discussion. I struggle with this too.
  • 18.
    Ahem, my point... isthat IT work as a career is quite well paid, thanks very much. Particularly considering how much fun it is (if you are so inclined).
  • 19.
    The converse ofthis is that businesses see IT work as tremendously expensive.
  • 20.
    It is alsomysterious, risky, and career threatening to run an IT project within a business.
  • 21.
    (And they seeIT people making money and having fun, and this doesn't help.)
  • 22.
    As IT peoplewe need to respect this.
  • 23.
    One way isto simply cease having, or appearing to have, fun. Which is what many of the major consulting firms do. They charge quite a lot for this.
  • 24.
    Another way tofix the situation is to use processes that strive to deliver actual value as quickly as possible. This is what a lot of Agile is about.
  • 25.
  • 26.
    Four XP values: Communication Simplicity Feedback Courage
  • 27.
    A dozen CommonAgile Practices in no particular order
  • 28.
  • 29.
    Iterations a.k.a. “Scrums”, or“Sprints” (simplicity, feedback) 2
  • 30.
    Continuous Integration automated build (& test) (feedback) 3
  • 31.
    Test Driven Development(TDD) (feedback, courage) 4
  • 32.
  • 33.
    Story Cards/Story Wall (communication, feedback) 6
  • 34.
  • 35.
  • 36.
  • 37.
  • 38.
  • 39.
    Iteration Planning a.k.a “ThePlanning Game” (simplicity, communication) 12
  • 40.
    Some of thesetechniques need each other examples: Refactoring needs TDD TDD needs Automated build & test
  • 41.
    Some of thesetechniques standalone, and can add value regardless of methodology. Retrospectives & Continuous Integration are two
  • 42.
    Lets talk abouta bit more Agile values/theory/manifesto/dogma
  • 43.
    “Agile Values” • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan
  • 44.
    The Agile Manifesto: Twelve principles • Customer satisfaction by rapid delivery of useful software • Welcome changing requirements, even late in development. • Working software is delivered frequently (weeks rather than months) • Working software is the principal measure of progress • Sustainable development, able to maintain a constant pace • Close, daily cooperation between businesspeople and developers • Face-to-face conversation is the best form of communication (co-location) • Projects are built around motivated individuals, who should be trusted • Continuous attention to technical excellence and good design • Simplicity • Self-organizing teams • Regular adaptation to changing circumstances
  • 45.
    Just so youknow, I am a Scrum Master.
  • 46.
    David Benjamin September 7th 2007 [ MEMBER: 000017685 ] [ EXPIRES: 2011-04-01 ] Tom Mellor Certified Scrum Trainer Chairman of the Board
  • 47.
    There are books •Kent Beck, “Extreme Programming Explained” • Mary & Tom Poppendieck, “Lean Software Development” • and oh so many more
  • 48.
  • 49.
    I mentioned “Amiga”which was a computer that existed briefly in the 1980’s Please allow me to discuss two perception issues.
  • 50.
    1. "Anything thatis in the world when you're born is normal and ordinary and is just a natural part of the way the world works". 2. "Anything that's invented between when you're fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it". 3. "Anything invented after you're thirty-five is against the natural order of things and the beginning of the end of civilization as we know it". -- Douglas Adams
  • 51.
    In the ITprofession, describing or telling personal anecdotes about technology that is... • less than 2 years old - is cool and shows you are hip. • between 2 and 5 years old - is acceptable and safe. • between 5 and 10 years old - is risky and should be only mentioned vaguely, as if you read about it someplace or heard people talking. • more than 10 years old - don't talk about it. If you make the mistake and do, back away from it and pretend its an old joke of your fathers.
  • 52.
    In reality, bothjokes are perception issues. Try to rise above them and make sensible decisions about what is useful and good and what is either past its use-by date, or strongly hyped.
  • 53.
  • 54.
    Right, we werefinishing up talking about agile values a second time. One more thing: As with many things these days, the community is surprisingly small and very accessible. Tune in!
  • 55.
  • 56.
    Build breaks canhave a lot of hidden, but very immediate, costs.
  • 57.
    Discovering integration orinstallation problems late can force a lot of rework, and sometimes, breathtaking hacks.
  • 58.
    Automated build canbe as simple as a script launched every 10 minutes.
  • 59.
    build logic • has someone checked stuff in? (no -> quit, yes -> continue) • check out or update all the source • build the code • run tests (if any) • build the installers (if any) • light the green light. • any failures? light the red light.
  • 60.
    “Green light” means •all code is compiling/building • all tests are passing • there are installers available on the build box
  • 61.
    Most teams say,"When the light is red, nobody should commit changes until the build is fixed."
  • 62.
    If your testcoverage is good, the build can give the team a lot of confidence to do major refactoring late in the project cycle. Courage.
  • 63.
    If you needto do frequent releases, under pressure, having the installer come off the build box removes a lot of risk... and fear.
  • 64.
    Build Tools • Hudson •CruiseControl • Bamboo • others (commercial & open source)
  • 65.
    Note: It isimportant to make sure no "special magic" exists on the buildbox and that the build can be run quite easily on any dev machine. This makes sure the whole build process is checked in. It makes sure that someone (the source) always knows how to build an installer.
  • 66.
  • 67.