0
What is the deal with Agile? I mean really?   an overview of "Practices of an Agile Developer"
In  a nutshell....Waterfall VS. Agile <ul><li>Waterfall </li></ul><ul><ul><li>fixed price </li></ul></ul><ul><ul><li>plann...
The Agile Manifesto <ul><li>We value: </li></ul><ul><ul><li>Individuals and interactions over processes and tools </li></u...
The Spirit <ul><ul><li>don't work in isolation </li></ul></ul><ul><ul><li>avoid quick hacks - they'll stay in the codebase...
Feeding Agility <ul><ul><li>Keep up with change </li></ul></ul><ul><ul><ul><li>keeping learning </li></ul></ul></ul><ul><u...
Delivering What Users Want <ul><ul><li>keep users involved in decision making </li></ul></ul><ul><ul><ul><li>don't show th...
Agile Feedback <ul><ul><li>small, continuous adjustment requires constant feedback </li></ul></ul><ul><ul><ul><li>sprint r...
Coding Agile <ul><ul><li>good code does not necessarily mean more classes and or fewer </li></ul></ul><ul><ul><li>code re-...
Bugs <ul><ul><li>report and log all exceptions - even if there is no plan to fix them right away </li></ul></ul><ul><ul><l...
Collaboration <ul><li>Client Facing: </li></ul><ul><ul><li>back log tasks </li></ul></ul><ul><ul><li>keep a project glossa...
Wrapup <ul><ul><li>better collaboration systems </li></ul></ul><ul><ul><ul><li>auto genererated status reports </li></ul><...
Upcoming SlideShare
Loading in...5
×

Agile Development Brown Bag Lunches Slides

1,837

Published on

Published in: Technology
1 Comment
2 Likes
Statistics
Notes
No Downloads
Views
Total Views
1,837
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
14
Comments
1
Likes
2
Embeds 0
No embeds

No notes for slide

Transcript of "Agile Development Brown Bag Lunches Slides"

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

    Clipping is a handy way to collect important slides you want to go back to later.

×