Agile Project Management for Elearning Instructional Design (mLearnCon 2015)
•
21 j'aime•2,353 vues
Megan Torrance's presentation from mLearnCon 2015, Austin, TX. This is the overview presentation for TorranceLearning's LLAMA project management - the Lot Like Agile Management Approach - in which we adopt the best of the software world's Agile project management and combine it with solid instructional design techniques.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Agile Project Management for Elearning Instructional Design (mLearnCon 2015)
Similaire à Agile Project Management for Elearning Instructional Design (mLearnCon 2015) (20)
Plus de TorranceLearning
Plus de TorranceLearning (20)
Dernier
Dernier (20)
Agile Project Management for Elearning Instructional Design (mLearnCon 2015)
- 1. © Megan Torrance | Agile Project Management for Elearning Development Megan Torrance mtorrance@torrancelearning.com Agile Project Management for Elearning Development
- 2. © Megan Torrance | Agile Project Management for Elearning Development Megan Torrance mtorrance@torrancelearning.com @MMTorrance linkedin.com/in/megantorrance
- 3. © Megan Torrance | Agile Project Management for Elearning Development
- 4. © Megan Torrance | Agile Project Management for Elearning Development Think about your best project ever.
- 5. © Megan Torrance | Agile Project Management for Elearning Development "Do more of what works, and do less of what doesn't." Kent Beck, author of Extreme Programming (XP) Explained
- 6. © Megan Torrance | Agile Project Management for Elearning Development How do you manage projects now? Agile (online or analog) MS Project / Gantt Charts / SharePoint Excel / Word / PowerPoint We don’t really “manage” projects per se
- 7. © Megan Torrance | Agile Project Management for Elearning Development
- 8. © Megan Torrance | Agile Project Management for Elearning Development Projects need to keep up with an ever- increasing rate of change.
- 9. © Megan Torrance | Agile Project Management for Elearning Development ANALYZE DESIGN DEVELOP IMPLEMENT EVALUATE
- 10. © Megan Torrance | Agile Project Management for Elearning Development It's folly to assume that the client knows everything they want at the beginning of the project. Any set of meaningful requirements is subject to change.
- 11. © Megan Torrance | Agile Project Management for Elearning Development The first day of a project is the worst day to plan what the end product will be (and how much it will cost).
- 12. © Megan Torrance | Agile Project Management for Elearning Development If we do not come up with a brilliant idea that might change things mid- project, we're not fully engaged creatively.
- 13. © Megan Torrance | Agile Project Management for Elearning Development Every day you learn something new about the project you're working on.
- 14. © Megan Torrance | Agile Project Management for Elearning Development ANALYZE DESIGN DEVELOP IMPLEMENT EVALUATE
- 15. © Megan Torrance | Agile Project Management for Elearning Development A D I/E D I/E D DD D
- 16. © Megan Torrance | Agile Project Management for Elearning Development Tip #1: Create a PLP (Primary Learner Persona)
- 17. © Megan Torrance | Agile Project Management for Elearning Development 17
- 18. © Megan Torrance | Agile Project Management for Elearning Development
- 19. © Megan Torrance | Agile Project Management for Elearning Development Tip #2: Define Scope in Stories
- 20. © Megan Torrance | Agile Project Management for Elearning Development Stories capture business needs and performance outcomes in a format that's useful for planning & production.
- 21. © Megan Torrance | Agile Project Management for Elearning Development As a I want so I can
- 22. © Megan Torrance | Agile Project Management for Elearning Development
- 23. © Megan Torrance | Agile Project Management for Elearning Development
- 24. © Megan Torrance | Agile Project Management for Elearning Development LLAMA: Use Cathy Moore's Action Mapping to define stories for Agile learning projects.
- 25. © Megan Torrance | Agile Project Management for Elearning Development How familiar are you with Cathy Moore’s work? I am Cathy Moore. Love it. Use action mapping all the time. I’ve heard of her but don’t know much about action mapping at all. I have no idea who Cathy Moore is.
- 26. © Megan Torrance | Agile Project Management for Elearning Development
- 27. © Megan Torrance | Agile Project Management for Elearning Development ! Act! ! Respond! ! Decide! ! Create! ! Build! Practice Know . . . Business Goal that solves a Business Problem Adapted from: Cathy Moore
- 28. © Megan Torrance | Agile Project Management for Elearning Development Tip #3: Estimate the work in small batches And do so fearlessly
- 29. © Megan Torrance | Agile Project Management for Elearning Development
- 30. © Megan Torrance | Agile Project Management for Elearning Development Rules for Estimating: Estimate based on what you think it will take to do the work, with no padding.
- 31. © Megan Torrance | Agile Project Management for Elearning Development An estimate is just that. An estimate.
- 32. © Megan Torrance | Agile Project Management for Elearning Development Tip #4: Plan the Work Visibly
- 33. © Megan Torrance | Agile Project Management for Elearning Development Define at the outset what type of project this is.
- 34. © Megan Torrance | Agile Project Management for Elearning Development Define at the outset what type of project this is. iStockphoto.com/4689051
- 35. © Megan Torrance | Agile Project Management for Elearning Development Organize the project overall in terms of (bi)weekly goals on a big, visible board.
- 36. © Megan Torrance | Agile Project Management for Elearning Development
- 37. © Megan Torrance | Agile Project Management for Elearning Development
- 38. © Megan Torrance | Agile Project Management for Elearning Development
- 39. © Megan Torrance | Agile Project Management for Elearning Development Organize weekly work by day and team member.
- 40. © Megan Torrance | Agile Project Management for Elearning Development
- 41. © Megan Torrance | Agile Project Management for Elearning Development
- 42. © Megan Torrance | Agile Project Management for Elearning Development Use colors to indicate status on cards.
- 43. © Megan Torrance | Agile Project Management for Elearning Development Tip #5: Plan for Iterative Experiments Lather, Rinse, Repeat.
- 44. © Megan Torrance | Agile Project Management for Elearning Development How iterative is your development work? We run in full-on Agile, SAM, or rapid prototyping style development. We’re experimenting. We do a standard alpha beta gold approach Iterative development would never fly around here. It’s got to be perfect or it will never see the light of day.
- 45. © Megan Torrance | Agile Project Management for Elearning Development Make small mistakes faster. Skip the big mistakes. Agile Explained, Menlo Innovations
- 46. © Megan Torrance | Agile Project Management for Elearning Development A D I/E D I/E D DD D Iteration 1 Iteration 2 Iteration 3
- 47. © Megan Torrance | Agile Project Management for Elearning Development
- 48. © Megan Torrance | Agile Project Management for Elearning Development
- 49. © Megan Torrance | Agile Project Management for Elearning Development
- 50. © Megan Torrance | Agile Project Management for Elearning Development
- 51. © Megan Torrance | Agile Project Management for Elearning Development
- 52. © Megan Torrance | Agile Project Management for Elearning Development
- 53. © Megan Torrance | Agile Project Management for Elearning Development The Minimum Viable Product M.V.P.
- 54. © Megan Torrance | Agile Project Management for Elearning Development Why? You always have something usable. You catch errors early. You don’t get too far off track. It’s easier to estimate. It’s psychologically way more satisfying.
- 55. © Megan Torrance | Agile Project Management for Elearning Development td.org/agilellama Megan Torrance mtorrance@torrancelearning.com @MMTorrance linkedin.com/in/megantorrance
Notes de l'éditeur
- [lay this out as a question card, with supporting cards, on the table before class]
- Things are changing faster than ever before, and the rate of change is exponential. This change is being driven by: New hardware and platforms New software and tools Globalization and localization New development tools Greater complexity (volatility, uncertainty, complexity and ambiguity, VUCA) Post-recession continuing cost pressures Increasing ROI pressure
- But what happens when change happens AFTER it’s supposed to?
- In any project of any size or complexity (in any project really worth doing), the client or sponsor really often only knows what they want after they've seen the first version. Then they can really hone in on what they want and what they need. Then the requirements shift and change as the project comes closer to each release. Where do these changes come from? They come from shifting business needs, priorities, new tools & technologies, new ideas. Said differently: Any set of meaningful requirements is subject to -- and should! -- change.
- This doesn’t mean that EVERY new idea – squirrel! – is pursued.
- ... something that will help you estimate a project scope, cost and completion date with much more clarity.
- But what happens when change happens AFTER it’s supposed to?
- A learner persona = fictitious future learner And a valuable member of your team!
- They define scope. They are meaningful to sponsors and users. When we use Action Mapping to define stories, we then tie them to actual performance outcomes of the project.
- This covers the WHO, WHAT and WHY aspects of design.
- Small = 65 Medium = 235 Large = 579
- Every project is one (or maybe two) type of project. Knowing which one it is is critical to making project planning decisions. Fixed budget projects have no wiggle room to spend more money or time, even if it means we cut out functionality. You'll see this in strict budget-focused organizations and grant-funded projects, for example. Fixed time projects have to be completed by a certain date. Sometimes that means that functionality gets cut. Sometimes it means that we add resources to the team to get things done. But the date is the date. You'll see this in projects that are or that support other well-publicized milestones. Fixed scope projects are worked until they are completed. Sometimes that means that you need to spend more time or more budget completing them, but they've got to be right and complete in order to be of any value. These tend to be the rarest of the three.
- Every project is one (or maybe two) type of project. Knowing which one it is is critical to making project planning decisions. Fixed budget projects have no wiggle room to spend more money or time, even if it means we cut out functionality. You'll see this in strict budget-focused organizations and grant-funded projects, for example. Fixed time projects have to be completed by a certain date. Sometimes that means that functionality gets cut. Sometimes it means that we add resources to the team to get things done. But the date is the date. You'll see this in projects that are or that support other well-publicized milestones. Fixed scope projects are worked until they are completed. Sometimes that means that you need to spend more time or more budget completing them, but they've got to be right and complete in order to be of any value. These tend to be the rarest of the three.
- The high level planning board has a column for each (sub)project, and row for each week. Each week or so represents a goal (a sprint).The series of sprints (releases) follow the phase-wise plan for the project as a whole. Weekly planning boards should be to meet the big board sprint/release goals.Color-coded cards can be used to signal project starts, major releases and other important dates.
- The weekly planning board has a column for each team member, and row for each day of the week. The weekly board: - Starts on the planning day (which doesn't have to be Monday), - Shows all the (work)days of the week as horizontal rows - Shows vertical swim lanes for each team member's assignment - Displays all standing activities (weekly client check-in, staff meetings, etc.) and all tasks authorized for the week - Includes a row for "pull ahead" cards (cards that have been authorized but don't naturally fit into this week) - Allows for easy access to stickers, push pins, cards, etc. for planning.
- Sticker dots make for great status tracking on each card. Use the approach that works best for your situation. A traditional Agile approach Yellow = started Orange = ready to test Green = tested and ready for client Red = blocked Black = cancelled At TorranceLearning we use this: Yellow = started Green = completed and ready for clientBlue = awaiting clientRed = emergency
- http://objectivesoftwaresolutions.com/content/iterative-development-model txweb-design.com http://www.dcon.com.br/jd.comment/articles/notes-java/15principles_and_practices/iterative/30Interative-incremental-dev.html http://jasonunes.blogspot.com/2008_04_01_archive.html http://www.abreit.com.au/Services/SoftwareDevelopment
- http://objectivesoftwaresolutions.com/content/iterative-development-model txweb-design.com http://www.dcon.com.br/jd.comment/articles/notes-java/15principles_and_practices/iterative/30Interative-incremental-dev.html http://jasonunes.blogspot.com/2008_04_01_archive.html http://www.abreit.com.au/Services/SoftwareDevelopment
- http://objectivesoftwaresolutions.com/content/iterative-development-model txweb-design.com http://www.dcon.com.br/jd.comment/articles/notes-java/15principles_and_practices/iterative/30Interative-incremental-dev.html http://jasonunes.blogspot.com/2008_04_01_archive.html http://www.abreit.com.au/Services/SoftwareDevelopment
- http://objectivesoftwaresolutions.com/content/iterative-development-model txweb-design.com http://www.dcon.com.br/jd.comment/articles/notes-java/15principles_and_practices/iterative/30Interative-incremental-dev.html http://jasonunes.blogspot.com/2008_04_01_archive.html http://www.abreit.com.au/Services/SoftwareDevelopment
- You always have a running version of the program, eg, if you run out of time, you can deliver the last iteration, which may not have all functionality, but it does something. This is usually worth more to your instructor than a program which doesn't even compile yet. It helps identify the source of the last error (compilation or execution), because you know it's in the code you just added in this iteration. This makes finding bugs much faster. It's psychologically more satisfying to get positive feedback on your work, ie, a running program. Corrections early in development generally take less time than later in the development process.