Transforming your sw development to agile


Published on

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Transforming your sw development to agile

  1. 1. Transforming your SoftwareDevelopment to AgileAnu Khendry PMP, PMI-ACP, Six Sigma Black BeltCoach, Consultant and Trainer – Agile, PM, SPI
  2. 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. 3. Overview of Agile
  4. 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. 5. Agile DefinitionAgile is about delivering the highestbusiness value possible faster by focusingon people and continuous improvement(iteration).
  6. 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. 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. 8. Project Chaos Level Agile works here
  9. 9. Iterative & Incremental Development Incremental IterativeCourtesy: Jeff Patton
  10. 10. Cost of Change in Waterfall ApproachCourtesy: Declan Whelan
  11. 11. Cost of Change in Agile ApproachCourtesy: Declan Whelan
  12. 12. Comparison between Various Methodologies Waterfall Incremental AgileAnalysisDesign TimeImplementationTest Scope
  13. 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. 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. 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. 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. 17. Overview of SCRUM
  18. 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. 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. 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. 21. Agile in the Product Developmentframework Strategy Portfolio Other teams in the company plan here Product Release Sprint Day Agile teams plan here
  22. 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. 23. Progressive Elaboration Product Sprint Backlog Backlog Sprint Stories, Themes Priority Release EpicsFuture IdeasReleases
  24. 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. 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. 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. 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. 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. 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. 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. 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. 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. 33. Scrum Ceremonies Sprint Planning Sprint Review Sprint Retrospective
  34. 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. 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. 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. 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. 38. Traditional vs. Agile SoftwareDevelopmentWhat needs to change?
  39. 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. 40. DSDM‟s Inverted Triangle Model Functionality Resources/Cost Time fixed Agile Traditional varyTime Resources/Cost Functionality
  41. 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. 42. Sample Road Map forTransition
  43. 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. 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. 45. Select a Right Pilot Project Large Pick This One Project Size Duration Short Long Small
  46. 46. Form Agile teams Cross-functional End-to-end functionality 5-9 people Full time resources What other supporting teams will you need?
  47. 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. 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. 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. 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. 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. 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. 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. 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. 55. Improve … Improve … Improve Improve the Product Improve the Process Improve the Skills (People) Every retrospective brings about improvements
  56. 56. Methodology Anti-Patterns • One size for all projects • Intolerant • Heavy • Embellished • Untried • Used onceCourtesy: Alastair Cockburn
  57. 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. 58. Agile Adoption: Barriers and ConcernsSource: VersionOne, 5th Annual “State of Agile Development” Survey 2010”
  59. 59. Leading Causes of Failed Agile ProjectsSource: VersionOne, 5th Annual “State of Agile Development” Survey 2010”
  60. 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. 61. Thank YouMy contact info: anu.khendry@gmail.comSome slides in this presentation are from freelyshareable resources at