Be it
1. An LMS customization and implementation
2. A new Product Creation
3. An e-Learning course development
SCRUM snugs well in all e-Learning implementations.This post is to iterate my thoughts on #3 above.
Most e-Learning course development contain inherent ability to package and publish the output as a SCORM package. For this post, I wish to request my readers to understand SCORM as a course asset model that allows to slice and dice courses into independent small size units called as "SCOs". SCOs have a great importance in reusability, durability and configuration across multiple learner groups and can be packaged across multiple learning modules. This is the benefit of SCORM apart from making it available across multiple LMS that support the specifications by allowing interactions between the courses and LMS. SCORM makes for a great way for course designers to think in terms of packaging and easy access.
Where SCORM does not specify a way of execution, SCRUM fills the gap to showcase that execution of SCOs in Sprints makes for a better experience for clients and project teams alike.
e-Learning course development mostly follow a flavored variation of ADDIE model (which is likened to waterfall software development). My experience, thus far, has been that Instruction and Visual Designers thinking is always top-down ("AD" phase in ADDIE). Think of course at large, break it down as MLT (Module-Lesson-Topic) structure and then define SCO level. Then start work at SCO level based on templates, guidelines defined at high level. This is not wrong at all. This has been working well, so long until SCRUM changes the paradigm.
Top-Down design thinking has its merits. You define consistent writing styles, Instructional approaches for content treatment, color palettes, Interface elements, determine the navigation flows and drill down from overall business objectives to atomic level terminal objectives. This established upfront leaves developers and writers to publish courses with ease.
In this approach, when you request for a change to better, it becomes a limiting factor. What is good to digress becomes a one-off case or a work around. What is the ideal treatment style suited to a particular SCO, becomes a change request if not factored in the earlier design phase. What is required as a logical extension but not factored in earlier analysis phase becomes phase 2 or version 2 of the project. For larger implementations, beyond 3-4 months, a stagnant document driving the development suffers from dull teams executing with hand and not with brains. In many cases, the relevance becomes obsolete.
Every designer knows that although you arrive at design using a top-down approach (if done so), it is always an aggregation from bottom-up that makes real sense. A collection of terminal objectives satisfy a learning objective, a collection of learning objectives satisfy a business objective. We call them "Roll Up" objectives. From course standpoint too it is an aggregation model that makes meaning for ROI to training managers. Consumption and mandatory access of learning units aggregates to determine the project priorities and these in turn define the budgets for training. (However, still budgeting is a yearly top-down affair).
The definition of SCOs is left to course designers way of sizing the content and many a times based on the limitations of LMS/business requirements within confines of SCORM. So designers either get to treat the entire course as SCO or a Module or really treat small topical units as SCO. In practice, there is no right or wrong approach in determining what is considered to be a SCO.
Consider the case of users and learners for whom the whole industry strives for best experience. Users knowledge is an aggregation of multiple learning units and past experience and learning that lets them perform better. It never happens to have a direct one to one correlation between learning a course and improvement in performance. It is an aggregation of learning from multiple sources that aids and betters performance. It is multiple insights from learning and their application that a job gets executed well.
SCRUM comes around as a more meaningful approach towards design thinking and sizing of SCOs. The primary reason is that SCRUM at its fundamental level delivers value by aggregation. A collection of user stories determines a SPRINT, Every SPRINT delivers a shippable product. A collection of SPRINTS allow for successive iterations towards the desired goals. Every Feature is prioritized and iterated in multiple SPRINTS thereby delivering maximum value while keeping overall vision in mind.
For commissioning any project, you need to have an intent (Vision) at highest level. But beyond that, every big thought is written down and broken down to finer details as shared (user) stories. (in e-Learning terms SCOed). This allows for better design thinking at shared (user) story/SCO level and applying the patterns common across SCOs/user stories that unifies than homogenize the entire course.
Thus when SCORM meets SCRUM you get to see an exceptional output which retains the localized and unique customizations required at SCO level, while larger part of design is driven by commonalities across SCO units. So instead of homogenizing SCOs as is done in top-down version, thereby bringing in monotony in treatment, you get to unify by applying designs that work at SCO levels, making SCOs truly stand alone as an independent package.
Does this mean each shared (user) story is a SCO. Possibly yes. But the flexibility is at designers desk. However, common sense dictates that you will not make a larger SCO than user stories.
I am realizing the merits of this approach in my current assignment. Looking at design parameters at SCO level and rolling it up, gives far greater freedom to designers, writers, producers to improvise on the final output quality. SCO is the access point where users spend most of their time. This is where they will make opinions on your work. This is the moment of truth for users to get maximum worth for their time. This is what business managers will eventually learn that their benefits are derived. Hence focusing on them that SCRUM greatly emphasizes on, is a better approach.
Welcome SCRUM to your e-Learning projects development and am sure of far greater productivity, happy development teams, clients and users.
Let me know your SCRUM and SCORM story.
1. An LMS customization and implementation
2. A new Product Creation
3. An e-Learning course development
SCRUM snugs well in all e-Learning implementations.This post is to iterate my thoughts on #3 above.
Most e-Learning course development contain inherent ability to package and publish the output as a SCORM package. For this post, I wish to request my readers to understand SCORM as a course asset model that allows to slice and dice courses into independent small size units called as "SCOs". SCOs have a great importance in reusability, durability and configuration across multiple learner groups and can be packaged across multiple learning modules. This is the benefit of SCORM apart from making it available across multiple LMS that support the specifications by allowing interactions between the courses and LMS. SCORM makes for a great way for course designers to think in terms of packaging and easy access.
Where SCORM does not specify a way of execution, SCRUM fills the gap to showcase that execution of SCOs in Sprints makes for a better experience for clients and project teams alike.
e-Learning course development mostly follow a flavored variation of ADDIE model (which is likened to waterfall software development). My experience, thus far, has been that Instruction and Visual Designers thinking is always top-down ("AD" phase in ADDIE). Think of course at large, break it down as MLT (Module-Lesson-Topic) structure and then define SCO level. Then start work at SCO level based on templates, guidelines defined at high level. This is not wrong at all. This has been working well, so long until SCRUM changes the paradigm.
Top-Down design thinking has its merits. You define consistent writing styles, Instructional approaches for content treatment, color palettes, Interface elements, determine the navigation flows and drill down from overall business objectives to atomic level terminal objectives. This established upfront leaves developers and writers to publish courses with ease.
In this approach, when you request for a change to better, it becomes a limiting factor. What is good to digress becomes a one-off case or a work around. What is the ideal treatment style suited to a particular SCO, becomes a change request if not factored in the earlier design phase. What is required as a logical extension but not factored in earlier analysis phase becomes phase 2 or version 2 of the project. For larger implementations, beyond 3-4 months, a stagnant document driving the development suffers from dull teams executing with hand and not with brains. In many cases, the relevance becomes obsolete.
Every designer knows that although you arrive at design using a top-down approach (if done so), it is always an aggregation from bottom-up that makes real sense. A collection of terminal objectives satisfy a learning objective, a collection of learning objectives satisfy a business objective. We call them "Roll Up" objectives. From course standpoint too it is an aggregation model that makes meaning for ROI to training managers. Consumption and mandatory access of learning units aggregates to determine the project priorities and these in turn define the budgets for training. (However, still budgeting is a yearly top-down affair).
The definition of SCOs is left to course designers way of sizing the content and many a times based on the limitations of LMS/business requirements within confines of SCORM. So designers either get to treat the entire course as SCO or a Module or really treat small topical units as SCO. In practice, there is no right or wrong approach in determining what is considered to be a SCO.
Consider the case of users and learners for whom the whole industry strives for best experience. Users knowledge is an aggregation of multiple learning units and past experience and learning that lets them perform better. It never happens to have a direct one to one correlation between learning a course and improvement in performance. It is an aggregation of learning from multiple sources that aids and betters performance. It is multiple insights from learning and their application that a job gets executed well.
SCRUM comes around as a more meaningful approach towards design thinking and sizing of SCOs. The primary reason is that SCRUM at its fundamental level delivers value by aggregation. A collection of user stories determines a SPRINT, Every SPRINT delivers a shippable product. A collection of SPRINTS allow for successive iterations towards the desired goals. Every Feature is prioritized and iterated in multiple SPRINTS thereby delivering maximum value while keeping overall vision in mind.
For commissioning any project, you need to have an intent (Vision) at highest level. But beyond that, every big thought is written down and broken down to finer details as shared (user) stories. (in e-Learning terms SCOed). This allows for better design thinking at shared (user) story/SCO level and applying the patterns common across SCOs/user stories that unifies than homogenize the entire course.
Thus when SCORM meets SCRUM you get to see an exceptional output which retains the localized and unique customizations required at SCO level, while larger part of design is driven by commonalities across SCO units. So instead of homogenizing SCOs as is done in top-down version, thereby bringing in monotony in treatment, you get to unify by applying designs that work at SCO levels, making SCOs truly stand alone as an independent package.
Does this mean each shared (user) story is a SCO. Possibly yes. But the flexibility is at designers desk. However, common sense dictates that you will not make a larger SCO than user stories.
I am realizing the merits of this approach in my current assignment. Looking at design parameters at SCO level and rolling it up, gives far greater freedom to designers, writers, producers to improvise on the final output quality. SCO is the access point where users spend most of their time. This is where they will make opinions on your work. This is the moment of truth for users to get maximum worth for their time. This is what business managers will eventually learn that their benefits are derived. Hence focusing on them that SCRUM greatly emphasizes on, is a better approach.
Welcome SCRUM to your e-Learning projects development and am sure of far greater productivity, happy development teams, clients and users.
Let me know your SCRUM and SCORM story.
Hi - I'm wondering what your thoughts are on the analysis phase in ADDIE vs. Sprint 0 activities. I'm trying to map out which sprint 0 activities align with analysis needs, and looking for outside opinions. Thanks!
ReplyDelete