PMI is NOT the enemy
•
6 j'aime•1,381 vues
Agile and Waterfall: how to be good neighbours: find a common language
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (17)
Similaire à PMI is NOT the enemy
Similaire à PMI is NOT the enemy (20)
Plus de Silvana Wasitova, Scrum & Agile Coach
Plus de Silvana Wasitova, Scrum & Agile Coach (10)
Dernier
Dernier (20)
PMI is NOT the enemy
- 1. PMI is NOT the Enemy: How to be "Good Neighbours" with the Traditionalists Service Knowledge Result ALE Bathtub Conference 6 December 2011 Silvana Wasitova, PMP, CSP
- 2. About me PMI Member since 1998 PMP 2002 President of PMI Silicon Valley, 2004 Scrum Practitioner 2005 Certified Scrum Master 2007 Scrum Coach & Trainer since 2009
- 3. PMI – Project Management Institute Often portrayed as… George Coghill Cartoons www.how-to-draw-funny-cartoons.com 3
- 4. What is World’s largest not-for-profit professional association for Project Managers Founded in 1969 Now: Over half a million members, 185 countries Multiple industries, from construction to software dev. PMP certification since 1984, 370,000 holders now 4 © Itecor all rights reserved
- 5. January 2010 Agile processes have not only gained increasing adoption levels; they have also rapidly joined the mainstream of development approaches. And while more organizations are adapting to Agile conventions, Agile is also adapting to the workplace. Perhaps the clearest sign of the mainstreaming of Agile is the abandonment of orthodoxy: Teams are puzzling out the mix of methodologies and combining them to fit within their organizational realities, blending Agile and non-Agile techniques and practices to create a hybrid methodology that fits larger organizations. …. It's time for software development professionals to stop sitting on the fence where Agile is concerned. According to those who have successfully adopted Agile, the benefits are well worth the effort, and with the recent dramatic increase in Agile adoption, the probability of working in or with an Agile team has increased for everyone.
- 6. QSM: Quality Software Management 2008 6 © Itecor all rights reserved
- 7. 7 © Itecor all rights reserved
- 8. Definition of Success Has Changed Functionality 85% respondents consider it more important to meet stakeholder needs, even if they changed Quality: 82% consider it more important to deliver high quality than delivering on time and within Money 70% consider best ROI more important than under budget Source: Software Development Projects Success, IBM, Scott Ambler, 2008 8 © Itecor all rights reserved
- 9. Good Resource for the Traditionalists Michelle Sliger and Stacia Broderick: Identifies common lingo Helps “translate” the concepts 9 © Itecor all rights reserved
- 10. 3 MONTHS Scrum vs. Waterfall: Time To Market Faster Time to Market Higher Quality Scrum Satisfied Customer Collaborative Spec Develop & QA Results-Oriented 6-10 MONTHS 9 weeks Waterfall 3 months Spec Develop & QA Updates 12 weeks 3-6 wks x wks y wks 6-10 months Sequential © Silvana Wasitova Process-Oriented
- 11. 11 © Itecor all rights reserved
- 12. Agile deals with Ziv’s Law • Specifications will never be fully understood Humphrey’s • The user will never be sure of what they want Law until they see the system in production (if then) Wegner’s • An interactive system can never be fully Lemma specified, nor can it ever be fully tested Langdon’s • Software evolves more rapidly as it approaches Lemma chaotic regions (without spilling into chaos) 12 © Itecor all rights reserved
- 13. Good Neighbour
- 16. SURPRISE Agile practices are aligned with PMBOK process groups: initiating, planning, executing, monitoring, controlling, closing In each iteration: Planning, executing, monitoring, controlling Manage scope, time, cost and quality
- 17. Agile & Waterfall - Comparison Source: Michelle Sliger, PMI Global Congress 2008
- 18. Agile & Waterfall - Comparison Source: Michelle Sliger, PMI Global Congress 2008
- 19. Agile & Waterfall - Comparison Source: Michelle Sliger, PMI Global Congress 2008
- 20. Agile & Waterfall - Comparison Source: Michelle Sliger, PMI Global Congress 2008
- 21. Fundamental Difference instead 21
- 22. Silvana Wasitova, PMP, CSM, CSP Itecor.com Vevey, Switzerland s.wasitova@itecor.com +41 79 558 05 09 slideshare.com/wasitova 22
- 23. References Michelle Sliger, PMI Global Congress 2008 – http://www.slideshare.net/VersionOne/agile-project-management-for-pmps http://www.infoq.com/presentations/Agile-in-the-Waterfall-Enterprise-Michele-Sliger Forrester - http://www.forrester.com/rb/Research/agile_development_mainstream_adoption_has _changed_agility/q/id/56100/t/2 Scott Ambler, Software Development Projects Success, 2008 PMI - 23
Notes de l'éditeur
- Stay flexible by reducing obstacles to changeChange is your best friend. The more expensive it is to make a change, the less likely you'll make it. And if your competitors can change faster than you, you're at a huge disadvantage. If change gets too expensive, you're dead.EmergenceEmergence is one of the founding principles of agility, and is the closest one to pure magic. Emergent properties aren't designed or built in, they simply happen as a dynamic result of the rest of the system. "Emergence" comes from middle 17th century Latin in the sense of an "unforeseen occurrence." You can't plan for it or schedule it, but you can cultivate an environment where you can let it happen and benefit from it.A classic example of emergence lies in the flocking behavior of birds. A computer simulation can use as few as three simple rules (along the lines of "don't run into each other") and suddenly you get very complex behavior as the flock wends and wafts its way gracefully through the sky, reforming around obstacles, and so on. None of this advanced behavior (such as reforming the same shape around an obstacle) is specified by the rules; it emerges from the dynamics of the system.Simple rules, as with the birds simulation, lead to complex behavior. Complex rules, as with the tax law in most countries, lead to stupid behavior.Many common software development practices have the unfortunate side effect of eliminating any chance for emergent behavior. Most attempts at optimization — tying something down very explicitly — reduces the breadth and scope of interactions and relationships, which is the very source of emergence. In the flocking birds example, as with a well-designed system, it's the interactions and relationships that create the interesting behavior.The harder we tighten things down, the less room there is for a creative, emergent solution. Whether it's locking down requirements before they are well understood or prematurely optimizing code, or inventing complex navigation and workflow scenarios before letting end users play with the system, the result is the same: an overly complicated, stupid system instead of a clean, elegant system that harnesses emergence.Keep it small. Keep it simple. Let it happen.—Andrew Hunt, The Pragmatic Programmers
- BIGGER THAN ANY OF US can do aloneWhat must we do together that is bigger then any of us, requires all of us, and none of us can claim individual victory until it is done?Assume personal responsibility for the success of the team.The more members feel a sense of ownership for the entire team, the more likely good team-building things will happen.TOP Step1: Build shared clarity about the task (and keep pointing to it as the reason for the team). This is the single greatest lever for team-building. Feeling a sense of positive interdependence (i.e., you moving your work forward helps me accomplish mine) or “being in the same boat together” drives a natural shift in behavior toward helpfulness and trust.
- PMBOK Processes
- http://www.microsoft.com/downloads/details.aspx?familyid=AE7E07E8-0872-47C4-B1E7-2C1DE7FACF96