• Agile Learning Design for Beginners

    Designing learning at the speed of change

    “Pay no attention to the man behind the curtain!” We remember this scene from the movies, and in the past have treated our instructional design the same way. We tell our clients or stakeholders, “Don’t look at what we’re doing. Wait until it’s built until you look.” But agile instructional design is different. It’s about telling our stakeholders, “Come join me behind the curtain and work with me to create something great.”

  • Managing the Work

    Wanting to work incrementally, iteratively, and collaboratively is all well and good, but at some point you have to manage the work and timeline.

    Agile does not mean there isn’t any planning, but rather that planning is different. Instead of creating one plan at the beginning and using your time and energy trying to hold everyone to that plan (which never works), we spend our time identifying what work is a value-add and what can be worked on based on priorities and availability.

    How you manage that work is flexible and can be done using several different methods. Two that we’ve chosen to use at BLP include Kanban and Scrum.

  • Getting Started

    It can feel overwhelming to get started with Agile, especially when we start talking about terms like Kanban and Scrum. To help you get started, we’ve provided a few questions and suggestions for you to get a conversation started with your organization and team.

  • Leaving Addie for SAM Michael Allen’s book is really helpful as you think about conducting design workshops and sending deliverables to stakeholders. http://amzn.com/1562867113

    Agile Manifesto The principles and practices of agile development. www.agilemanifesto.org

    Kanban Learn more about this lean management system. http://en.wikipedia.org/wiki/Kanban

  • Why not ADDIE?

    Using ADDIE methodology gives learning designers a framework we can use to manage the process of creating a learning solution and ensures that we complete the critical tasks to create something that’s instructionally sound.

    What it doesn’t do is help us manage the realities of our daily work lives where content shifts like sand, procedures are updated frequently, and leaders change direction.

  • Creating a linear plan at the beginning of a project with fixed milestones and timelines is usually an exercise in futility. The beginning of the project is the time when we know the least amount of information about it. So, rather than working our way through ADDIE, we’re going to complete all of the same instructional design steps, but do it incrementally, iteratively, and collaboratively.

    Agile learning design allows you to:

    • Create more creative, learner-focused courses.
    • View your stakeholders as partners, not someone to keep at arms length.
    • Plan for and respond to changes.
    • Uncover requirements, preferences, and changes earlier in the design and development process.
  • Using Kanban to Pull Work to Team

    Kanban is a methodology to control the amount of work that the team is working on at any given time. It was created at Toyota to help maintain a consistent amount of work that a team can handle at any given time.

    In Kanban, the team pulls work onto their plates. The team also has set work in progress (WIP) limits that tell the team and the people they work with how much work they can do at any given time. When done correctly, the team can keep the pace of their work in progress limits indefinitely.

  • Scrum

    Steve writing

  • Focus on the mindset, not the process.

    This might seem like the easiest step, but it’s really the hardest. Changing the way we communicate both internally and with stakeholders requires us to develop new habits that can be hard to implement.

    Talk about these questions with your team:

    • Who can you collaborate with more often?
    • Where are the opportunities for more face-to-face conversations?
    • Who on the team needs to take more ownership for the project?
    • Where does the team need to be more flexible and less resistant to change?
  • Have a goal

    To get buy-in for agile, having answers to these questions is critical.

    • Why do we really want to change?
    • What does success look like?
    • Does our company environment and culture support increased collaboration and flexibility?
    • Is our company organizational structure and culture in alignment?
    • Does management and leadership support change?
  • Start Small

    Transitioning to agile is going to take time. At BLP, it’s taken us about a year of research, discussion, piloting, and experimenting before we were ready to take the plunge as an organization. As you work through your goals and begin working more collaboratively, also consider implementing these practical ideas.

    • Conduct project team daily/weekly “stand-ups” 10 minutes max (use a timer). Each person should answer these questions:
      — What’d you do last week?
      — What are you going to do this week?
      — What obstacles might get in your way?
    • At the end of each iteration or significant deliverable, have the team complete a retrospective. Celebrate wins, identify what needs improvement, and leave with at least one action item.
    • Create intact project teams. Allow people the opportunity to develop close working relationships, get to know each other’s styles, and gain efficiencies from that knowledge.
  • Collaborative Design

    Agile instructional design focuses just as much on communication as it does process, if not more. Without strong communication within a development team and with a client or stakeholder, agile just doesn’t work.

    Agile comes to us from the software development world, and one of the principles is individuals and interactions over processes and tools.

  • Incremental Design

    In the past we at BLP have sent our clients a small set of key deliverables for an eLearning course:

    • Design document
    • Script
    • Alpha (first draft)
    • Beta (second draft)
    • Goldmaster (final)

    Each of these deliverables were usually long and time-consuming to review.

    Using an incremental approach, we now focus on sending clients features to react to rather than an entire course. While we still have set deliverables, we’re much more likely to send a screen shot or a piece of something for interim reaction than before.

    We also share with our stakeholders rough drawings, prototypes, and mockups. We don’t worry about making everything polished before they see it. As long as we set expectations well, this allows them to 1) focus on the functionality, not the graphics and 2) provide early feedback that helps us make valuable changes.

  • Iterative Design

    Getting that early feedback is one of the biggest benefits of the agile process. It helps us confirm that our design decisions meet the needs of the learner and organization. It also uncovers faulty logic early in the process.

    Because we are providing clients with small pieces early, they can see the course or app or game evolve over time and become closer and closer to “right.

    This is especially important as we develop things that are new to both us and the clients. Creating mobile apps, games, and higher-level learner interactions requires more iteration than if we’re doing just more of the same.

  • BLP has been using the Kanban approach for our client projects. Because each project team has multiple clients and projects going on at any given time, using a Scrum type method where we try to plan out a two week period is not workable.

    Kanban works really well for our project teams because it allows us to pull work into our workstream, especially when existing projects hit snags or delays.

    Below is an example of a physical Kanban board our team used. Having a visual representation of what’s going on helps the team stay focused and know exactly what everyone is doing when.

    (insert pic of kanban board)

  • What does collaboration look like in a development team?

    Our agile team has worked hard to become more collaborative and ensure that everyone has a voice. In the past, the individuals on the team would throw things over the fence to each other and often it would result in miscommunication and frustration.

    We’ve created some guidelines for the team to help us ensure that we’re communicating well:

    • We will all plan on working in the office at least one day a week. We believe that having face-time aids in communication and makes it easier for us to collaborate as a team.
    • We’ll use group lync chats if there’s something that we feel like the whole group needs to know or weigh in on.
    • We’ll avoid using email. It stinks as a communication tool. It slows things down and doesn’t allow for conversations to happen. Face-to-face, IM, or phone are our preferred tools.
    • We want to have no surprises at internal deliverables. What that means is that the team will work together to agree on functionality, graphics, flow. We believe that we come up with better ideas when more than one person is involved in making the decision.

    It’s been a change in behavior and taken time, but now individuals catch themselves when they communicate in ways that aren’t efficient or involve everyone. (Insert IM from MAtt)

  • What does collaboration look like with stakeholders or clients?

    Collaborating with stakeholders means involving them in the idea creation and decision making processes. While most people like that idea in theory, it requires a different way of working. To help your stakeholders, be sure to:

    • Set clear expectations as to what you want them to review. Try giving them a checklist of questions they should answer.
    • Be sure to tell them what’s not included in the review. If certain features or activities haven’t been created, be clear that it’s intentional, not an oversight.
    • Let them know how much time it will take to look at the feature. In general, our clients have found that they are looking at smaller pieces, more often.
    • Look for ways where you can have them look at things with you. Tack on 10 minutes at the end of a meeting and show them what you’re working on. Or if you have regularly scheduled status meetings, come prepared with some show and tell to get their reactions and feedback.
    {"cards":[{"_id":"4397212ea4a1208d6e00002a","treeId":"439719a5a4a1208d6e000027","seq":271708,"position":1,"parentId":null,"content":"# Agile Learning Design for Beginners\n*Designing learning at the speed of change* \n\n\"Pay no attention to the man behind the curtain!\" We remember this scene from the movies, and in the past have treated our instructional design the same way. We tell our clients or stakeholders, \"Don't look at what we're doing. Wait until it's built until you look.\" But agile instructional design is different. It's about telling our stakeholders, \"Come join me behind the curtain and work with me to create something great.\""},{"_id":"43973bafa4a1208d6e000036","treeId":"439719a5a4a1208d6e000027","seq":92716,"position":3,"parentId":"4397212ea4a1208d6e00002a","content":"## Why not ADDIE?\n\nUsing ADDIE methodology gives learning designers a framework we can use to manage the process of creating a learning solution and ensures that we complete the critical tasks to create something that's instructionally sound. \n\nWhat it doesn't do is help us manage the realities of our daily work lives where content shifts like sand, procedures are updated frequently, and leaders change direction. "},{"_id":"43974514a4a1208d6e000037","treeId":"439719a5a4a1208d6e000027","seq":91196,"position":4,"parentId":"4397212ea4a1208d6e00002a","content":"Creating a linear plan at the beginning of a project with fixed milestones and timelines is usually an exercise in futility. The beginning of the project is the time when we know the least amount of information about it. So, rather than working our way through ADDIE, we're going to complete all of the same instructional design steps, but do it **incrementally, iteratively, and collaboratively.**\n\nAgile learning design allows you to: \n* Create more creative, learner-focused courses.\n* View your stakeholders as partners, not someone to keep at arms length.\n* Plan for and respond to changes. \n* Uncover requirements, preferences, and changes earlier in the design and development process."},{"_id":"4397271fa4a1208d6e00002b","treeId":"439719a5a4a1208d6e000027","seq":91474,"position":1,"parentId":"43974514a4a1208d6e000037","content":"### Collaborative Design \n\nAgile instructional design focuses just as much on communication as it does process, if not more. Without strong communication within a development team and with a client or stakeholder, agile just doesn't work. \n\nAgile comes to us from the software development world, and one of the principles is **individuals and interactions over processes and tools**. "},{"_id":"4397378ea4a1208d6e000034","treeId":"439719a5a4a1208d6e000027","seq":91592,"position":1,"parentId":"4397271fa4a1208d6e00002b","content":"### What does collaboration look like in a development team? \n\nOur agile team has worked hard to become more collaborative and ensure that everyone has a voice. In the past, the individuals on the team would throw things over the fence to each other and often it would result in miscommunication and frustration. \n\nWe've created some guidelines for the team to help us ensure that we're communicating well: \n* We will all plan on working in the office at least one day a week. We believe that having face-time aids in communication and makes it easier for us to collaborate as a team.\n* We’ll use group lync chats if there’s something that we feel like the whole group needs to know or weigh in on.\n* We’ll avoid using email. It stinks as a communication tool. It slows things down and doesn’t allow for conversations to happen. Face-to-face, IM, or phone are our preferred tools.\n* We want to have no surprises at internal deliverables. What that means is that the team will work together to agree on functionality, graphics, flow. We believe that we come up with better ideas when more than one person is involved in making the decision.\n\nIt's been a change in behavior and taken time, but now individuals catch themselves when they communicate in ways that aren't efficient or involve everyone. (Insert IM from MAtt)\n\n\n"},{"_id":"4397b444a4a1208d6e00003b","treeId":"439719a5a4a1208d6e000027","seq":103383,"position":2,"parentId":"4397271fa4a1208d6e00002b","content":"### What does collaboration look like with stakeholders or clients?\n\nCollaborating with stakeholders means involving them in the idea creation and decision making processes. While most people like that idea in theory, it requires a different way of working. To help your stakeholders, be sure to: \n\n* Set clear expectations as to what you want them to review. Try giving them a checklist of questions they should answer. \n* Be sure to tell them what's **not** included in the review. If certain features or activities haven't been created, be clear that it's intentional, not an oversight. \n* Let them know how much time it will take to look at the feature. In general, our clients have found that they are looking at smaller pieces, more often. \n* Look for ways where you can have them look at things with you. Tack on 10 minutes at the end of a meeting and show them what you're working on. Or if you have regularly scheduled status meetings, come prepared with some show and tell to get their reactions and feedback. "},{"_id":"43975613a4a1208d6e000039","treeId":"439719a5a4a1208d6e000027","seq":91406,"position":3,"parentId":"43974514a4a1208d6e000037","content":"### Incremental Design\n\nIn the past we at BLP have sent our clients a small set of key deliverables for an eLearning course: \n* Design document\n* Script\n* Alpha (first draft)\n* Beta (second draft)\n* Goldmaster (final)\n\nEach of these deliverables were usually long and time-consuming to review. \n\nUsing an incremental approach, we now focus on sending clients **features** to react to rather than an entire course. While we still have set deliverables, we're much more likely to send a screen shot or a piece of something for interim reaction than before. \n\nWe also share with our stakeholders rough drawings, prototypes, and mockups. We don't worry about making everything polished before they see it. As long as we set expectations well, this allows them to 1) focus on the functionality, not the graphics and 2) provide early feedback that helps us make valuable changes. "},{"_id":"43978cc0a4a1208d6e00003a","treeId":"439719a5a4a1208d6e000027","seq":91722,"position":4,"parentId":"43974514a4a1208d6e000037","content":"### Iterative Design\n\nGetting that early feedback is one of the biggest benefits of the agile process. It helps us confirm that our design decisions meet the needs of the learner and organization. It also uncovers faulty logic early in the process. \n\nBecause we are providing clients with small pieces early, they can see the course or app or game evolve over time and become closer and closer to \"right. \n\nThis is especially important as we develop things that are new to both us and the clients. Creating mobile apps, games, and higher-level learner interactions requires more iteration than if we're doing just more of the same. "},{"_id":"43972a7da4a1208d6e00002d","treeId":"439719a5a4a1208d6e000027","seq":93209,"position":2,"parentId":null,"content":"## Managing the Work\n\nWanting to work incrementally, iteratively, and collaboratively is all well and good, but at some point you have to manage the work and timeline. \n\nAgile does not mean there isn't any planning, but rather that planning is different. Instead of creating one plan at the beginning and using your time and energy trying to hold everyone to that plan (which never works), we spend our time identifying what work is a value-add and what can be worked on based on priorities and availability. \n\nHow you manage that work is flexible and can be done using several different methods. Two that we've chosen to use at BLP include Kanban and Scrum. "},{"_id":"43972b1da4a1208d6e00002e","treeId":"439719a5a4a1208d6e000027","seq":93036,"position":1,"parentId":"43972a7da4a1208d6e00002d","content":"## Using Kanban to Pull Work to Team\n\nKanban is a methodology to control the amount of work that the team is working on at any given time. It was created at Toyota to help maintain a consistent amount of work that a team can handle at any given time. \n\nIn Kanban, the team pulls work onto their plates. The team also has set work in progress (WIP) limits that tell the team and the people they work with how much work they can do at any given time. When done correctly, the team can keep the pace of their work in progress limits indefinitely. "},{"_id":"43999a0fd575c93c0200003b","treeId":"439719a5a4a1208d6e000027","seq":93128,"position":1,"parentId":"43972b1da4a1208d6e00002e","content":"BLP has been using the Kanban approach for our client projects. Because each project team has multiple clients and projects going on at any given time, using a Scrum type method where we try to plan out a two week period is not workable. \n\nKanban works really well for our project teams because it allows us to pull work into our workstream, especially when existing projects hit snags or delays. \n\nBelow is an example of a physical Kanban board our team used. **Having a visual representation of what's going on helps the team stay focused and know exactly what everyone is doing when.** \n\n(insert pic of kanban board)"},{"_id":"43972b40a4a1208d6e00002f","treeId":"439719a5a4a1208d6e000027","seq":93134,"position":2,"parentId":"43972a7da4a1208d6e00002d","content":"### Scrum\n\nSteve writing"},{"_id":"43972cffa4a1208d6e000030","treeId":"439719a5a4a1208d6e000027","seq":103390,"position":2.25,"parentId":null,"content":"## Getting Started\n\nIt can feel overwhelming to get started with Agile, especially when we start talking about terms like Kanban and Scrum. To help you get started, we've provided a few questions and suggestions for you to get a conversation started with your organization and team. "},{"_id":"43972d4fa4a1208d6e000031","treeId":"439719a5a4a1208d6e000027","seq":93596,"position":1,"parentId":"43972cffa4a1208d6e000030","content":"### Focus on the mindset, not the process.\n\nThis might seem like the easiest step, but it's really the hardest. Changing the way we communicate both internally and with stakeholders requires us to develop new habits that can be hard to implement. \n\nTalk about these questions with your team: \n\n* Who can you collaborate with more often?\n* Where are the opportunities for more face-to-face conversations?\n* Who on the team needs to take more ownership for the project?\n* Where does the team need to be more flexible and less resistant to change?\n"},{"_id":"43972db7a4a1208d6e000032","treeId":"439719a5a4a1208d6e000027","seq":93624,"position":2,"parentId":"43972cffa4a1208d6e000030","content":"### Have a goal\n\nTo get buy-in for agile, having answers to these questions is critical. \n\n* Why do we really want to change?\n* What does success look like?\n* Does our company environment and culture support increased collaboration and flexibility?\n* Is our company organizational structure and culture in alignment?\n* Does management and leadership support change?\n"},{"_id":"43972e1ba4a1208d6e000033","treeId":"439719a5a4a1208d6e000027","seq":93774,"position":3,"parentId":"43972cffa4a1208d6e000030","content":"### Start Small\n\nTransitioning to agile is going to take time. At BLP, it's taken us about a year of research, discussion, piloting, and experimenting before we were ready to take the plunge as an organization. As you work through your goals and begin working more collaboratively, also consider implementing these practical ideas.\n\n* Conduct project team daily/weekly “stand-ups” 10 minutes max (use a timer). Each person should answer these questions: \n-- What’d you do last week?\n-- What are you going to do this week?\n-- What obstacles might get in your way?\n* At the end of each iteration or significant deliverable, have the team complete a retrospective. Celebrate wins, identify what needs improvement, and leave with at least one action item.\n* Create intact project teams. Allow people the opportunity to develop close working relationships, get to know each other's styles, and gain efficiencies from that knowledge.\n"},{"_id":"43975544a4a1208d6e000038","treeId":"439719a5a4a1208d6e000027","seq":103391,"position":2.5,"parentId":null,"content":"## Links\n\n*Leaving Addie for SAM* Michael Allen's book is really helpful as you think about conducting design workshops and sending deliverables to stakeholders. http://amzn.com/1562867113\n\n**Agile Manifesto** The principles and practices of agile development. www.agilemanifesto.org\n\n**Kanban** Learn more about this lean management system. http://en.wikipedia.org/wiki/Kanban\n"}],"tree":{"_id":"439719a5a4a1208d6e000027","name":"Agile WhitePaper","publicUrl":"agile-whitepaper"}}