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
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
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
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.
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.
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
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
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
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
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.
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 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