Your SlideShare is downloading. ×
Transforming your sw development to agile
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Transforming your sw development to agile


Published on

  • Be the first to comment

  • Be the first to like this

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. Transforming your SoftwareDevelopment to AgileAnu Khendry PMP, PMI-ACP, Six Sigma Black BeltCoach, Consultant and Trainer – Agile, PM, SPI
  • 2. Agenda Overview of Agile Overview of SCRUM Traditional vs. Agile Software Development A Typical Road Map (and how to avoid the pot-holes and speed-breakers)
  • 3. Overview of Agile
  • 4. History of Agile Mid-90s ◦ Lightweight software development methods evolved as a reaction against Heavyweight (waterfall) methods ◦ Birth of SCRUM, XP, Crystal Clear, DSDM, FDD and Adaptive Software Development 2001 ◦ The Manifesto for Agile Software Development ◦ Principles behind the Agile Manifesto ◦ Agile Alliance
  • 5. Agile DefinitionAgile is about delivering the highestbusiness value possible faster by focusingon people and continuous improvement(iteration).
  • 6. Agile 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 ManifestoIndividuals and interactions over Process and tools ComprehensiveWorking software over documentationCustomer collaboration over Contract negotiationResponding to change over Following a planThat is, while there is value in the items on the right, we value the items on theleft more. Source:
  • 8. Project Chaos Level Agile works here
  • 9. Iterative & Incremental Development Incremental IterativeCourtesy: Jeff Patton
  • 10. Cost of Change in Waterfall ApproachCourtesy: Declan Whelan
  • 11. Cost of Change in Agile ApproachCourtesy: Declan Whelan
  • 12. Comparison between Various Methodologies Waterfall Incremental AgileAnalysisDesign TimeImplementationTest Scope
  • 13. Benefits- examples 16% increase in productivity 37% faster Time-to-Market 84% said defects down by >25% 30% said defects down by >10% 58% said Stakeholder Satisfaction was higher 86% said higher job satisfaction Sources: QSMA (Michael Mah 2008) David Rico (2008) VersionOne (2008)
  • 14. Agile is being used by •Microsoft •Intuit •Yahoo •Nielsen Media •Google •First American Real Estate •Electronic Arts •BMC Software •High Moon Studios •Ipswitch •Lockheed Martin •John Deere •Philips •Lexis Nexis •Siemens •Sabre •Nokia • •Capital One •Time Warner •BBC •Turner Broadcasting •Intuit •Oce
  • 15. Misconceptions about Agile • It is not disciplined • It is a specific methodology • It does not work for large projects • No documentation • It works only with teams physically located at one place
  • 16. Agile FrameworksFramework What is it?Scrum Adaptive, flexible, implements small, self-organizing development teamsExtreme Programming (XP) Customer driven, small teams, daily buildsLean & Kanban Prioritization and limiting work-in-progressCrystal Family of methodologies, tailoring approach for each project, two rules and two techniques, pre & post reflection workshopsDynamic Systems Evolution of Rapid Application Development (RAD)Development Method(DSDM)Feature Driven Five-step process, short iterations, plan, design, build &Development (FDD) promote featureRational Unified Process Activity driven role assignment, business modeling, tool(RUP) family supportAdaptive Software Adaptive culture, collaborative, iterative development,Development (ASD) focuses on concept and culture
  • 17. Overview of SCRUM
  • 18. Scrum in 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.
  • 19. Characteristics of Scrum• Self-organizing teams• Product progresses in a series of month-long “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”
  • 20. Scrum 24 hours Sprint 2-4 weeks Sprint goal Return Sprint backlog Potentially shippable Return Cancel product increment Gift wrap Coupons Cancel Gift wrap Coupons Product backlogCourtesy: MountainGoat Software
  • 21. Agile in the Product Developmentframework Strategy Portfolio Other teams in the company plan here Product Release Sprint Day Agile teams plan here
  • 22. Nested Time-boxesPlanning Project Planning ReleasePlanning Release … Planning Planning Review Review Retro Retro Sprint … Sprint Order and Structure … Pressure and Focus Cost limits No “Analysis Paralysis” Daily Scrum
  • 23. Progressive Elaboration Product Sprint Backlog Backlog Sprint Stories, Themes Priority Release EpicsFuture IdeasReleases
  • 24. Multiple Backlogs Search for options Search by author Select the best option Search byBuy a Book Enter shipping information popularity Search by price Make a payment Search by rating ShipmentProduct ReleasesSprints
  • 25. Release, iteration, & velocity Release Planning  A release comprises multiple iterations  Each iteration can be thought of as a same sized box  Stories are put into each box until it‟s full …….. Sprint n  The size of the box is the planned velocity Sprint 1 Sprint 2Courtesy: MountainGoat Software
  • 26. Scrum FrameworkRoles•Product Owner•Scrum Master•Team Ceremonies •Sprint planning •Sprint review •Sprint retrospective •Daily scrum meeting Artifacts •Product backlog •Sprint backlog •Burndown charts
  • 27. Scrum RolesRoles•Product owner•Scrum Master•Team Ceremonies •Sprint planning •Sprint review •Sprint retrospective •Daily scrum meeting Artifacts •Product backlog •Sprint backlog •Burndown charts
  • 28. Product Owner• Define the features of the product by interfacing with stakeholders• Decide on release date and content• Be responsible for the profitability of the product (ROI)• Prioritize features according to market value• Adjust features and priority every iteration, as needed• Accept or reject work results• Communicate progress to the external world
  • 29. Scrum Master• Makes SCRUM work - responsible for enacting Scrum values and practices• Removes impediments• Ensures that the team is fully functional and productive• Enables close cooperation across all roles and functions• Shields the team from external interferences• Is a “Servant Leader”
  • 30. SM vs. PM Scrum Master Project ManagerFacilitates the process, team has Hierarchical, command and controlcontrol mentalityIs a peer Is a “boss”Helps team focus on managing risks Focuses on managing riskFacilitates release and sprint Plans for the project – scope, time andplanning costIs not involved in estimation Estimates for the project and its tasksFacilitates continuous improvement Responsible for continuous improvementTeam picks and manages their work Prioritizes, assigns and tracks team‟s workaccording to the defined priorityHas allegiance only to the team Has allegiance to team and managementTeam is responsible for success PM is responsible for success of the project
  • 31. The Team• Typically 5-9 people• Cross-functional:  Programmers, testers, user experience designers, etc.  May have a “Bouncer”• Members should be full-time  May be exceptions (e.g., database administrator)• Teams are self-organizing  Ideally, no titles but rarely a possibility• Membership should change only between sprints• Responsibilities of Team • Attend the Daily Scrum • Update the Sprint Backlog • Carry out the tasks as per the Sprint Backlog
  • 32. Scrum CeremoniesRoles•Product owner•Scrum Master•Team Ceremonies •Sprint planning •Sprint review •Sprint retrospective •Daily scrum meeting Artifacts •Product backlog •Sprint backlog •Burndown charts
  • 33. Scrum Ceremonies Sprint Planning Sprint Review Sprint Retrospective
  • 34. Scrum ArtifactsRoles•Product owner•Scrum Master•Team Ceremonies •Sprint planning •Sprint review •Sprint retrospective •Daily scrum meeting Artifacts •Product backlog •Sprint backlog •Burndown charts
  • 35. Product Backlog • 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 • Contains: • Requirements (E.g. User stories)This is the • Defectsproduct backlog • Risk-related actions • Change requests • Any work that was not planned initially and was added later
  • 36. A Sprint Backlog Remaining Work Tasks Mon Tues Wed Thu Fri Code the user interface 8 4 8 Code the middle tier 16 12 10 4 Test the middle tier 8 16 16 11 8 Write online help 12 Write the foo class 8 8 8 8 8 Add error logging 8 4Courtesy: MountainGoat Software
  • 37. Sprint Burndown Chart Tasks Mon Tues Wed Thu Fri Code the user interface 8 4 8 Code the middle tier 16 12 10 7 Test the middle tier 8 16 16 11 8 Write online help 12 50 40 30 20 10 Hours 0 Mon Tue Wed Thu FriCourtesy: MountainGoat Software
  • 38. Traditional vs. Agile SoftwareDevelopmentWhat needs to change?
  • 39. Traditional Vs. AgileS No. Traditional Agile1 Resist change Embrace change2 Comprehensive documentation „Just-Enough‟ documentation & working software3 Document-driven communication Team collaboration & necessary documentation4 Upfront planning Continual planning5 Detailed requirements Customer collaboration6 Test after development Test early & often7 Predictive Adaptive8 Design before development Emergent design9 Delivery at end Frequent delivery
  • 40. DSDM‟s Inverted Triangle Model Functionality Resources/Cost Time fixed Agile Traditional varyTime Resources/Cost Functionality
  • 41. When to Transition?◦ Ask - does your current process work?  Does it help us deliver high customer value?  Does it help us deliver on time?  Does it help us stay within budget?  Is our competition always ahead?  Are our requirements changing?  Are our customers happy?  Are our teams happy?
  • 42. Sample Road Map forTransition
  • 43. Road Map to Agile Decide on the roll-out approach Form Agile teams Decide on a minimal process Appoint Scrum Masters and Product Owners Create Product Backlogs Training and Orientation Intensive coaching for the first few sprints Tailor the process Improve … Improve … Improve Get help from an Agile Coach!!
  • 44. Roll-out ApproachTwo options:• Big bang - All teams• Gradual - Pilot in one or two teamsHow to choose?• Size of the company• Size of the problem• Ability to succeed• Availability of skilled coaches, POs, SMs
  • 45. Select a Right Pilot Project Large Pick This One Project Size Duration Short Long Small
  • 46. Form Agile teams Cross-functional End-to-end functionality 5-9 people Full time resources What other supporting teams will you need?
  • 47. An Agile Organization - Example ManagementMarketing Dev Teams Testing Team Product SM / Team Process SCRUM Team SCRUM Team SCRUM Team SCRUM Team Product Supporting TeamsTechnical Experts, Integration and Build Teams, Domain Experts, Regression Test Teams
  • 48. Decide on a “minimal” process Sprint duration and schedule Release schedules Demo schedules Build schedules Mandatory standards like Code Mandatory tasks like Code Review Unit and Regression Test automation Defect handling Agile tools for tracking What else??
  • 49. Appoint Scrum Masters A very critical role! Look for the correct attitude and aptitude! Leads are not potential Scrum Masters Mid-level people work best We rotate this role after some sprints One SM can have one (ideal) or two (max) teams The SM must not handle sprint tasks
  • 50. Appoint Product Owners Also a very critical role! Look for the correct attitude and aptitude! Leads can be potential Product Owners We must not rotate this role One PO can ideally handle only one team A PO must not handle sprint tasks
  • 51. Create a Product Backlog Break up requirements into end-to-end functionalities Define Agile requirements – small, detailed, with acceptance criteria, e.g. user stories Address needs of all “customers” Address needs of the team Prioritize!
  • 52. Training and Orientation Involve everybody • Customers, Senior management, Sales and marketing, Business analysts, Portfolio managers, Project managers, Agile teams Can use standard programs like CSM, CPO Half to Two Day modules are enough – a lot happens as we go along with a coach Teams love this approach, others take some time to adapt!
  • 53. Intensive coaching for the first fewsprints Involve an Agile Coach in ◦ Sprint planning and estimation ◦ Daily scrum ◦ Retrospectives ◦ Group and one-on-one coaching sessions with SMs and POs ◦ Ensures all in the team learn to perform their roles
  • 54. Process Tailoring • Start with normal Agile, tailor based on experiences • Needs to be done with care – interconnected practices • View agile methods as tools • Change for the good • Treat the cause, not the symptom • Try small doses
  • 55. Improve … Improve … Improve Improve the Product Improve the Process Improve the Skills (People) Every retrospective brings about improvements
  • 56. Methodology Anti-Patterns • One size for all projects • Intolerant • Heavy • Embellished • Untried • Used onceCourtesy: Alastair Cockburn
  • 57. Principles for Project Success • Face-to-face communications • Excess methodology weight is costly • Larger teams need heavier methodologies • More ceremony for more critical projects • Increasing feedback and communication reduces the need for intermediate deliverables • Discipline / skills / understanding over process / formality / documentation • Efficiency is expendable in non-bottleneck activitiesCourtesy: Alastair Cockburn
  • 58. Agile Adoption: Barriers and ConcernsSource: VersionOne, 5th Annual “State of Agile Development” Survey 2010”
  • 59. Leading Causes of Failed Agile ProjectsSource: VersionOne, 5th Annual “State of Agile Development” Survey 2010”
  • 60. To Summarize Necessary for Successful Transition (ADAPT model) ◦ AWARENESS that the current process does not deliver ◦ DESIRE to adopt Scrum as a way to address the current problems ◦ ABILITY to succeed with Scrum ◦ PROMOTION of Scrum by sharing experiences ◦ TRANSFER of the implications of using Scrum across the organizationCourtesy: Lori Schubring
  • 61. Thank YouMy contact info: anu.khendry@gmail.comSome slides in this presentation are from freelyshareable resources at