Your SlideShare is downloading. ×
0
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Agile in Action - Agile Overview for Developers
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Agile in Action - Agile Overview for Developers

396

Published on

Excerpt from a presentation I gave to the University of Alabama Association for Computing Machinery in November 2010. I wanted to give the students a practical overview of Agile and Scrum and give …

Excerpt from a presentation I gave to the University of Alabama Association for Computing Machinery in November 2010. I wanted to give the students a practical overview of Agile and Scrum and give them some perspective on what Agile means for developers.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
396
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Thanks for the invite and hospitality…
    Thanks for showing up…
  • Our highest priority is to satisfy the customerthrough early and continuous deliveryof valuable software.
    Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
    Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
    Business people and developers must work together daily throughout the project.
    Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
    The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
    Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
    Continuous attention to technical excellence and good design enhances agility.
    Simplicity--the art of maximizing the amount of work not done--is essential.
    The best architectures, requirements, and designs emerge from self-organizing teams.
    At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
  • Working software is the primary measure of progress.
    Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
    Continuous attention to technical excellence and good design enhances agility.
    Simplicity--the art of maximizing the amount of work not done--is essential.
    The best architectures, requirements, and designs emerge from self-organizing teams.
    At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
  • Break things into smaller pieces
    It doesn’t mean the end project gets smaller overall, just represented as smaller pieces
  • Timebox – fixed length iterations
    Same length every single time – team gets into a rhythm
    Change the scope, not the date
  • Done may contain lots of things…
    What if you need to be compliant? Need documentation?
    What if you have corporate architectural standards? Need to comply.
    What about security needs? Need to meet them.
    How do you define done for that particular feature / user story?
    How do you know when something has been tested enough?
    Do you require peer code reviews?
  • Just enough…just in time – may feel uncomfortable…
  • Get to done, and I mean done (not 80% done)
    First, need to define success and any applicable constraints, then get to success – RINSE.REPEAT
  • Explain Scrum
    First – Scrum is not simply a daily meeting
    Talk about sprint demo / sprint review and sprint planning
  • User Story
    As a software developer, I want to buy a book so that I can learn how to create applications with Ruby on Rails.
  • Scrum team commits to a set of features from the product backlog
    Business commits to leave the priorities alone during the sprint to allow the team to focus
  • Better yet – how do I know what to build?
    User Story
    As a software developer, I want to buy a book so that I can learn how to create applications with Ruby on Rails.
    Is that enough? Not likely. I need a mini-waterfall to figure this out, right? Wrong.
    We don’t need a 5-step process to develop working software in two weeks.
    We still need the content of these steps, mind you, but not necessarily so rigidly.
    Even within the context of a sprint, we need to get to done over and over again quickly.
    No “Design Phase” then “Construction Phase”…
  • Better yet – how do I know what to build?
    User Story
    As a software developer, I want to buy a book so that I can learn how to create applications with Ruby on Rails.
    Is that enough? Not likely. I need a mini-waterfall to figure this out, right? Wrong.
    We don’t need a 5-step process to develop working software in two weeks.
    We still need the content of these steps, mind you, but not necessarily so rigidly.
    Even within the context of a sprint, we need to get to done over and over again quickly.
    No “Design Phase” then “Construction Phase”…
  • Better yet – how do I know what to build?
    User Story
    As a software developer, I want to buy a book so that I can learn how to create applications with Ruby on Rails.
    Is that enough? Not likely. I need a mini-waterfall to figure this out, right? Wrong.
    We don’t need a 5-step process to develop working software in two weeks.
    We still need the content of these steps, mind you, but not necessarily so rigidly.
    Even within the context of a sprint, we need to get to done over and over again quickly.
    No “Design Phase” then “Construction Phase”…
  • Simple math – talk about relative estimation?
  • Simple math – talk about relative estimation?
  • Simple math
    Again, this is done at a high level – the closer you get to the release date, the more accurate you are…
  • AGILE IN GENERAL IS NOT PRESCRIPTIVE – BUT HERE ARE GOOD PRACTICES NECESSARY FOR GOOD AGILITY
    Meaning you have to do things outside of your role – no more – that’s not my problem
  • AGILE IN GENERAL IS NOT PRESCRIPTIVE – BUT HERE ARE GOOD PRACTICES NECESSARY FOR GOOD AGILITY
    Meaning you have to do things outside of your role – no more – that’s not my problem
  • AGILE IN GENERAL IS NOT PRESCRIPTIVE – BUT HERE ARE GOOD PRACTICES NECESSARY FOR GOOD AGILITY
    Meaning you have to do things outside of your role – no more – that’s not my problem
  • AGILE IN GENERAL IS NOT PRESCRIPTIVE – BUT HERE ARE GOOD PRACTICES NECESSARY FOR GOOD AGILITY
    Meaning you have to do things outside of your role – no more – that’s not my problem
  • AGILE IN GENERAL IS NOT PRESCRIPTIVE – BUT HERE ARE GOOD PRACTICES NECESSARY FOR GOOD AGILITY
    Meaning you have to do things outside of your role – no more – that’s not my problem
  • AGILE IN GENERAL IS NOT PRESCRIPTIVE – BUT HERE ARE GOOD PRACTICES NECESSARY FOR GOOD AGILITY
    Meaning you have to do things outside of your role – no more – that’s not my problem
  • Believe it or not, you have a choice as to whether or not to practice these things…
    Your employer can’t tell you not to practice Red, Green, Refactor
  • Believe it or not, you have a choice as to whether or not to practice these things…
    Your employer can’t tell you not to practice Red, Green, Refactor
  • Believe it or not, you have a choice as to whether or not to practice these things…
    Your employer can’t tell you not to practice Red, Green, Refactor
  • Believe it or not, you have a choice as to whether or not to practice these things…
    Your employer can’t tell you not to practice Red, Green, Refactor
  • Believe it or not, you have a choice as to whether or not to practice these things…
    Your employer can’t tell you not to practice Red, Green, Refactor
  • Thanks for the invite and hospitality…
    Thanks for showing up…
  • Transcript

    • 1. Matt Cowell VP of Software Engineering, CSO agile in action
    • 2. about me…
    • 3. the plan… • The Agile Manifesto – Magic? • Agile Theory • What does agile mean for developers? • Agile @ Daxko
    • 4. the agile manifesto… Individuals & Interactions --over-- Process and Tools Working Software --over-- Comprehensive Documentation Customer Collaboration --over-- Contract Negotiation Responding to Change --over-- Following a Plan
    • 5. the magic part… • Forgo processes / tools • Make sure individuals interact • Don’t bother with documentation • No more contracts • No sense trying to create / follow a plan, just deal with change
    • 6. the magic part… • Forgo processes / tools • Make sure individuals interact • Don’t bother with documentation • No more contracts • No sense trying to create / follow a plan, just deal with change Success!
    • 7. the agile manifesto… Individuals & Interactions --over-- Process and Tools Working Software --over-- Comprehensive Documentation Customer Collaboration --over-- Contract Negotiation Responding to Change --over-- Following a Plan
    • 8. the manifesto principles… • Satisfy the customer early and continuously • Harness change for competitive advantage • Deliver working software frequently • Business people and devs must work together • Build projects around motivated individuals • Conveying info face-to-face is most effective
    • 9. the manifesto principles… • Progress = working software • Agile promotes sustainable dev (constant pace) • Technical excellence / good design enhances agility • Maximize the work not done • The best work emerges from self-organization • Team reflects regularly and tunes accordingly
    • 10. the manifesto principles… • Progress = working software • Agile promotes sustainable dev (constant pace) • Technical excellence / good design enhances agility • Maximize the work not done • The best work emerges from self-organization • Team reflects regularly and tunes accordingly
    • 11. sounds cool, but how?
    • 12. Large vs. small pieces…
    • 13. Fix time…
    • 14. define done…
    • 15. Figure out what’s needed, when it is needed… Just enough…just in time
    • 16. drive to done…
    • 17. Scrum
    • 18. Scrum concepts… • User Story • Product Backlog • Sprint Backlog • Release Burndown / Sprint Burndown • Sprint Planning • Daily Scrum • Sprint Demo / Review • Sprint Retrospective
    • 19. sprint commitment Complete features Leave priorities alone
    • 20. when do I get the reqs?
    • 21. when do I get the reqs?
    • 22. Source: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986. User stories are meant to seed conversation… when do I get the reqs?
    • 23. estimation… Source: Rally How tall is the Sears Tower?
    • 24. estimation… Source: Rally How tall is the Sears Tower? Info: The Empire State Building is 1250 ft
    • 25. long term planning… • Size the product backlog • Measure velocity of the team size of backlog ÷ team velocity # sprints left Source: Rally
    • 26. What about developers? 1) You are now part of a cross functional team
    • 27. What about developers? 1) You are now part of a cross functional team 2) Attention to detail – get to 100% (i.e. DONE!)
    • 28. What about developers? 1) You are now part of a cross functional team 2) Attention to detail – get to 100% (i.e. DONE!) 3) Don’t just ask the question; answer the question
    • 29. What about developers? 1) You are now part of a cross functional team 2) Attention to detail – get to 100% (i.e. DONE!) 3) Don’t just ask the question; answer the question 4) Communicate with team…
    • 30. What about developers? 1) You are now part of a cross functional team 2) Attention to detail – get to 100% (i.e. DONE!) 3) Don’t just ask the question; answer the question 4) Communicate with team… 5) Sustain your effort – take pride in meeting your commitments
    • 31. What about developers? 1) You are now part of a cross functional team 2) Attention to detail – get to 100% (i.e. DONE!) 3) Don’t just ask the question; answer the question 4) Communicate with team… 5) Sustain your effort – take pride in meeting your commitments 6) Learn how to work in vertical slices
    • 32. What about developers? 7) Focus on unit testing. QA is not there to find what you were too careless to check for…
    • 33. What about developers? 7) Focus on unit testing. QA is not there to find what you were too careless to check for… 8) Learn patterns…use them
    • 34. What about developers? 7) Focus on unit testing. QA is not there to find what you were too careless to check for… 8) Learn patterns…use them 9) Refactor early and often
    • 35. What about developers? 7) Focus on unit testing. QA is not there to find what you were too careless to check for… 8) Learn patterns…use them 9) Refactor early and often 10)Practice test driven development
    • 36. What about developers? 7) Focus on unit testing. QA is not there to find what you were too careless to check for… 8) Learn patterns…use them 9) Refactor early and often 10)Practice test driven development 11)Implement continuous integration
    • 37. Matt Cowell VP of Software Engineering, CSO

    ×