by Austin Kirkbride, M.A.
Austin Kirkbride, M.A., is a Project Manager, certified in Scrum and waterfall project management approaches, and an Organizational Change Management specialist with 20 years of domestic and international experience working in the people side of technology and change. This is the first in a series of posts on how Scrum can enhance learning organizations. written in collaboration with the colleagues on her team.
Austin Kirkbride, M.A., is a Project Manager, certified in Scrum and waterfall project management approaches, and an Organizational Change Management specialist with 20 years of domestic and international experience working in the people side of technology and change. This is the first in a series of posts on how Scrum can enhance learning organizations. written in collaboration with the colleagues on her team.
Scrum is an iterative, incremental framework for project management. Originating in the IT
software development world, the scrum methodology has translated well to other industries as it emphasizes functional deliverables, the flexibility to change and adapt along with emerging business realities, and provides a high level of communication and collaboration across the team.Some of my more purist Scrum Master colleagues have challenged me that the learning development methodology – ADDIE, or Assess, Design, Develop, Implement, Evaluate – cannot survive in a Scrum world and that it needs to be eliminated. They argue that ADDIE lives in the old world of waterfall project management, complete with silos and hand-offs that make the methodology an antiquated notion of how training should be developed.
I beg to differ.
One of the more elegant aspects of Scrum is that it is a framework, not a dogma. I’ll admit that ADDIE reeks of waterfall project management and implies that there are hand-offs and linear thinking required to apply the methodology. But with a little open-minded application, I see no reason why ADDIE can’t live in the Scrum world. Here’s how:
Assess: Learning can’t happen unless we know what the scope of the training needs to be. The Assessment is critical to understanding things like audience, content needs, identifying subject matter experts, and looking at how the training fits into the larger needs of the organization. Assessments can be treated as a Sprint Zero, occurring over a couple of weeks or actually broken down into Sprints if the assessment requires a longer chunk of time. The Sprint Zero is the opportunity for the Product Owner, Scrum Master, and team to identify business requirements and value, needs, scope, etc., so why wouldn’t it be malleable enough to be a time of learning assessment?
Design: Once the scope and assessment of the learning needs is identified, the approach, or design, will begin to evolve. Depending upon the scope of the project, the design can be treated as Sprint Planning (for smaller projects with a minimum of complexity) or the design process can be sprinted, with client design reviews (Sprint Reviews) at the end of the sprints to gain sign-off and buy-in from the client (for larger, more complex projects).
Development: Much like software development, learning development can be planned for, sprinted, and reviewed, whether eLearning or Instructor-led. Developing training – eLearning or ILT – would align most closely with its parentage in software development, allowing the instructional designers/developers to collect content and iteratively present it to the client until delivery.
Implementation: This is where applying Scrum needs to be an exercise in Scrum framework flexibility. If implementing training means putting the eLearning on the LMS, there is probably no need to sprint the activity – likely it would be a task within the final sprint. But if implementation requires the team to deliver the learning in a classroom, webcast or interactive environment, it would likely make sense to sprint these activities, complete with stories and tasks. As long as the team is producing a product, it continues to Sprint and deliver to the client.
Evaluation: Again, the process of evaluation may be part of a sprint, or might be sprinted separately, depending upon the scope of the evaluation. Most Level I or II evaluation might likely be tasks within a sprint if, for instance, it is a compiling of survey results at the end of a learning event. Larger evaluation approaches, such as following up with large-scale, long-term metrics, may require their own sprint, or possibly even their own project.
I beg to differ.
One of the more elegant aspects of Scrum is that it is a framework, not a dogma. I’ll admit that ADDIE reeks of waterfall project management and implies that there are hand-offs and linear thinking required to apply the methodology. But with a little open-minded application, I see no reason why ADDIE can’t live in the Scrum world. Here’s how:
Assess: Learning can’t happen unless we know what the scope of the training needs to be. The Assessment is critical to understanding things like audience, content needs, identifying subject matter experts, and looking at how the training fits into the larger needs of the organization. Assessments can be treated as a Sprint Zero, occurring over a couple of weeks or actually broken down into Sprints if the assessment requires a longer chunk of time. The Sprint Zero is the opportunity for the Product Owner, Scrum Master, and team to identify business requirements and value, needs, scope, etc., so why wouldn’t it be malleable enough to be a time of learning assessment?
Design: Once the scope and assessment of the learning needs is identified, the approach, or design, will begin to evolve. Depending upon the scope of the project, the design can be treated as Sprint Planning (for smaller projects with a minimum of complexity) or the design process can be sprinted, with client design reviews (Sprint Reviews) at the end of the sprints to gain sign-off and buy-in from the client (for larger, more complex projects).
Development: Much like software development, learning development can be planned for, sprinted, and reviewed, whether eLearning or Instructor-led. Developing training – eLearning or ILT – would align most closely with its parentage in software development, allowing the instructional designers/developers to collect content and iteratively present it to the client until delivery.
Implementation: This is where applying Scrum needs to be an exercise in Scrum framework flexibility. If implementing training means putting the eLearning on the LMS, there is probably no need to sprint the activity – likely it would be a task within the final sprint. But if implementation requires the team to deliver the learning in a classroom, webcast or interactive environment, it would likely make sense to sprint these activities, complete with stories and tasks. As long as the team is producing a product, it continues to Sprint and deliver to the client.
Evaluation: Again, the process of evaluation may be part of a sprint, or might be sprinted separately, depending upon the scope of the evaluation. Most Level I or II evaluation might likely be tasks within a sprint if, for instance, it is a compiling of survey results at the end of a learning event. Larger evaluation approaches, such as following up with large-scale, long-term metrics, may require their own sprint, or possibly even their own project.
