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: www.agilemanifesto.org
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 •Salesforce.com •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”
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
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
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: firstname.lastname@example.orgSome slides in this presentation are from freelyshareable resources at MountainGoat.com