Your SlideShare is downloading. ×
Agile Development Brown Bag Lunches Slides
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Agile Development Brown Bag Lunches Slides


Published on

Published in: Technology

1 Comment
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


  • 1. What is the deal with Agile? I mean really?   an overview of "Practices of an Agile Developer"
  • 2. In  a nutshell....Waterfall VS. Agile
    • Waterfall
      • fixed price
      • planning up front
        • features documented with great detail
      • Linear process - planning is first testing is at the end
    • Agile
      • price TDB
      • limited planning up front
        • goals and problems documented over solutions
      • Continuous, iterative process
  • 3. The Agile Manifesto
    • We 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
  • 4. The Spirit
      • don't work in isolation
      • avoid quick hacks - they'll stay in the codebase forever
        • understand the problem you are trying to solve
        • fix the problem, not just the symptom
      • blame doesn't fix anything
      • criticize ideas, not people
      • negativity kills innovation
      • simplify - if it's too hard for one person to understand, it's probably not maintainable
      • use timeboxing (by lunch, end of day, etc) to keep things moving forward (software projects are like sharks, if they don't keep moving, they'll die)
  • 5. Feeding Agility
      • Keep up with change
        • keeping learning
        • follow blogs for the latest "buzz"
        • User groups and conferences
        • READ!
      • Share what you know with your team
      • Know when to unlearn
        • in this business, if you still doing something the same way you did it 3-4 years's probably time for a change
      • Question until you understand (get past the symptoms, ask  "why?")
        • think of all the stuff we could NOT build if we just asked "why?"
  • 6. Delivering What Users Want
      • keep users involved in decision making
        • don't show them when it's too late to change course
        • present options early
      •   early designs should be high level, not too exact - only as detailed as necessary to implement (think Lewis and Clark crossing the country)
      • justify technology use - don't build it when you can download it
      • always keep the application in a state that is ready to deploy, check in your work early and often (use CI)
      • Frequent Demos
      • Good software today is much better than Superior Software sometime next year - get something usable out ASAP
  • 7. Agile Feedback
      • small, continuous adjustment requires constant feedback
        • sprint reviews (every 1, 2 or more weeks)
        • release notes
      • build as early as possible (automate)
      • improve constantly
      • customers are the domain experts
      • scope can change more easily (SOWs can be issued to accomodate in our case)
  • 8. Coding Agile
      • good code does not necessarily mean more classes and or fewer
      • code re-use is key, code duplication should be in check
      • Good programming can be simple to read, and well optimized - you can do both! refactor!
        • everytime you re-use something, make improvments
        • don't comment things out, remove them
        • today's lazy hack is tomorrow's nightmare, don't give in to will cost more in the long run, quick fixes are ticking time bombs
  • 9. Bugs
      • report and log all exceptions - even if there is no plan to fix them right away
      • provide useful messages to the client in the software for any event that occurs, whether it's an exception or a success
      • for hard to find bugs in huge codebases, isolate the bug into a test or prototype that is more managable
      • Blame does not fix bugs
  • 10. Collaboration
    • Client Facing:
      • back log tasks
      • keep a project glossary
      • email
      • status reporting (client facing, and SCRUMS)
      • release notes with demos
    • Internal:
      • improving team skills is just as important as getting projects out the door
        • improve things with each go round, not just the quality of the deliverable, but better your skills (old code should dissapear over time)
      • designers and architects must work on the deliverable
      • tools (meetings, fogbugz, "the list")
  • 11. Wrapup
      • better collaboration systems
        • auto genererated status reports
        • auto generated release notes
        • email tracking
      • weekly or bi-weekly reviews with client
        • gather client feedback
    There no need to fix everything at once. Like agile itself, implementation should be incremental.   What we can take on now:
      • Continuous Integration
      • Source Control Change
        • eventually integrate with collab system
    • Results:
      • fewer surprises, less overbuilding
      • more SOWs
      • better quality
      • better software
      • more profit (fewer trainwrecks)
      • happier clients