Downloaded 48 times
Uploaded byDvir Zohar
Agile vs. waterfall simple 2017
The document discusses different project management methodologies like Waterfall, Agile, and hybrid approaches. It provides details on frameworks for scaling Agile like SAFe and LeSS. Studies have shown that Agile projects have a higher success rate of delivering on time and on budget compared to Waterfall. Scaling Agile involves frameworks to coordinate large programs involving multiple Agile teams through elements like program increment planning and aligning teams.
More Related Content
Similar to Agile vs. waterfall simple 2017
Agile vs. waterfall simple 2017
- 1. Waterfall, Agile &Scaling Agile Dvir Zohar – Simple CEO Dvir@SimpleDO.co.il Think Simple, Run Faster
- 2. Bottom Line 9 67 24 WATERFALL AGILEHYBRID Hi Tech & IT PM Methodology Deloitte survey 2016 82% of “Agile Firms” implement also Scaling Agile
- 3. Bottom Line (2) Standishreport 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 » Happycustomer – 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) Individualsand 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 8279 74 69
- 12. Agile for HW-SWDevelopment • 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.
- 14. Scaling Agile MainTopics • Realistic commitment • Visibility for management • Large programs • Changes in portfolio • Resource load & Bottle necks • Sub contractors • Knowledge transfer
- 15. Strategic Management Tactic Management TheSCALING AGILE Organization Scrum Team Scrum Team Scrum Team Scrum Team PM, PO, PMO, System
- 16. Scaling Agile Frameworks SoS 27% SAFe 23% LeSS SpotifyModel Scrum @ Scale DaD
- 17. SAFe -Three Levelsof Management Expand one level
- 18. Program Increment (PI)Planning (Every 8-12 weeks)
- 19. Synchronizes with PIPlanning
- 20. Spotify Model • Since2008 • 100M Users • $2 B Sales • - $200 M Profit • 8.5B$ Value (2015) • 1600 Employees
- 21.
- 22. SQUADs » Mini STARTUP »Focus mission » SCRUM » Minimize the dependencies
- 23. TRIBE » Mini company »Squads with common missions » Till 100 employees
- 24.
- 25. 31 Simple Tools UsersTool 30,000,000Jira 22,000,000MSProject 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
- 26. Agile is simple Buttransformation is …
- 27. 1st Move: SteeringCommittee Vision, Road Map Leaders Workshops, Iterations Change Management
- 28. Fast, Agile, Lean Mostcompanies decided (had) to implement AGILE you should start
- 29.
Editor's Notes
- #10 9-22
- #11 10-22
- #19 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.
- #20 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.]
- #23 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.
- #35 34-22