• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Agile & SCRUM
 

Agile & SCRUM

on

  • 7,799 views

 

Statistics

Views

Total Views
7,799
Views on SlideShare
7,792
Embed Views
7

Actions

Likes
10
Downloads
798
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 Agile & SCRUM Presentation Transcript

    • 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.
    • AGILE Methodology
    • Why Agile Software Development…?
    • 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
    • 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
    • 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
    • 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!!
    • 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)
    • 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
    • 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
    • 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
    • SCRUM
    • 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
    • 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.
    • 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
    • Roles and Responsibilities
      Product Owner
      • Defines the features of the product, decides on release date and content
      • Is responsible for the profitability of the product (ROI)
      • Prioritizes features according to market value
      • Can change features and priority every 30 days
      • Accepts or rejects work results
      Scrum Master
      • Ensures that the team is fully functional and productive
      • Enables close cooperation across all roles and functions and removes barriers
      • Shields the team from external interferences
      • Ensures that the process is followed. Invites to daily scrum, iteration review and planning meetings
    • Team
      • Cross-functional, seven plus/minus two members
      • Selects the iteration goal and specifies work results
      • Has the right to do everything within the boundaries of the project guidelines to reach the iteration goal
      • Organizes itself and its work
      • Demos work results to the Product Owner
    • Key Artifacts
      Product backlog
      • List of requirements & issues
      • Owned by Product Owner
      • Anybody can add to it
      • Only Product Owner prioritizes
      Sprint Goal
      • A short “theme” for the sprint, typically one line summary:
      • For example, “Make the application run on Oracle in addition to SQL Server”
      • Declared by Product Owner
      • Accepted by team
    • From Sprint Goal to Sprint Backlog …
      • Scrum team takes the Sprint Goal and decides what tasks are necessary
      • Team self organizes around how they’ll meet the Sprint Goal
      • Manager doesn’t assign tasks to individuals
      • Managers don’t make decisions for the team
      • Sprint Backlog is created
      Sprint backlog
      • List of tasks
      • Owned by team
      • Only team modifies it
      Blocks list
      • List of blocks & unmade decisions
      • Owned by Scrum Master
      • Updated daily
    • Product Backlog
    • Sprint Backlog
    • Sprint Backlog (after 5th days)
    • Key Meetings
      Sprint Planning Meeting
      • Hosted by Scrum Master; ½-1 day
      • In: Product Backlog, existing product, business & technology conditions
      • Select highest priority items in Product Backlog; declare Sprint Goal
      • Team turns selected items into Sprint Backlog
      • 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
    • Key Meetings (Cont’d)
      Daily Scrum
      • Hosted by Scrum Master
      • 15 – 30 minutes stand-up meeting
      • Attended by all: pigs (scrum team) and chickens (others), but only pigs can talk
      • Same time every day; three questions:
      • What did you do yesterday?
      • What will you do today?
      • What obstacles are in your way?
      • 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!
    • 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
    • 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
    • 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.
    • Burndown chart
    • Scrum of Scrum
    • 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
    • Concept & Process (PM & SM)
      • Scrum Masters say
      • Sprint
      • Sprint Backlog
      • Task Breakdown
      • Velocity
      • Burndown Chart
      • Project Managers say
      • Schedule
      • Scope
      • Work Breakdown Structure
      • Productivity
      • Estimate to Complete
      • Scrum Masters say
      • Define Backlog, Plan Sprint
      • Develop and Test
      • Move Stickies, have Daily Scrums
      • Demo, Release, have Retrospective
      • Project Managers say
      • Plan
      • Execute
      • Monitor & Control
      • 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
    • SCRUM IN MY PROJECT
    • Case study: Our project
      We haven’t done a SCRUM yet
      We planning it
      • We need to adapt not adopt
      • No “big bang” adoption
      Start by a simple but working, NOT complete but not working
    • 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
    • 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
    • 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!
    • SCRUM TEAM MEMBER?
      What you should keep in mind

    • 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
    • END