Your SlideShare is downloading. ×
Introduction To Agile And Scrum
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

Introduction To Agile And Scrum

7,607
views

Published on

Introduction to Agile development with Scrum

Introduction to Agile development with Scrum


5 Comments
61 Likes
Statistics
Notes
No Downloads
Views
Total Views
7,607
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
5
Likes
61
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
  • My name is Robert Dempsey
  • I’m the CEO of ADS, a web development shop in Orlando
  • Simple project management for agile teams
  • Find me on Twitter
  • The Old Way
    Requirements -> Design -> Implement -> Verify -> Maintain
    Waterfall
  • The Old Way
    Requirements -> Design -> Implement -> Verify -> Maintain
    Waterfall
  • The Old Way
    Requirements -> Design -> Implement -> Verify -> Maintain
    Waterfall
  • The Old Way
    Requirements -> Design -> Implement -> Verify -> Maintain
    Waterfall
  • The Old Way
    Requirements -> Design -> Implement -> Verify -> Maintain
    Waterfall
  • The Old Way
    Requirements -> Design -> Implement -> Verify -> Maintain
    Waterfall
  • Pros
    Find bugs early in the process
    Correct requirements now, less problems later (in theory)
    Emphasis on documentation - developers hate doing this
    Simple and disciplined
    Good for stable projects
  • Cons
    Each step is not mutually exclusive
    Developers are usually (not) clairvoyant
    Documentation overhead
    Rigid and inflexible
    Stable project?!
  • Reality
    Development phases overlap
    Software is emergent - the farther along we go the more we know
    “Done” is a moving target
    Flexibility is required - business requirements and the environment changes
    Collaboration is essential
  • Lays out the philosophy for agile development
    Individuals and interactions over process and tools
    Working software over comprehensive documentation
    Customer collaboration over contract negotiation
    Responding to change over following a plan
  • Agile Myths
    Lack of discipline - “self-managing” = do whatever you want, when you want
    Lack of visibility
    “That won’t work here”
  • What is Agile?
    Group of philosophies and practices that provides the ablility to handle changing requirements
    Iterative development
    A lot of collaboration between business and developer
    Have self-organizing and self-managing teams
    Stressing leadership over management

    Utilizing these and a set of practices, a team gains the ability to continuously adapt.
  • Agile Methods
    Extreme Programming (XP)
    Test Driven Development (TDD)
    Feature Driven Development (FDD)
    Behavior Driven Development (BDD)
    Scrum
  • Scrum!
  • A framework for developing complex products and systems
    Grounded in empirical process control theory
    Transparency
    Inspection
    Adaptation
    Three inspect and adapt points
    Sprint Review and Planning meetings
    Daily Scrum
    The Retrospective
  • The Scrum Team
    Product Owner
    ScrumMaster
    The Team
    Called pigs: they have their bacon on the line
  • Involved, but aren’t committed
    Users, stakeholders (customers, vendors), managers, and business units
  • The driving force behind the process
    Helps the team and organization adopt and use Scrum
    A leader, not a manager
    Roles they play: coach, teacher, and supporter
  • Manages and controls the product backlog
    Responsible for the value of the work done
    Keeps the product backlog in priority order, visible to everyone
    A single person, not a committee
    Must have authority, and the respect of others to succeed
    Single point of contact for the team
  • The ones turning product backlog items into increments of potentially shippable functionality
    Cross-functional: everyone that needs to be on the team to make the stories happen
    Self-organized: everyone contributes
    No job descriptions, no titles, no exceptions
    Sink or swim as a team
    Optimal team size: 7, +- 2
    Team composition may change at the end of a sprint; be careful in doing so
  • Scrum Overview
    Product backlog -> release planning -> sprint (daily scrum) ->
    increment -> sprint review -> sprint retrospective
  • Scrum Overview
    Product backlog -> release planning -> sprint (daily scrum) ->
    increment -> sprint review -> sprint retrospective
  • Scrum Overview
    Product backlog -> release planning -> sprint (daily scrum) ->
    increment -> sprint review -> sprint retrospective
  • Scrum Overview
    Product backlog -> release planning -> sprint (daily scrum) ->
    increment -> sprint review -> sprint retrospective
  • Scrum Overview
    Product backlog -> release planning -> sprint (daily scrum) ->
    increment -> sprint review -> sprint retrospective
  • Scrum Overview
    Product backlog -> release planning -> sprint (daily scrum) ->
    increment -> sprint review -> sprint retrospective
  • Scrum Overview
    Product backlog -> release planning -> sprint (daily scrum) ->
    increment -> sprint review -> sprint retrospective
  • Product Backlog
    Managed by the Product Owner
    Evolves along with the product and the environment
    Master list of all functionality desired in the product
    Includes all features, functions, technologies, enhancements, and bug fixes
    Requirements are typically written in user story format
  • User Stories
    How we write our requirements
    From the user perspective
  • User Stories
  • Product Backlog
    Sorted in order of priority
    Requirements never stop changing
    Minimize work: add fine-grained detail to the highest priority items (for the next few sprints)
  • Release Planning
    Purpose: establish a plan and goals that everyone can understand and communicate
    Establishes
    The goals of the release
    The highest priority Product Backlog items
    The major risks
    Overall features and functionality that the release will contain
    Probable delivery date and cost if nothing changes
    Composed of Sprints that deliver increments of the product, starting with the most valuable and most risky
    Once enough increments are completed, release!
    Most planning is done at the beginning of a release
  • Sprint
    Sprint: 1-4 week block of time; all sprints are the same length
    Protected by the ScrumMaster - no changing once it's started
    Sprint Planning Meeting
    When the iteration is planned
    Max 8 hours for a one-month sprint, or 5% of the total Sprint length
    Two parts
  • Sprint Planning Meeting: Part 1 - What
    4 hours
    The Product Owner and Team mutually determine what functionality will go into the Sprint
    Considers the Product Backlog, the latest increment, team capacity, and past performance of the team
    Only the team can say what they can accomplish in the upcoming Sprint
    Sprint Goal: the purpose statement of the Sprint, the "why"
  • Sprint Planning Meeting: Part 2 - How
    4 hours
    Team determines how it will deliver a "done" increment
    Identification of tasks - where the details are
    A single task should take no more than one day
    Sprint backlog - the list of tasks
    Team self-organizes to assign and do the work
    Negotiation between the Team and the Product Owner happens here
  • Sprint Backlog
    All of the tasks required to turn Product Backlog items into "done" increments
    Break each user story down so that changes in progress can be understood in the Daily Scrum
    Modified during the Sprint as-needed
    Tasks are added and removed if unnecessary
    Tasks are estimated in hours, by the Team
    Only the Team can change the Sprint Backlog during a Sprint
    Highly-visible and real-time
  • Sprint Backlog
    All of the tasks required to turn Product Backlog items into "done" increments
    Break each user story down so that changes in progress can be understood in the Daily Scrum
    Modified during the Sprint as-needed
    Tasks are added and removed if unnecessary
    Tasks are estimated in hours, by the Team
    Only the Team can change the Sprint Backlog during a Sprint
    Highly-visible and real-time
  • Sprint Backlog
    All of the tasks required to turn Product Backlog items into "done" increments
    Break each user story down so that changes in progress can be understood in the Daily Scrum
    Modified during the Sprint as-needed
    Tasks are added and removed if unnecessary
    Tasks are estimated in hours, by the Team
    Only the Team can change the Sprint Backlog during a Sprint
    Highly-visible and real-time
  • Sprint Backlog
    All of the tasks required to turn Product Backlog items into "done" increments
    Break each user story down so that changes in progress can be understood in the Daily Scrum
    Modified during the Sprint as-needed
    Tasks are added and removed if unnecessary
    Tasks are estimated in hours, by the Team
    Only the Team can change the Sprint Backlog during a Sprint
    Highly-visible and real-time
  • Sprint Backlog
    All of the tasks required to turn Product Backlog items into "done" increments
    Break each user story down so that changes in progress can be understood in the Daily Scrum
    Modified during the Sprint as-needed
    Tasks are added and removed if unnecessary
    Tasks are estimated in hours, by the Team
    Only the Team can change the Sprint Backlog during a Sprint
    Highly-visible and real-time
  • Sprint Backlog
    All of the tasks required to turn Product Backlog items into "done" increments
    Break each user story down so that changes in progress can be understood in the Daily Scrum
    Modified during the Sprint as-needed
    Tasks are added and removed if unnecessary
    Tasks are estimated in hours, by the Team
    Only the Team can change the Sprint Backlog during a Sprint
    Highly-visible and real-time
  • Sprint Burndown
    Graph showing the amount of Sprint Backlog work remaining
    Variable of interest: work remaining and date
  • Daily Scrum
    15-minute standup
    The Team is responsible for having the meeting
    The ScrumMaster ensures it happens, and that it stays short
    3 questions
    Goals
    Improve communication
    Eliminate other meetings
    Identify and remove impediments
    Highlight and promote quick decision making
    Improve everyone's knowledge
  • Daily Scrum
    15-minute standup
    The Team is responsible for having the meeting
    The ScrumMaster ensures it happens, and that it stays short
    3 questions
    Goals
    Improve communication
    Eliminate other meetings
    Identify and remove impediments
    Highlight and promote quick decision making
    Improve everyone's knowledge
  • Increment
    Potentially shippable software: the Product Owner may decide to put it into production
    Bug free, tested, clean code
    Must work with everything already in place
    This is where regression testing and continuous integration servers come in
  • Sprint Review
    4-hour meeting for a one-month Sprint, or 5% of the total length of the sprint
    The Scrum Team and stakeholders collaborate on what was done
    Based on the feedback and changes to the Product Backlog during the Sprint, they collaborate about what to do next
    Informal meeting intended to foster collaboration
    Product Owner - tells what has/hasn't been done
    Team - discusses what went well, what problems they ran into, and what they did to resolve them
    Team - demos what's been done, and answers questions
    Product Owner - discusses the Product Backlog as it stands
    Group - collaborates on what to do next
  • Release Burndown
    Graph showing the Product Backlog estimated effort remaining across time
    Product Backlog estimates are reviewed and revised
    Keep in mind: the Team is responsible for all estimates
  • Sprint Retrospective
    Held between the Sprint Review and the next Sprint Planning meeting
    3 hours max
    ScrumMaster encourages the Team to revise their development process to become more effective
    Purpose: inspect how the last Sprint went in regards to people, relationships, processes and tools
    Identify and prioritize the major items that went well, and those that didn't - discuss how they can be done better
    Discuss: team composition, meeting arrangements, tools, definition of "done"
    Result: actionable improvement measures
  • Rinse and Repeat
    The process begins anew
  • Scrum Overview
    Product backlog -> release planning -> sprint (daily scrum) ->
    increment -> sprint review -> sprint retrospective
  • Scrum Overview
    Product backlog -> release planning -> sprint (daily scrum) ->
    increment -> sprint review -> sprint retrospective
  • Scrum Overview
    Product backlog -> release planning -> sprint (daily scrum) ->
    increment -> sprint review -> sprint retrospective
  • Scrum Overview
    Product backlog -> release planning -> sprint (daily scrum) ->
    increment -> sprint review -> sprint retrospective
  • Scrum Overview
    Product backlog -> release planning -> sprint (daily scrum) ->
    increment -> sprint review -> sprint retrospective
  • Scrum Overview
    Product backlog -> release planning -> sprint (daily scrum) ->
    increment -> sprint review -> sprint retrospective
  • Scrum Overview
    Product backlog -> release planning -> sprint (daily scrum) ->
    increment -> sprint review -> sprint retrospective
  • Results of Agile Adoption - Agile Survey (2/08)
    642 respondents
    82% increased productivity
  • Results of Agile Adoption - Agile Survey (2/08)
    77% increased quality
  • Results of Agile Adoption - Agile Survey (2/08)
    78% increased stakeholder satisfaction
  • Results of Agile Adoption - Agile Survey (2/08)
    37% decreased costs
  • Compelling arguments for at least giving it a try
  • Compelling arguments for at least giving it a try
  • Compelling arguments for at least giving it a try
  • Compelling arguments for at least giving it a try
  • Additional Information
    Scrum Lunch and Learn
  • Additional Information
    Agile Development with Scrum
  • Transcript

    • 1. Hello
    • 2. Robert Dempsey
    • 3. adsdevshop.com
    • 4. scrumd.com
    • 5. rdempsey
    • 6. Introduction to Agile and Scrum
    • 7. Requirements
    • 8. Requirements Design
    • 9. Requirements Design Implement
    • 10. Requirements Design Implement Verify
    • 11. Requirements Design Implement Verify Maintain
    • 12. Requirements Design Implement Verify Maintain
    • 13. Thine Agile Manifesto
    • 14. http://www.scrum.com/scrum/rugby/image/95279.html
    • 15. ScrumMaster
    • 16. Product Owner
    • 17. The Team
    • 18. 24H 2W
    • 19. 24H 2W
    • 20. 24H 2W
    • 21. 24H 2W
    • 22. 24H 2W
    • 23. As a role I want something so that I get a benefit
    • 24. As a User I want to log in so that I can use the site
    • 25. 2 Weeks
    • 26. Part 1: What
    • 27. Part 2: How
    • 28. User Story User Story User Story
    • 29. Task User Story Task Task User Story User Story
    • 30. Task User Story Task Task Task User Story Task Task User Story
    • 31. Task User Story Task Task Task User Story Task Task Task User Story Task
    • 32. 24 Hours 2 Weeks
    • 33. 24 Hours 2 Weeks
    • 34. 24H 2W
    • 35. 24H 2W
    • 36. 24H 2W
    • 37. 24H 2W
    • 38. 24H 2W
    • 39. 82%
    • 40. Increased productivity
    • 41. 77%
    • 42. Increased quality
    • 43. 78%
    • 44. Increased stakeholder satisfaction
    • 45. 37%
    • 46. Decreased costs
    • 47. Increased productivity
    • 48. Increased productivity Increased quality
    • 49. Increased productivity Increased quality Increased satisfaction
    • 50. Increased productivity Increased quality Increased satisfaction Decreased costs
    • 51. http://www.meetup.com/scrum-lunch-and-learn/
    • 52. http://www.agiledevelopmentwithscrum.com/
    • 53. Letʼs Chat