Planning Agile Projects

Uploaded on

Book Review of Planning eXtreme Programming (XP)

Book Review of Planning eXtreme Programming (XP)

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide
  • Planning XP 1/22/2002 H.Briley


  • 1. Planning e X treme P rogramming (XP)
    • How little can we do
    • … and still build great software?
            • A book review by Harry Briley, January 22, 2002
    • ICS Group Leader, Lawrence Livermore National Lab
  • 2. By Kent Beck and Martin Fowler, 140 pages
    • (the GREEN book)
    • These slides have only a few highlights
    • Copyright law : Buy a copy of the book
  • 3. PLAN? “I have always found plans … useless, but planning … indispensable” – Eisenhower
    • What really matters today is building software fast
        • But often introduced to projects when they are mostly dead
    • Agile/XP Keys:
        • Break large jobs into 3-week self-contained mini-projects
        • Enable developers to work without a formal process
    • Most Plans are huge time sinks, dragging down people who’d rather be productive
  • 4. FEAR “Unacknowledged fear is the source of all project failures.” - Kent Beck
    • Customers fear: They won’t ever see meaningful plan
        • The right to an overall plan : what, when, and at what cost.
        • The right to cancel and get a useful system reflecting investment.
    • Developers fear: They won’t have time to succeed
        • The right to ask for and receive help
        • The right to accept responsibilities instead of being assigned them
  • 5. BALANCE and ITERATIONS Frequently assess where project going: “Ready…Fire…Aim… Aim… Aim…”
    • Estimating is a technical decision
    • Choosing between features is a business decision.
    • Shrink development life cycle to microscopic size
        • A quarter ly turn of ‘business crank’ is a release
        • A three week development cycle is an iteration .
        • An iteration is a fully-tested production-ready system
    • Estimates: Assume you’ll accomplish as much in this iteration as you did in the last iteration.
  • 6. TOO MUCH TO DO “Not only do I have a full plate, I now have a complete dining set.” – a Lab 285
    • COSTS : Adding more people makes a late project later
        • Faster desktops, bigger monitors ( flat panels? ) are motivators
        • Motivated developer in 7 hours outperforms a tired one at 10 hours.
        • Long hours to do -> fatigue -> mistakes -> Long hours to fix
    • QUALITY : Trade tolerable defects for valuable functions
        • Trade-offs are always the Customer’s decision
    • TIME and SCOPE : Planning makes time visible
        • Since hopelessness breeds mistakes, burnout, and failure ...
        • End the project every few weeks
        • By planning so often, nobody pays for plans , they pay for results
  • 7. SCOPING A PROJECT “You can’t put 10 pounds of manure in a 5 pound bag.” – Anyone that tried
    • A typical 24 month project using Agile/XP:
        • Begins with shouting and negotiations
        • Break problem into pieces
        • Estimate each piece
        • Defer less valuable pieces
    • A manager once said, “I know it’s going to be a challenge, but if anyone can do it, you can.”
        • The result was that developers found something else to work on most of the time
  • 8. RELEASES and STORIES Release often ... with enough new functionality to merit a press release
    • Whoops! Infrastructure before delivering functions
        • Common feature of dead and dying projects
        • You spend a lot of time not delivering things
    • Project Tools for repetitive projects useless for XP
        • Dependencies between XP tasks do not figure strongly
        • False Dependencies: Building GUI data entry screens first
    • Customer has responsibility to supply stories
        • Writing stories iterative , few at a time, clear enough to estimate
        • Value: Customer is happier if we do valuable things first
        • Risk: If developers are nervous , everyone should listen.
          • New technology, Task too big, Inflexible design
        • Creep: Let requirements crawl around to find customer’s needs .
  • 9. ITERATION PLANNING Understanding a story is simplest if customer gives short talk about story
    • Regularly Scheduled Planning Meeting:
        • Customer reads out stories for the given iteration
        • Together, White-board the tasks for each story
        • Developers sign up and estimate tasks … up to their velocity
    • With motivated and capabable developers
        • “ Ideal Weeks” are if programmer could dedicate 100% time
        • Velocity = Number of stories completed in an iteration
    • Programmer chooses amount completed last cycle
        • When programmer says, ” I’ll get that done in a day” ... check.
        • Learn to accurately predict than reach for arbitrary measure .
        • Records as weapons? You’ll never get an honest estimate again.
  • 10. TRACKING The only thing you know about a plan … is that things won’t go according to it
    • A key question: “ How many days are left? ”
        • Every dark corner you haven’t tested … is full of bugs
        • “ I’m done coding, but haven’t tested yet”, is meaningless.
        • Customers sadly log developer ‘doneness’ as bugs .
    • Work iteration to iteration, but plan one or two ahead.
        • A danger is never having a ‘ formal release ’
        • Keep long term in mind . We can easily lose strategic vision .
    • Iterations synchronized to rhythms of programming
        • Never slip dates . Set regular cycle . Defer functionality.
        • Rule: No one allowed overtime two weeks in a row.
        • Overtime will rapidly takes its ‘pay’ in some other form .
  • 11. Planning e X treme P rogramming (XP) The GREEN Book - Planning XP The WHITE Book - XP Explained