Agile vs. waterfall
Download as PPTX, PDF1 like1,707 views
The document discusses different project management methodologies like Waterfall, Agile, and Scaling Agile. It provides statistics showing Agile projects have a higher success rate than Waterfall projects. It then explains concepts like scrum, sprints, product owners, and scaling frameworks like SAFe and Spotify model to manage large programs and resources. Overall, the document advocates that most companies have adopted Agile and that readers should start implementing it to work in a faster, more agile and lean way.
More Related Content
Similar to Agile vs. waterfall (20)
Agile vs. waterfall
- 1. Waterfall, Agile & Scaling Agile Dvir Zohar – Simple CEO [email protected] Think Simple, Run Faster
- 2. Bottom Line 9 67 24 WATERFALL AGILE HYBRID Hi Tech & IT PM Methodology Deloitte survey 2016 72% of “Agile Firms” implement also Scaling Agile
- 3. Bottom Line (2) Standish report 2011-2015, over 10,000 technology projects Method Achieved Goals in Budget, in Time Achieved Goals Failed Agile 39% 52% 9% Waterfall 11% 60% 29%
- 4. The Waterfall Concept » Based on many years of experience » “Do it right the first time” » Long term view – Planning, SRS, DR’s, risk management… Time
- 5. PMBOK Matrix - Implementation Requires Discipline Knowledge Area Processes Initiating Process Group Planning Process Group Executing Process Group Monitoring &Controlling Process Group Closing Process Group Project Integration Management 4.1 Develop Project Charter 4.2 Develop Project Management Plan 4.3 Direct and Manage Project Execution 4.4 Monitor and Control Project Work 4.5 Perform Integrated Change Control 4.6 Close Project or Phase Project Scope Management 5.1 Collect Requirements 5.2 Define Scope 5.3 Create WBS 5.4 Verify Scope 5.5 Control Scope Project Time Management 6.1 Define Activities 6.2 Sequence Activities 6.3 Estimate Activity Resources 6.4 Estimate Activity Durations 6.5 Develop Schedule 6.6 Control Schedule Project Cost Management 7.1 Estimate Costs 7.2 Determine Budget 7.3 Control Costs Project Quality Management 8.1 Plan Quality 8.2 Perform Quality Assurance 8.3 Perform Quality Control Project Human Resource Management 9.1 Develop Human Resource Plan 9.2 Acquire Project Team 9.3 Develop Project Team 9.4 Manage Project Team Project Communications Management 10.1 Identify Stakeholders 10.2 Plan Communications 10.3 Distribute Information 10.4 Manage Stakeholders Expectations 10.5 Report Performance Project Risk Management 11.1 Plan Risk Management 11.2 Identify Risks 11.3 Perform Qualitative Risk Analysis 11.4 Perform Quantitative Risk Analysis 11.5 Plan Risk Responses 11.6 Monitor and Control Risks Project Procurement Management 12.1 Plan Procurements 12.2 Conduct Procurements 12.3 Administer Procurements 12.4 Close Procurements
- 6. Agile Drivers Quality (90’s) Vs. TTM (2000’s) Change – The only sure thing Complexity 6 1 32 Complexity TTM You can’t think of everything
- 7. Agile Principles » Happy customer – Value management, Feedback » Quantum mind set – Small iterations, Early values » Projects are about people - Many variables, motivation » Keep it simple 7
- 8. Agile Manifesto (2001) Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
- 9. SCRUM » Scrum teams » SPRINT – a focused effort for 7-30 days period » Sprint backlog – constantly reprioritized Do CheckAdjust Plan PDCA
- 10. SCRUM Elements New Roles » Product Owner » Scrum Master Ceremonies » Sprint planning » Daily standup meeting » Retrospective Simple Control » Boards » Backlog burndown
- 11. Implemented Elements 83 82 79 74 69
- 12. Agile for HW-SW Development • Customer • Short term iterations (Simulation, early prototypes, Sprints) • People engagement (Scrum ceremonies) • Simplicity (boards, planning) • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan HW-SW-QA Scrum teams
- 13. 13 Understanding Customer Real Needs (HW)
- 14. SCALING AGILE Scrum Team Scrum Team Scrum Team Scrum Team Scrum Team Scrum Team Lean, Fast, Agile
- 15. Scaling Agile Main Topics • Realistic commitment • Visibility for management • Large programs • Changes in portfolio • Resource load & Bottle necks • Sub contractors • Knowledge transfer
- 16. Strategic Management Tactic Management The SCALING AGILE Organization Scrum Team Scrum Team Scrum Team Scrum Team PM, PO, PMO, System
- 17. Scaling Agile Frameworks SoS 27% SAFe 23% LeSS Spotify Model Scrum @ Scale DaD
- 18. SAFe -Three Levels of Management Expand one level
- 19. Program Increment (PI) Planning (Every 8-12 weeks)
- 20. Synchronizes with PI Planning
- 21. Spotify Model • Since 2008 • 100M Users • $2 B Sales • - $200 M Profit • 8.5B$ Value (2015) • 1600 Employees
- 23. SQUADs » Mini STARTUP » Focus mission » SCRUM » Minimize the dependencies
- 24. TRIBE » Mini company » Squads with common missions » Till 100 employees
- 25. Chapter & Guilds
- 26. 32 Simple Tools UsersTool 30,000,000Jira 22,000,000MS Project 15,000,000BaseCamp 2,500,000Podio 1,700,000TeamWork 1,700,000Trello 1,500,000Smartsheet 1,300,000Wrike 1,250,000VersionOne 1,200,000Zoho 2015 Simple Tools • Collaboration • Visibility
- 27. Agile is simple But transformation is …
- 28. 1st Move: Steering Committee Vision, Road Map Leaders Workshops, Iterations Change Management
- 29. Fast, Agile, Lean Most companies decided (had) to implement AGILE you should start
- 30. Thanks !
Editor's Notes
- #10: 9-22
- #11: 10-22
- #20: So let's discuss the Lean-Agile principles that underlie SAFe. [Read through each of the principles on the slide] We don't have time in presentation to drill into each of these, but if you head down the SAFe journey, it will be important to learn why these principles are so critical to a successful implementation of SAFe. They are so important because principles trump practices. So if we're struggling with a practice, we're going to return to these basic principles to make sure that we're trying to build a system and an implementation that is as Lean and Agile as possible.
- #21: You can see that it's organized around teams—teams are the fundamental construct. Teams are the goose that lay our Agile golden egg, and we want to create teams and help them be and stay incented to do their best work. The Program Level, where a group of Agile Teams work together to deliver a larger solution, is indicated here. And of course the Customer is part of our Solution. This larger structure in the middle is the Agile Release Train, which I'll come back to in a second. The Agile Release Train is the organizational construct—typically virtual—that delivers solutions. ------ [Note: It is helpful to point out where each of the bolded items above are located on the slide when speaking to them.]
- #24: The ART truly takes a systems view. It brings together the people we need to deliver larger amounts of value. That includes our business owners, our representatives from the customers, product management, architecture, systems engineering, hardware, software, testing, people involved in manufacturing or deployment of our solution…. We create this virtual program. And the virtual program now has the skills they need. So the ART is cross-functional as well. And it typically contains about 50 to 125 people.
- #36: 35-22