Your SlideShare is downloading. ×

Agile & SCRUM


Published on

Published in: Technology
  • Be the first to 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. Agile & SCRUM
    Created by, 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)
    Fast – but never hurried
    Exposes wastefulness
    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)
    Lean Development
    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
    Product Backlog
    Sprint Planning
    Team Capabilities
    Sprint Goal
    Business Conditions
    Sprint Backlog
    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
    24 hours
    Backlog tasks
    by team
    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
    Product Owner
    Team presents what it accomplished during the sprint
    Team demos Increment
    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)
  • 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
  • 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
    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!
    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