Download as PDF, PPTX
Uploaded byJohn Carter
Can Agile Work With a Waterfall Process?
The document outlines a presentation by John Carter of TCGen on the compatibility of Agile methodologies with traditional Waterfall processes. It discusses barriers to Agile adoption, the principles of the Agile Manifesto, and provides strategies for implementing Agile in organizations with existing structures. The presentation emphasizes the need for cultural change, proactive leadership, and tailored approaches to effectively integrate Agile practices.
More Related Content
Similar to Can Agile Work With a Waterfall Process?
Can Agile Work With a Waterfall Process?
- 1. PRESENTATION TO AGILECOP Never the Twain Shall Meet… Can Agile Work with a Waterfall Process? John Carter TCGen Inc. March 5, 2018 Agile Community of Practice
- 2.
- 4.
- 5.
- 6.
- 7. TCGEN: AN EXPERIENCEDBASED CONSULTANCY John Carter • Recognized authority in Product Development • Author of “Innovate Products Faster” • Created Apple’s New Product Process (ANPP) • Invented Bose’s Noise Cancelling Headphones
- 9.
- 10.
- 11. WHAT THE RESEARCHTELLS US: AGILE IS SPREADING • McKinsey Study of Organization-wide Agile Transformations* • Surprising that it is not “up and to the right”!? * How to Create an Agile Organization, Oct. 2017 (Ahlback, Fahrbach, Murarka, and Salo) Percentofrespondentsreportingorganization-wide agiletransformations,byindustry
- 12. WHAT PRACTICES DOESAN AGILE ORGANIZATION FOLLOW? • Differences between Agile and Bureaucratic Organizations • The top four differences are directly applicable to most organizations * How to Create an Agile Organization, Oct. 2017 (Ahlback, Fahrbach, Murarka, and Salo)
- 13. WHY HAVE ORGANIZATIONSBEEN SLOW TO ADOPT AGILE? •Myths create major barriers to adoption* • “Applying Agile is all or nothing” • “You must be able to ship every two weeks” • “Agile and Waterfall/Milestone are mutually exclusive” •Bite off too much *TCGen Research on Agile Implementation Barriers, 2016
- 14. AGILE MANIFESTO –NOT JUST FOR AGILE 1.Business people and developers work together daily 2.Projects require motivated individuals, support & trust 3.Face-to-face conversation is most efficient 4.Agile processes promote sustainable development 5.Continuous attention to technical excellence 6.Simplicity is essential 7.The best designs emerge from self-organizing teams 8.At regular intervals, the team reflects 9.Welcome changing requirements 10.Continuous delivery of valuable software 11.Deliver working software frequently 12.Working software is the measure of progress 75% of the Agile Manifesto CAN apply to any type of development Consumer / Cloud Universal http://agilemanifesto.org/
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21. ORGANIZATION: A BIGCHALLENGE Challenges • Stronger teaming required • Trust may be missing • Power transfer to teams Impacts Maslow’s hierarchy of needs. Why it’s hard • Fear of lost domain knowledge • Teams need to skill up • Career path changes
- 22. CHANGE ROLES: RECIPEFOR THE AGILE TRANSFORMATION • Servant Leadership model –Proactive help • Roles for Managers –Increase Talent Density –Remove Roadblocks –Plan Architecture • Roles for Teams –Self Governing if in bounds
- 23. HOW CAN I HELPYOU TO BE SUCCESSFUL?
- 24.
- 25.
- 26.
- 27. REMOVE BARRIERS WITHATTITUDE INFLUENCE MAP High Influence Negative Attitude Sarah VP User Experience Individuals Involved in Initiative's success
- 28. WHAT IS ANATTITUDE INFLUENCE MAP? •Helps proactive leaders accomplish objectives •Removes roadblocks placed by others •Part of three steps to remove barriers
- 29. BARRIER REMOVAL INTHREE SIMPLE STEPS 3.Implement 2.Map & Plan 1.Identify Barriers
- 30. #1 – PROGRAMLEADERS EVALUATE CHALLENGES •In small group –List those who might impact your program •Plot individuals against the two axes (Attitude and Influence) •Attitude (horizontal axis) – Rate the person’s attitude •Influence (vertical axis) – Rate the person’s influence –Often it is their position, but also consider seniority, knowledge, etc.
- 31. #2 - CREATEATTITUDE INFLUENCE MAP & PLAN • Use “Pair Wise” comparisons to fine tune Map • Discuss Sarah versus Jill, then Jill versus Harry • Finally Sarah versus Harry • Identify high influence & negative attitude individuals • Generate plan Jill VP IT Ops Harry Manager PMO Sarah VP User Experience
- 32. -5 -4 -3 -2 -1 0 1 2 3 4 5 -5 -4 -3-2 -1 0 1 2 3 Attitude Influence ATTITUDE INFLUENCE MAP Pinpoint proactive plans to bring managers on-board Jill VP IT Ops Harry Manager PMO Sarah VP User Experience Attitude Influence
- 33. #3 - ACTIONPLANS* Create individualized action plans & divide work 1. Jill – Have Kate speak to her peer, James, who she trusts & has her ear (March 12) 2. Sarah – Have Bill meet with her 1:1, address concerns (March 15) 3. Harry – In PMO Bi-Weekly, Mindy ask Harry’s boss how to work with Harry (OPTIONAL! – Scheduled for March 19) *Kate, Bill and Mindy are leading an Agile initiative Jill, Sarah and Harry are managers key to success
- 34. AGILE ADVOCATES USEAT THEIR SITE OR AGILE BOD USE ACROSS ORG Idea!
- 35.
- 36. AGILE DEFINED • Defined17 years ago to address chronic delivery problems • The Agile Manifesto* has led to remarkable improvements • The most common approach is a Scrum approach * http://agilemanifesto.org/ Roles Scrum Master Product Owner Team Ceremonies Planning & Estimation Daily Standups & Monitoring Demos & Retrospectives Foundations Fixed length Sprints (2W) Stories & Epics Managers serve the Team Customers part of Team
- 37. AGILE IN PRACTICE •In practice, most firms doing Agile select elements • This is a very small subset of Agile practices • All organizations we know - Agile co-exists with Milestones * http://agilemanifesto.org/ Roles Scrum Master Product Owner Team Ceremonies Planning & Estimation Daily Standups & Monitoring Demos & Retrospectives Foundations Fixed length Sprints (2W) Stories & Epics Managers serve the Team Customers part of Team Example of Intelligent adoption
- 38. Instructor Biographies • Theapproach –Focus on “Show & Tell” @ end of Sprints (UX, SW, SI) –NO burndown charts, NO sprint estimates • The Costs –More prototypes & more effort in stories • The Benefits –Progress was now visible in 3 week increments –Forced decisions and schedule adherence –Accuracy of the overall project is much higher –Developers are much more engaged MEDICAL DEVICES CASE STUDY HOW THEY DISRUPTED WATERFALL DEVELOPMENT
- 39. Instructor Biographies • TheApproach –Demo to management at the end of the Sprints –Planning: focus Sprint Goals, Acceptance Criteria, Metrics –Heavy facilitation for the first set of Sprints • The Costs –Process highlighted lack of management support –Exposed the organization to reskilling team • The Benefits –Sprints resulted in faster decisions and schedule accountability CONSUMER ELECTRONICS CASE STUDY A STEP AT A TIME
- 40. NOW, HOW TOTHINK ABOUT AGILE? Agile helps organizations innovate & execute 1. Embracing change gracefully 2. Enabling Teams’ autonomy 3. Getting closer to customers
- 41. HOW TO IMPLEMENTAGILE @ AN ORGANIZATION WITH WATERFALL PROCESS
- 42. THREE STEPS TOIMPLEMENT AGILE 1.Identify challenges 2.Select Elements 3.Inch-Wide, Mile-Deep
- 43. PROJECT HISTORIES: UNCOVERAREAS FOR IMPROVEMENT Positive: “What went well on this project that we would like to reinforce and repeat? Negative: “What are the key barriers to this program meeting the expectations of key stakeholders?” Project History Timeline & Why's Synthesis of Root Causes Wagon Wheel Frogman Jamestown Interviews Implementation Recommendations 80 facts Select Key Facts .... ... .. .. . . . . . .. .. . . . .. ... . .. ..Numerical data for each project history . .. . . . . .. . .. .. . .. .. . . . . . .. . .. .. .. Steering Team Project History Summary Root Causes of Project Difficulties & Successes Staffing Feature Changes Financials Predicted Schedule vs. Actual Quality Steering Committee Electra Ultra II
- 44. INTELLIGENT AGILE: SELECTTHE BEST SUBSET • In practice, most firms select elements • All organizations we know have Agile co-existing with a milestones • Project Histories will inform which practices to implement first Roles Scrum Master Product Owner Team Ceremonies Planning & Estimation Daily Standups & Monitoring Demos & Retrospectives Foundations Fixed length Sprints (2W) Stories & Epics Managers serve the Team Customers part of Team Example of YOUR selective adoption
- 45. Utilization of DevelopmentCapability Total Development Time Value Added Designing Testing -> feedback... Non-Value Added Redesign Poor testing Meetings without progress... Number of Concurrent Projects for a Given Developer 100 90 80 70 60 50 40 30 20 10 % Usable Developer Time, i.e., Value Added Time 1 2 3 4 5 6 Number of Initiatives Implementa- Tion Effectiveness (Initiatives / Person / Month) 1 2 3 4 • In PROGRAM MANAGEMENT, developers can get buried under too many projects • In CHANGE MANAGEMENT, employees can get buried under too many initiatives INCH-WIDE, MILE-DEEP IMPLEMENTATION
- 46.
- 47. PATH FOR YOU •1, 2, 3
- 48.
- 49.
- 50. WHAT IS ABOUNDARY CONDITION DIAGRAM? What is a Boundary Condition Diagram? • Diagram identifies the critical elements of a project • Lightweight plan of record • Drives tradeoff decisions Which Business Problems Does the Tool Solve? • Ensures project teams clearly understand goals • Enables management alignment • Reduces delays
- 51. HOW TO APPLYCREATE BOUNDARY CONDITIONS •Team selects key boundaries •Assign each element to a side • Triangle • Square… • Polygon •State the boundary for each element •Document thresholds
- 52. EXAMPLE BOUNDARY CONDITIONS •Listboundaries •List key thresholds •If team within boundaries •Then free from constant status reporting
- 53. EXAMPLE BOUNDARY BREAK •Burndown too Slow! • Key Engineer pulled! • Three week delay!
- 54. BOUNDARY CONDITION PROCESS *Or Scrum Manager SC Agree?
- 55. AGILE TEAMS CREATEBOUNDARY CONDITIONS DIAGRAM THEN PRESENT TO MANAGEMENT @ NEXT REVIEW Idea!
- 56.
- 57. WHY DEMONSTRATIONS WITHPROTOTYPES ARE SO POWERFUL •Provides short term, tangible goals •Enables organizational input •Provides tangible indication of progress •At the end of every 2 Week Sprint
- 58. DEMOS & IMPORTANCEOF CUSTOMERS & PROXIES • The audience is as important as the goal • The audience should vary from sprint to sprint • There are many different and useful ‘customers’ Audience Examples End customers Providers, patients, companies AND internal business partners (finance, operations, purchasing…) Internal customers Executives in same department, executives in other areas, UX/UE, Quality, Customer Service, Operations Intermediate customers Hospitals, Clinics, physician’s offices, administrative staff, suppliers Internal customer proxies Business Partners, analysists, customer service, operations, quality
- 59. AGILE TEAMS IDENTIFY AUDIENCE & PLANTHREE SPRINT DEMONSTRATIONS Idea!
- 60.
- 61. REVIEW AND REFLECTION:RAPID LEARNING & FEEDBACK • Review the execution of the PROJECT –Did we accomplish our goals? –Do we have the right resources? –What will we do differently for the next sprint? • Review execution of the PROCESS –How effective was our Sprint Plan –How well did our metrics work? –What will we do differently for the next sprint?
- 62. 3 PROJECT HISTORY MEETINGAGENDA 8:00 - 8:30 Introductions Ground rules (set the tone) Select the theme (see an example in bold below) 8:30 - 11:30 Semantics pointers Timeline review When did project start & end? Identify unplanned events Dot vote on the most important Root cause analysis on the most important Perform omissions check 11:30 - 12:00 Begin exercise on “What are the key barriers to this meeting the expectations of key stake holders?” Create Affinity Diagram grouping the most important root causes 12:00 - 12:30 Lunch (a working lunch) 12:30 - 3:00 Complete Affinity Diagram Perform omissions check 3:00 - 3:30 Dot vote on the top three first level grouping 3:30 - 4:00 Review data Action items and summary Reflection on day's process
- 63. 4 PROJECT HISTORY PREPARATION •Select Team – Have the cross functional team participate – no managers • Kick-off Meeting – Define meeting objectives – Detail preparation requirements • Pre-work – Gather project information – Collect metrics • Project History Day – Truly fact based
- 64. REVIEW AND REFLECTION Action Plan 1.Event Analysis Identify the impact of planned & unplanned events on project outcome 2. Root Cause Analysis Select most significant root causes 3. Root Cause Synthesis Understanding the big picture Planned Events Unplanned Events Definition Design Integration Validation MVP Release Event 1 Event 2 Event 3 SPRINT or PROJECT Timeline? ?? Grooming Estimation Feature Feature Testing Retrospective
- 65. EXAMPLE PROJECT HISTORYLANGUAGE ANALYSIS WHAT ARE THE ROOT CAUSES FOR THE ISSUES IMPACTING CYCLE TIME AND PRODUCT QUALITY FOR THE VENUS 2 PROJECT? A PROJECT WITHOUT A ROAD MAP AND A DESTINATION GETS YOU TO AN UNKNOWN PLACE AT AN UNKNOWN TIME. There is no commitment to follow a product development process MAN-HOUR ESTIMATE WAS NOT CHANGED AFTER CUSTOMER REQUIREMENTS CHANGED PRODUCT REQUIRE-MENTS WERE NEVER FROZEN. (NOT EVEN FROZEN, THAWED, FROZEN,...) THERE WAS NO DEFINITION OF CUSTOMER OR PRODUCT REQUIREMENTS THERE WAS NO PRODUCT OR CUSTOMER ACCEPTANCE CRITERIA DOCUMENTED FOR THE ENGINEERING TEAM 50% OF THE CUSTOMER REQUIREMENTS WERE NOT KNOWN BY THE DESIGN TEAM DURING IMPLEMENTATION THERE WAS NO PRODUCT DEFINITION = Top Vote Getter = Second Vote Getter = Third Vote Getter ONLY 1 CUSTOMER WAS USED TO GATHER REQUIREMENTS FOR THE PRODUCT MARKETING WAS NOT INVOLVED DURING THIS PROJECT THIS WAS A CUSTOMER DRIVEN GENERIC PRODUCT PRODUCT REQUIREMENTS WERE NOT CLEARLY DEFINED NO TIME WAS SCHEDULED TO PROVIDE DOCUMENTATION TO APPLICATION WRITERS AS NEW PEOPLE WERE ADDED TO THE TEAM, PROJECT LEADERSHIP DID NOT PASS ON DESIGN OR FUNCTIONAL METHODS FORMALLY THE VENUS 2 SOFTWARE ARCHITECTURE IS NOT DOCUMENTED OUTSIDE OF THE CODE WE DID NOT PROVIDE TEAM MEMBERS WITH BASELINE PRODUCTS S/W KNOWLEDGE THERE IS NO METHOD FOR COMMUNICATING PRODUCT KNOWLEDGE NO COMMON SOFTWARE DEVELOPMENT PROCESS WAS USED DURING INTEGRATION WE HAD ONE TEST SETUP IN LIEU OF THREE NEEDED SHARING RESOURCES WITH HARDWARE ENGINEERS LIMITED SOFTWARE ENGINEER’S TEST TIME BY 20% OF WHAT WAS NEEDED THE APPLICATION INTERFACE WAS NOT FORMALLY REVIEWED PRIOR TO IMPLEMENTATION THERE WAS NO SOFTWARE DESIGN REVIEW FOR THE VENUS 2 MODULE FORMAL TESTING WAS NOT DONE AS COMPONENTS BECAME AVAILABLE NO COMMON DESIGN METHOD- OLOGY WAS USED ON THIS PROJECT THE DELIVERY DATE FOR HARDWARE LEFT ONLY 1.5 MONTHS FOR H/W - S/W INTEGRATION AND TESTING CUSTOMER ACCEP-TANCE TESTING WAS NOT SCHEDULED NO DEFECT DETECTION WAS DONE ON THE SOFTWARE DESIGN WE DID NOT TEST THE SYSTEM PRIOR TO SHIPMENT 1 HOUR OF TESTING WAS DONE WHEN 2 WEEKS WERE REQUIRED ADDITION OF CUSTOMER DEMO TO COMPRESSED SCHEDULE DIRECTLY REDUCED TESTING TIME NO FORMAL TESTING PROCESS WAS ALLOWED THERE WAS A LACK OF COMMITMENT TO TESTING THERE WAS INSUFFICIENT H/W AVAILABLE TO S/W
- 66. AGILE LEADERSHIP –SELECT BEST PRACTICES TO IMPLEMENT AGILE TEAMS – PERFORM AT END OF NEXT SPRINT Idea!
- 68. IN SUMMARY… Tidal Waveto Fountain – By Directing the Water
- 69. TCGen Inc. Menlo Park CA,94025 jcarter@tcgen.com +1 650 733-5310 Thank you, Agile COP And Agile COP Board of Directors