Agile & SCRUM
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Agile & SCRUM

on

  • 8,317 views

 

Statistics

Views

Total Views
8,317
Views on SlideShare
8,310
Embed Views
7

Actions

Likes
10
Downloads
837
Comments
0

1 Embed 7

http://searchutil01 7

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Agile & SCRUM Presentation Transcript

  • 1. Agile & SCRUM
    Created by ejlp12@gmail.com, 6 Nov 2009
    Why, What & How.
    Presented to project team members. Pictures are copied from Internet and not my copyright. Some slides are also taken from Internet.
  • 2. AGILE Methodology
  • 3. Why Agile Software Development…?
  • 4. What is Agile?
    The agile process is based on the empirical approach, accepting the complexity of the problem and addressing it through frequent inspection and constant adaptation
    – Ken Schwaber
  • 5. Agile, basic
    Adaptive and responsive to change
    Increase productivity and identifying and prioritizing high value features
    Positive emergent culture that allows for continuous improvement
    Avoid the pitfalls of waterfall
  • 6. More on characteristics
    Empirical (relies on observation and experience)
    Lightweight
    Adaptive
    Fast – but never hurried
    Exposes wastefulness
    Customer-centric
    Pushes decision making to lower levels
    Fosters trust, honesty and courage
    Encourages self-organization
  • 7. Agile manifesto
    Individuals & Interactions over Process & Tools
    Working Software over Comprehensive Documents
    Customer Collaboration over Contract Negotiation
    Responding to Change over Following a Plan
    Things on the right are important.
    Things on the left are more important!!
  • 8. Agile methodologies
    Feature Driven Development (FDD)
    Extreme programming (XP)
    Crystal
    Lean Development
    SCRUM
    Rational Unified Process (RUP)
    Adaptive Software Development (ASD)
    Dynamic System Development Method (DSDM)
  • 9. Agile SW development practices
    Essential Practices
    Regular refactoring (many times daily)
    This produces well-componentized designs, clear APIs and clean code without duplications
    Frequent check-ins (many times daily)
    Unit Testing
    Leading to Test Driven Development (TDD)
    Continuous Build and Integration
    Running automated tests on each build
    Just-in-time code reviews (e.g. pair programming)
    Example methodologies: XP, Agile Modeling
  • 10. Agile SW Testing
    Early involvement
    An Agile project begins when testers convert high-level requirements into testable specifications.
    Work as part of the development team
    The testers work with the developers to pick unit test and acceptance test frameworks, and to test the software in parallel with development. This requires a shift in thinking.
    Automate everything
    (wherever possible)
    Test early, test often
    Never leave the testing until the end
  • 11. The Agile Customer
    “Customer’ is a role, not a person
    Also known as Product Manager, Product Owner
    Proxy for the entire customer group
    Responsible for the Release Plan
    Responsible for managing the Product Backlog
    Determines business value & priority on a regular basis
    Provides information to development team for estimation purposes
    Works with testers to produce clear, testable user stories for each iteration
    Inspects software regularly (e.g. runs acceptance tests) and provides feedback to the development team
  • 12. SCRUM
  • 13.
  • 14. SCRUM is…
    Scrum is an agile, lightweight processthat can be used to manage and control software and product development using iterative, incremental practices
    Wrapping existing engineering practices, including Extreme Programming and RUP, Scrum generates the benefits of agile development with the advantages of a simple implementation
    It is adaptive, quick, self-organizing and have few rests
    ..process framework, not methodology
  • 15. Why SCRUM
    It is HOT!
    It’s work and simple.
    More practical (practical process model).
    A rule of thumb or best practices for process inspection and continue adaptation.
  • 16. SCRUM Characteristics
    Self-organizing teams
    Product progresses in a series of month-long “sprints”
    Requirements are captured in a list of “product backlog”
    No specific engineering practices prescribed
    SCRUM doesn’t tell how to develop Software.
    Find XP, TDD, etc
  • 17. Roles and Responsibilities
    Product Owner
    • Defines the features of the product, decides on release date and content
    • 18. Is responsible for the profitability of the product (ROI)
    • 19. Prioritizes features according to market value
    • 20. Can change features and priority every 30 days
    • 21. Accepts or rejects work results
    Scrum Master
    • Ensures that the team is fully functional and productive
    • 22. Enables close cooperation across all roles and functions and removes barriers
    • 23. Shields the team from external interferences
    • 24. Ensures that the process is followed. Invites to daily scrum, iteration review and planning meetings
  • Team
    • Cross-functional, seven plus/minus two members
    • 25. Selects the iteration goal and specifies work results
    • 26. Has the right to do everything within the boundaries of the project guidelines to reach the iteration goal
    • 27. Organizes itself and its work
    • 28. Demos work results to the Product Owner
  • Key Artifacts
    Product backlog
    • List of requirements & issues
    • 29. Owned by Product Owner
    • 30. Anybody can add to it
    • 31. Only Product Owner prioritizes
    Sprint Goal
    • A short “theme” for the sprint, typically one line summary:
    • 32. For example, “Make the application run on Oracle in addition to SQL Server”
    • 33. Declared by Product Owner
    • 34. Accepted by team
  • From Sprint Goal to Sprint Backlog …
    • Scrum team takes the Sprint Goal and decides what tasks are necessary
    • 35. Team self organizes around how they’ll meet the Sprint Goal
    • 36. Manager doesn’t assign tasks to individuals
    • 37. Managers don’t make decisions for the team
    • 38. Sprint Backlog is created
    Sprint backlog
    • List of tasks
    • 39. Owned by team
    • 40. Only team modifies it
    Blocks list
    • List of blocks & unmade decisions
    • 41. Owned by Scrum Master
    • 42. Updated daily
  • Product Backlog
  • 43. Sprint Backlog
  • 44. Sprint Backlog (after 5th days)
  • 45. Key Meetings
    Sprint Planning Meeting
    • Hosted by Scrum Master; ½-1 day
    • 46. In: Product Backlog, existing product, business & technology conditions
    • 47. Select highest priority items in Product Backlog; declare Sprint Goal
    • 48. Team turns selected items into Sprint Backlog
    • 49. Output Sprint Goal, Sprint Backlog
  • Sprint Planning Meeting
    Product Owner
    Scrum Team
    Management
    Customers
    Product Backlog
    Sprint Planning
    Meeting
    Team Capabilities
    Sprint Goal
    Business Conditions
    Sprint Backlog
    Technology
    Current Product
  • 50. Key Meetings (Cont’d)
    Daily Scrum
    • Hosted by Scrum Master
    • 51. 15 – 30 minutes stand-up meeting
    • 52. Attended by all: pigs (scrum team) and chickens (others), but only pigs can talk
    • 53. Same time every day; three questions:
    • 54. What did you do yesterday?
    • 55. What will you do today?
    • 56. What obstacles are in your way?
    • 57. Team updates Sprint Backlog; Scrum Master updates Blocks List
    The team should reflect on how to make them most effective.
    Sit or stand, up to you!
  • 58. SCRUM Process
    Burndown Chart
    Daily Scrum
    Meeting
    24 hours
    Sprint
    Backlog tasks
    expanded
    by team
    30days
    Sprint Backlog
    Potentially Shippable
    Product Increment
    Product Backlog
    As prioritized by Product Owner
  • 59. Key Meetings (cont’d)
    Sprint Review Meeting
    Hosted by Scrum Master, attended by
    Customers
    Management
    Product Owner
    Team
    Team presents what it accomplished during the sprint
    Team demos Increment
    2-hour
    Hold retrospective
    Announce next Sprint Planning Meeting
  • 60. Tools: Burn-down chart
    For monitoring progress during a sprint.
    Remaining work is plotted on the Y axis,
    Time proceeds along the X axis.
    As tasks are completed, the line slopes down.
    Burndown Chart…the velocity of turning requirements into potentially shippable increments of functionality.
  • 61. Burndown chart
  • 62. Scrum of Scrum
  • 63. Summary
    Roles :
    Product Owner, ScrumMaster, Team
    Artifacts :
    Product Backlog, Sprint Backlog, Block List and Burndown Chart
    Ceremonies :
    Sprint Planning, Sprint Review, Sprint Retrospective, & Daily Scrum Meeting
  • 64. Concept & Process (PM & SM)
    • Scrum Masters say
    • 65. Sprint
    • 66. Sprint Backlog
    • 67. Task Breakdown
    • 68. Velocity
    • 69. Burndown Chart
    • 70. Project Managers say
    • 71. Schedule
    • 72. Scope
    • 73. Work Breakdown Structure
    • 74. Productivity
    • 75. Estimate to Complete
    • 76. Scrum Masters say
    • 77. Define Backlog, Plan Sprint
    • 78. Develop and Test
    • 79. Move Stickies, have Daily Scrums
    • 80. Demo, Release, have Retrospective
    • 81. Project Managers say
    • 82. Plan
    • 83. Execute
    • 84. Monitor & Control
    • 85. Close
  • Risks & Challenges
    Educating the team – Dev, QA, Business
    Estimations to get work ‘done’ – not just engineering
    Changing the mindset of all stakeholders – PM, team, management, client and users
    Reduced importance to signoffs and approvals, increased value to collaboration and transparency
    Either budget or scope should be flexible
  • 86. SCRUM IN MY PROJECT
  • 87. Case study: Our project
    We haven’t done a SCRUM yet
    We planning it
    • We need to adapt not adopt
    • 88. No “big bang” adoption
    Start by a simple but working, NOT complete but not working
  • 89. The Goal is Success
    Success factor as seen by customer
    On time
    No bugs, right features, good performance
    Successful deployment/release
    Success factor as seen by my employer
    On time to get money
    Maximum revenue
    The client is happy
  • 90. The Challenges are…
    It’s kind like SCM rather than PM
    Developer tends to
    Hard to estimate working effort (time)
    Don’t want to commit to timeline
    Complaining
    Our work culture:
    I only doing as you requested
    I don’t care about documentation
    As long as it is run (passed the test), it’s done
    Working time is not effective
    The CR is not iterative as seen by customer
  • 91. How?
    We will commit to any task that we can do
    We will use tools that works for us
    We will share each other
    Document first & document as simple as possible
    We start development early
    It seems “scrum of scrum” will work rather than scrum
    Minimize testing iteration whenever possible
    Characterize each CR then reduce work if possible
    We will not do scrum for small (effort) CR (team less than 3)
    Detail plan will be discussed after this presentation!
  • 92. SCRUM TEAM MEMBER?
    What you should keep in mind
  • 93. …
    SCRUM team, keep asking these questions:
    What is the simplest thing that can move the project forward?
    Does what I am doing right now move the project forward at all?
    Are there any impediments that are preventing progress?
    Escalate impediment even thought they don’t really care about it.
    Sprint is belong to the team and is a team’s goal
    “Don’t procrastinate, do something, no matter how small…” – Ken Schwaber, Vienna, April 2004
  • 94. END