Embracing Change With Agility
•Télécharger en tant que PPTX, PDF•
2 j'aime•689 vues
An overview of how Agile can better manage change in projects
Recommandé
Recommandé
Contenu connexe
En vedette
En vedette (7)
Similaire à Embracing Change With Agility
Similaire à Embracing Change With Agility (20)
Embracing Change With Agility
- 1. Embracing Change with Agility Ron Whitebread, CSM, PMP Image © www.anotherurl.com/travel/Wales/diary.asp
- 2. In a perfect world... Planning Build Testing Demo & Deliver
- 3. In a perfect world... Planning Build Testing Demo & Deliver Change Management?
- 4. Current reality... Planning Build Testing Demo & Deliver Change
- 5. Current reality... Planning Build Testing Demo & Deliver Change Management?
- 6. Changing reality... Planning Build Testing Demo & Deliver Change Management?
- 7. Agile beginnings... Software development Frequently changing Time-to-market critical
- 9. Release Burndown 350 300 Story Points 250 200 Target 150 Actual 100 50 0 0 1 2 3 4 5 Sprint Sprint Burndown 1,600 1,400 1,200 1,000 Hours 800 600 400 200 0 Image © www.anotherurl.com/travel/Wales/diary.asp
- 12. Actual Use of Requested Features 7% 13% 45% Always Often 16% Sometimes Rarely 19% Never The Standish Group International Inc. 2002 Image © www.anotherurl.com/travel/Wales/diary.asp
- 18. Project A new Agile reality... Charter Sprint review & Daily standup retrospective Product backlog (user stories) Sprint backlog Sprint (2-4 week Potentially iteration) shippable product Sprint planning increment Prioritization
- 19. Replacing this... Planning Build Testing Demo & Deliver
- 20. Replacing this... Planning Build Testing with this... Demo & Deliver until “DONE”
- 22. Project A new Agile reality... Charter Sprint adjustments Sprint review & Daily standup retrospective Product backlog (user stories) Sprint backlog Sprint (2-4 week Potentially iteration) shippable product Sprint planning increment Additions/subtractions/ modifications Change Management? Reprioritization
- 26. Agile references (web sites) Overview of Agile development - http://www.versionone.com/Agile101/Agile_Development.asp The Agile Manifesto – http://www.agilemanifesto.org/ The Agile Alliance – http://agilealliance.org/ The Scrum Alliance – http://scrumalliance.org/ Agile Project Leadership Network (APLN) Houston chapter – http://www.aplnhouston.org/ • You can also Google topics like Agile, Scrum, etc. • There are also apps for iPhone, Android such as planning poker
- 27. Agile references (books) “Agile Project Management with Scrum” Ken Schwaber “The Software Project Manager’s Bridge to Agility” Michele Sliger “Agile Project Management: Creating Innovative Products “ Jim Highsmith “Succeeding With Agile: Software Development Using Scrum” “Agile Estimating and Planning” “User Stories Applied: For Agile Software Development” Mike Cohn “Agile Retrospectives: Making Good Teams Great” Esther Derby, Diana Larsen, and Ken Schwaber
- 28. Embracing Change with Agility Ron Whitebread, CSM, PMP Image © www.anotherurl.com/travel/Wales/diary.asp
Notes de l'éditeur
- Winds of change blowing your project off track?
- How PMs would like to control change on a project - change not likely, or change-proof the project!
- How PMs would like to control change on a project - change not likely, or change-proof the project!
- Change occurs (or threatens) through all stages of project – how to manage?
- How we currently “manage” - Change processes, request forms, Impact assessments, approvals, add up to delays
- Replace command and control mindset – with one of inspect and adapt
- Agile was born out of software development industry based on difficult challenges including: getting your new software out before competitor does, making yours redundant or obsolete, and constant change due to internal/external factors such as not knowing exactly what the end result should look like, and what is happening in marketplace
- Team is self-organizing around planning and executing work using guidelines and priorities (servant leadership) – they are not handed “tasks” to accomplish according to schedule.Customer should be engaged all during project instead of just start and endProgress (or lack of it) is made visible to everyone (no hiding or guessing % done) – post “burndown” charts showing work done/not doneEstimation done at high level initially to relatively “size” project effort without detailed estimation process (using story points, planning poker)Waste - Really just maximizes “work not done” (Standish CHAOS report)Would not deliver most of the Never and Rarely used featuresPlanning occurs at start, and at key events throughout project instead of all upfront
- Team is self-organizing around planning and executing work using guidelines and priorities (servant leadership) – they are not handed “tasks” to accomplish according to schedule.Customer should be engaged all during project instead of just start and endProgress (or lack of it) is made visible to everyone (no hiding or guessing % done) – post “burndown” charts showing work done/not doneEstimation done at high level initially to relatively “size” project effort without detailed estimation process (using story points, planning poker)Waste - Really just maximizes “work not done” (Standish CHAOS report)Would not deliver most of the Never and Rarely used featuresPlanning occurs at start, and at key events throughout project instead of all upfront
- Team is self-organizing around planning and executing work using guidelines and priorities (servant leadership) – they are not handed “tasks” to accomplish according to schedule.Customer should be engaged all during project instead of just start and endProgress (or lack of it) is made visible to everyone (no hiding or guessing % done) – post “burndown” charts showing work done/not doneEstimation done at high level initially to relatively “size” project effort without detailed estimation process (using story points, planning poker)Waste - Really just maximizes “work not done” (Standish CHAOS report)Would not deliver most of the Never and Rarely used featuresPlanning occurs at start, and at key events throughout project instead of all upfront
- Team is self-organizing around planning and executing work using guidelines and priorities (servant leadership) – they are not handed “tasks” to accomplish according to schedule.Customer should be engaged all during project instead of just start and endProgress (or lack of it) is made visible to everyone (no hiding or guessing % done) – post “burndown” charts showing work done/not doneEstimation done at high level initially to relatively “size” project effort without detailed estimation process (using story points, planning poker)Waste - Really just maximizes “work not done” (Standish CHAOS report)Would not deliver most of the Never and Rarely used featuresPlanning occurs at start, and at key events throughout project instead of all upfront
- Scrum is most well known and widely used, though there are many others which share many of the key aspects
- Scrum is most well known and widely used, though there are many others which share many of the key aspects
- Briefly describe roles
- Product backlog – user stories on Post-Its or 3x5 cards (As a <> I would like to <> so that <>); use story points, planning poker to gauge relative size (time/cost) of project without detailed planning; product owner will prioritize Sprint planning – team plans work for next phase using priorities, feedback from retrospective, velocity for next sprint, etc.
- When are we done? When owner says we are, not necessary at end of “schedule” or budget. Remember – maximize work not being done!
- When are we done? When owner says we are, not necessary at end of “schedule” or budget. Remember – maximize work not being done!
- How does this incorporate change?
- Change only permitted at beginning of new sprint planning session. IF forced during Sprint, cancel Sprint, and re-plan a new Sprint instead of continuing current one.
- Classic (“safe” projects) vs. Agile (“uncertainty” and changing projects) drivers
- Cultural change – “not your father’s PM” – overcoming bias for traditionAcceptance of self-organizing team leadership, not PMTeam takes ownership of assignments, problem solving and is held accountable/visiblePlanning approach is tiered high level, then “just enough” detailed to keep movingDocumentation can be done as work is completed to capture what was done, not what should have been done before you start
- Winds of change always blowing – use your creativity and imagination to find ways to use Agile in non-software projects – where appropriate
- Questions?