Transforming your sw development to agile

61
Transforming your Software Development to Agile Anu Khendry PMP, PMI-ACP, Six Sigma Black Belt Coach, Consultant and Trainer – Agile, PM, SPI

Transcript of Transforming your sw development to agile

  • 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 SoftwareDevelopment A Typical Road Map (and how to avoidthe pot-holes and speed-breakers) 3. Overview of Agile 4. History of Agile Mid-90s Lightweight software development methodsevolved as a reaction against Heavyweight(waterfall) methods Birth of SCRUM, XP, Crystal Clear, DSDM,FDD and Adaptive Software Development 2001 The Manifesto for Agile SoftwareDevelopment 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 andexperience) 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 overProcess and tools ComprehensiveWorking software over documentationCustomer collaboration overContract negotiationResponding to change overFollowing a planThat is, while there is value in the items on the right, we value the items on theleft more. Source: www.agilemanifesto.org 8. Project Chaos LevelAgile workshere 9. Iterative & Incremental DevelopmentIncremental 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 MethodologiesWaterfall Incremental AgileAnalysisDesignTimeImplementationTest 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 washigher 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 GoogleFirst American Real Estate Electronic Arts BMC Software High Moon Studios Ipswitch Lockheed Martin John Deere Philips Lexis Nexis Siemens Sabre Nokia Salesforce.com Capital One Time Warner BBC Turner Broadcasting IntuitOce 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-organizingdevelopment teamsExtreme Programming (XP)Customer driven, small teams, daily buildsLean & Kanban Prioritization and limiting work-in-progressCrystal Family of methodologies, tailoring approach for eachproject, two rules and two techniques, pre & postreflection workshopsDynamic Systems Evolution of Rapid Application Development (RAD)Development Method(DSDM)Feature DrivenFive-step process, short iterations, plan, design, build &Development (FDD) promote featureRational Unified ProcessActivity 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-longsprints Requirements are captured as items in a list ofproduct backlog No specific engineering practices prescribed Uses generative rules to create an agileenvironment for delivering projects One of the agile processes 20. Scrum 24 hours Sprint 2-4 weeks Sprint goalReturnSprint backlog Potentially shippableReturnCancel product incrementGift wrapCouponsCancel Gift wrapCoupons Product backlogCourtesy: MountainGoat Software 21. Agile in the Product DevelopmentframeworkStrategyPortfolio Other teams in thecompany plan hereProductRelease SprintDay Agile teams plan here 22. Nested Time-boxesPlanningProjectPlanningReleasePlanningReleasePlanningPlanning Review ReviewRetroRetroSprintSprintOrder and StructurePressure and FocusCost limitsNo Analysis Paralysis Daily Scrum 23. Progressive Elaboration Product Sprint BacklogBacklog Sprint Stories, ThemesPriority ReleaseEpicsFutureIdeasReleases 24. Multiple BacklogsSearch for optionsSearch by author Select the best option Search byBuy a Book Enter shipping informationpopularitySearch by price Make a paymentSearch 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 its full.. Sprint n The size of the box is the planned velocitySprint 1 Sprint 2Courtesy: MountainGoat Software 26. Scrum FrameworkRolesProduct OwnerScrum MasterTeamCeremoniesSprint planningSprint reviewSprint retrospectiveDaily scrum meetingArtifacts Product backlog Sprint backlog Burndown charts 27. Scrum RolesRolesProduct ownerScrum MasterTeam Ceremonies Sprint planning Sprint review Sprint retrospective Daily scrum meetingArtifacts Product backlog Sprint backlog Burndown charts 28. Product Owner Define the features of the product byinterfacing with stakeholders Decide on release date and content Be responsible for the profitability ofthe product (ROI) Prioritize features according to marketvalue Adjust features and priority everyiteration, as needed Accept or reject work results Communicate progress to the externalworld 29. Scrum Master Makes SCRUM work - responsible forenacting Scrum values and practices Removes impediments Ensures that the team is fully functional andproductive Enables close cooperation across all rolesand functions Shields the team from externalinterferences Is a Servant Leader 30. SM vs. PMScrum Master Project ManagerFacilitates the process, team hasHierarchical, command and controlcontrolmentalityIs a peerIs a bossHelps team focus on managing risks Focuses on managing riskFacilitates release and sprint Plans for the project scope, time andplanning costIs not involved in estimationEstimates for the project and its tasksFacilitates continuous improvement Responsible for continuous improvementTeam picks and manages their workPrioritizes, assigns and tracks teams workaccording to the defined priorityHas allegiance only to the teamHas allegiance to team and managementTeam is responsible for successPM 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 betweensprints Responsibilities of Team Attend the Daily Scrum Update the Sprint Backlog Carry out the tasks as per the Sprint Backlog 32. Scrum CeremoniesRolesProduct ownerScrum MasterTeam Ceremonies Sprint planning Sprint review Sprint retrospective Daily scrum meetingArtifactsProduct backlogSprint backlogBurndown charts 33. Scrum CeremoniesSprint Planning Sprint ReviewSprint Retrospective 34. Scrum ArtifactsRolesProduct ownerScrum MasterTeam Ceremonies Sprint planning Sprint review Sprint retrospective Daily scrum meetingArtifacts Product backlog Sprint backlog Burndown charts 35. Product BacklogA list of all desired work on the projectIdeally expressed such that each item has value to the users or customers of the productPrioritized by the product ownerReprioritized at the start of each sprintContains: Requirements (E.g. User stories)This is the Defectsproduct backlog Risk-related actions Change requests Any work that was not planned initially andwas added later 36. A Sprint Backlog Remaining Work TasksMon Tues WedThuFriCode the user interface 848Code the middle tier 16 12 10 4Test the middle tier8 16 16 11 8Write online help12Write the foo class 888 88Add error logging 8 4Courtesy: MountainGoat Software 37. Sprint Burndown Chart TasksMon Tues WedThu FriCode the user interface 84 8Code the middle tier1612 10 7Test the middle tier8 16 16 118Write online help 12 50 40 30 20 10 Hours0Mon Tue WedThuFriCourtesy: 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 & necessarydocumentation4 Upfront planningContinual planning5 Detailed requirements Customer collaboration6 Test after developmentTest early & often7 PredictiveAdaptive8 Design before development Emergent design9 Delivery at end Frequent delivery 40. DSDMs Inverted TriangleModel Functionality Resources/Cost Time fixed Agile TraditionalvaryTimeResources/CostFunctionality 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 ImproveGet 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 OneProjectSize Duration ShortLongSmall 46. Form Agile teams Cross-functional End-to-end functionality 5-9 people Full time resources What other supporting teams will youneed? 47. An Agile Organization - ExampleManagementMarketing Dev TeamsTesting Team ProductSM /TeamProcessSCRUM Team SCRUM TeamSCRUM Team SCRUM TeamProduct 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 andaptitude! 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 andaptitude! Leads can be potential Product Owners We must not rotate this role One PO can ideally handle only oneteam A PO must not handle sprint tasks 51. Create a Product Backlog Break up requirements into end-to-endfunctionalities 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 andmarketing, Business analysts, Portfolio managers, Projectmanagers, Agile teams Can use standard programs like CSM, CPO Half to Two Day modules are enough a lothappens as we go along with a coach Teams love this approach, others take sometime 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 sessionswith SMs and POs Ensures all in the team learn to perform theirroles 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 aboutimprovements 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 communicationreduces the need for intermediate deliverables Discipline / skills / understanding over process/ formality / documentation Efficiency is expendable in non-bottleneckactivitiesCourtesy: 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 SummarizeNecessary for Successful Transition (ADAPT model) AWARENESS that the current process doesnot deliver DESIRE to adopt Scrum as a way to addressthe current problems ABILITY to succeed with Scrum PROMOTION of Scrum by sharing experiences TRANSFER of the implications of using Scrumacross the organizationCourtesy: Lori Schubring 61. Thank YouMy contact info: [email protected] slides in this presentation are from freelyshareable resources at MountainGoat.com