Close to agile
Upcoming SlideShare
Loading in...5
×
 

Close to agile

on

  • 2,264 views

a overview scrum introduction

a overview scrum introduction

Statistics

Views

Total Views
2,264
Views on SlideShare
2,260
Embed Views
4

Actions

Likes
2
Downloads
123
Comments
1

1 Embed 4

http://www.linkedin.com 4

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
  • Quality : Apple , BLZMondey: movie Is Deadline important
  • What did I get done yesterdayWhat will I get done todayAre there any impediments slowing my progress

Close to agile Close to agile Presentation Transcript

  • Close to Agile-Scrum introduction
    Wu Gang
    iSAP, HPIT GADSC
  • Before start
    Have you touched Agile / Scrum before?
    What do you want to learn from this session ?
  • AGENDA
    Why Agile
    What is Agile
    Agile Value
    Agile Principle
    Scrum
    How Scrum
    Scrum process
  • Agile
  • Why Agile
  • Agile is popular
  • IT realities
    IT project delivered late 90% Aberdeen
    IT project delivered over budget 50% Gartner
    IT project that fail to meet objectives 50% Gartner
    IT project cancelled prior to completion 30% Aberdeen
  • Situation for tradition software Dev
    35% project complete on-time within budget
    31% project cancelled
    64% feature rarely never used
  • Complexity
    Can you understand enough in the beginning?
  • Losing information
    2
    3
    4
    5
    1
    8
    9
    10
    6
    7
    6. This is document
    1. Promise Made by Sales
    7. This is Installation Package
    2. Requirement Metioned by Customer
    8. This is Cost
    3. Requirement Understanded by Project Manager
    9. This is Support
    4. Design given by Designer
    10. This is What Really Want by Customer
    5. Coding performed by programer
  • What is project success
    Cover scope
    On time (before dead line)
    Under budget
  • Definition of success has changed
    Functionality
    83% of respondents believe that meeting actual needs of stakeholders is more important that building the system to specific action
    Quality
    82% believe that delivering high quality is more important that delivering on time and on budget.
    Money
    70% believe that providing the best ROI is more important that delivering under budget
    Schedule
    58% believe that delivering when the system is ready to be shipped is more important that delivering on schedule
    Source: software development project success survey, Scott Ambler , 2008
  • Agile is moving into mainstream
  • Waterfall VS. Agile
  • Waterfall vs. agile - cont
    Manage Change
  • Benefit of using agile
    Delivers faster time to market
    Increases productivity
    Reduces cost
    Easily adapts to changing requirements and priorities
    Lowers cost of change
    Provides better visibility into project progress
    Reduces risk
    Maximizes ROI
    Reduces waste
    Encourages higher quality and simpler code
    Delivers business value early and often
    Increases team morale
  • Survey for scrum project
    88% increase productivity
    93% increase quality
    83% increase stakeholder satisfaction
    49% reduce cost
    Agile Methodologies: Survey Results, by Shine Technologies, 2003
  • Agile
  • What is Agile
    Ag-ile (adj.) Characterized by quickness, lightness and ease of movement; nimble
    Agile is simple (not easy)
    Agile is about doing the important things first and taking small steps
    It’s about people, values, principles, and practices that foster team communication and learning and improving as you go along to regularly deliver customer value through working software
  • Agile manifesto
    1
    3
    2
    4
    Individuals and interactionsover processes and tools
    Customer collaborationover contract negotiation
    Working softwareover comprehensive documentation
    Responding to changeover following a plan
  • Agile Principles
    Satisfy the Customer
    Welcome Change
    Deliver Frequently
    Work as a Team
    Motivate People
    Communicate Face-to-Face
    Measure Working Software
    Maintain Constant Pace
    Excel at Quality
    Keep it Simple
    Evolve Designs
    Reflect Regularly
  • What is Scrum
  • Scrum
  • Scrum
  • Scrum 100 words
    Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
    It allows us to rapidly and repeatedly inspect actual working software ( every two weeks to one month).
    The business sets the priorities. Teams self-organize to determine the best way to deliver the highest priority features.
    Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint.
  • What Scrum look like
  • Scrum characteristics
    Self-organizing teams
    Product progresses in a series of time boxed Sprints
    Requirements are captured as items in a list of Product backlog
    No specific engineering practices prescribed
    Uses generative rules to create an agile environment for delivering projects
    One of the Agile processes.
  • How Scrum
  • Roles
    Ceremonies
    Artifacts
    • Product owner
    • Scrum Master
    • Team
    • Sprint
    • Sprint planning
    • Sprint review
    • Sprint retrospective
    • Daily scrum meeting
    • Product backlog
    • Sprint backlog
    • Burndown charts
  • What Scrum look like
    ScrumMaster
    Product Owner
    Image available at www.mountaingoatsoftware.com/scrum
    Team
  • Roles
    Ceremonies
    Artifacts
    • Product owner
    • Scrum Master
    • Team
    • Sprint
    • Sprint planning
    • Sprint review
    • Sprint retrospective
    • Daily scrum meeting
    • Product backlog
    • Sprint backlog
    • Burndown charts
  • Product owner
    What he is
    Owner of project vision
    Represents the customer
    What he can do
    Define features (according to vision)
    Prioritize features (according to ROI)
    Pick release dates
    Give feedback
    Manage stakeholders
    Accept or reject results
    Define Success
  • Team
    What he is
    Typically 5-9 people
    Cross functional
    Full Time
    Self-Organized
    What he can do
    Define tasks
    Estimate effort
    Develop product
    Ensure quality
    Evolve processes
    Deliver Success
  • Scrum master
    What he is
    Servant leader
    Team protector
    Troubleshooter
    Scrum guide
    What he can do
    Remove impediments
    Prevent interruptions
    Facilitate the team
    Support the process
    Manage management
    Ensure Success
  • Pigs and Chickens
    Product Owner
    Scrum Master
    Team Members
    Users
    Managers
    Marketing
  • Roles
    Ceremonies
    Artifacts
    • Product owner
    • Scrum Master
    • Team
    • Sprint
    • Sprint planning
    • Sprint review
    • Sprint retrospective
    • Daily scrum meeting
    • Product backlog
    • Sprint backlog
    • Burndown charts
  • Product BackLog
    The requirements
    A list of all desired work on the project
    Ideally expressed such that each item has value to the users or customers of the product
    Prioritized by the product owner
    Reprioritized at the start of each sprint
    • Ordered
    • Valued
    • Estimated
    Product Backlog
  • Product backlog
  • User stories
    As a <user> I want <functionality>( so that <benefit> )
    As a guest, I want to cancel a reservation,
    As a hotel employee, I can run RevPAR reports so that I can help to improve the quality of service
  • Typical fields
  • Principle of create User story
    Independent
    Negotiable
    Valued
    Estimable
    Small
    Testable
  • Sprint Backlog
    Individuals sign up for work of their own choosing
    Work is never assigned
    Estimated work remaining is updated daily
    Any team member can add, delete or change the sprint backlog
    Work for the sprint emerges
    If work is unclear, define a sprint backlog item with a larger amount of time and break it down later
    Update work remaining as more becomes known
    • Assignable
    • Small (1-16hours)
    • Team Estimated
    Sprint Backlog
  • Sprint BackLog
    8
    4
    8
    16
    12
    4
    10
    8
    16
    11
    8
    16
    12
    8
    8
    8
    8
    8
    4
    Add error logging
    8
    Tasks
    Mon
    Tues
    Wed
    Thur
    Fri
    Code the user interface
    Code the middle tier
    Test the middle tier
    Write online help
    Write the foo class
  • Task Board
    Visible
    Editable
    Update Daily
    Own By team
  • Product BackLog VS Sprint Backlog
    Code the middle tier (8 hours)
    Code the user interface (4)
    Write test fixtures (4)
    Code the foo class (6)
    Update performance tests (4)
    As a vacation planner, I want to see photos of the hotels.
  • Burndown charts
    Effort Left
    Date
  • Brundown Charts
    Update daily, usually during the daily stand-up
    Represent the amount of work remaining
    Different approaches to create burndown charts
    Estimated remaining time
    Track done
  • Tasks
    Mon
    Tues
    Wed
    Thur
    Fri
    4
    8
    12
    7
    10
    16
    11
    16
    8
    Burndown charts
    Code the user interface
    8
    Code the middle tier
    16
    Test the middle tier
    8
    50
    Write online help
    12
    40
    30
    Hours
    20
    10
    0
    Mon
    Tue
    Wed
    Thu
    Fri
  • Burndown charts
    Possible over commitment
    Possible Under commitment
    Commitment achieved. Keep this velocity for next Sprint
  • Roles
    Ceremonies
    Artifacts
    • Product owner
    • Scrum Master
    • Team
    • Sprint
    • Sprint planning
    • Sprint review
    • Sprint retrospective
    • Daily scrum meeting
    • Product backlog
    • Sprint backlog
    • Burndown charts
  • Sprint goal
    24 hours
    Cancel
    Gift wrap
    Return
    Coupons
    Gift wrap
    Coupons
    Cancel
    Sprint backlog
    Return
    Sprint
    2-4 weeks
    Potentially shippable
    product increment
    Product
    backlog
    Image available at www.mountaingoatsoftware.com/scrum
  • Sprint
    Sprint
    2-4 weeks
    Scrum projects make progress in a series of “sprints”
    Analogous to Extreme Programming iterations
    Typical duration is 2–4 weeks or a calendar month at most
    A constant duration leads to a better rhythm
    Product is designed, coded, and tested during the sprint
  • Sprint
    Change
    Plan sprint durations around how long you can commit to keeping change out of the sprint
  • Sprint Planning
    Sprint backlog
    Team selects items from the product backlog they can commit to completing
    Sprint backlog is created
    Tasks are identified and each is estimated (1-16 hours)
    Collaboratively, not done alone by the Scrum Master
    High-level design is considered
  • Sprint prioritization
    Sprint planning
    Sprint
    backlog
    • Analyze and evaluate product backlog
    • Select sprint goal
    • Decide how to achieve sprint goal (design)
    • Create sprint backlog (tasks) from product backlog items (user stories / features)
    • Estimate sprint backlog in hours
    Sprint Planning
    Sprint goal
    Sprint planning meeting
    Team capacity
    Product backlog
    Business conditions
    Current product
    Techno-logy
  • Daily Scrum meeting
    Parameters
    Daily
    15-minutes
    Stand-up
    Not for problem solving
    Whole world is invited
    Only team members, ScrumMaster, product owner, can talk
    Helps avoid other unnecessary meetings
  • Daily scrum meeting
    Only the team talks
    Not to Scrum Master
    No problem solving
    Max 15 minutes
    Standing up
    1
    2
    3
    What have you done yesterday?
    What will be done today?
    Is anything in your way?
  • Sprint review
    Team presents what it accomplished during the sprint
    Typically takes the form of a demo of new features or underlying architecture
    Informal
    2-hour prep time rule
    No slides
    Whole team participates
    Invite the world
  • Sprint retrospective
    Periodically take a look at what is and is not working
    Typically 15–30 minutes
    Done after every sprint
    Whole team participates
    ScrumMaster
    Product owner
    Team
    Possibly customers and others
  • Sprint retrospective
  • Review
  • 3 – 3 – 5
    Roles
    Ceremonies
    Artifacts
    • Product owner
    • Scrum Master
    • Team
    • Sprint
    • Sprint planning
    • Sprint review
    • Sprint retrospective
    • Daily scrum meeting
    • Product backlog
    • Sprint backlog
    • Burndown charts
  • Scrum Process
    ScrumMaster
    Product Owner
    Image available at www.mountaingoatsoftware.com/scrum
    Team
  • There’s no silver bullets
  • Thank you