Learning Experience Leader

62 // Examples of Designing Learning Experiences using Agile Project Management with Alyssa Erickson

May 18, 2021 Greg Williams
Learning Experience Leader
62 // Examples of Designing Learning Experiences using Agile Project Management with Alyssa Erickson
Show Notes Transcript

While earning her master’s degree in Instructional Psychology & Technology at BYU, Alyssa worked on instructional design projects and teams in university, K-12, and corporate settings. Her work at BYU Independent Study introduced her to how Agile principles can be applied and adapted to instructional design, which became the subject of her master’s thesis. She currently works as a Learning Experience Designer at Qualtrics in the world of sales enablement.

Today we talk about:
👉 Agile and waterfall project management methodologies as related to instructional design
👉 Alyssa’s experience of using agile methodologies in academic and corporate organizations
👉 Estimating work to be done using “planning poker”
👉 An example of a traditional waterfall project viewed from an agile perspective

Resources:
👉 Scrum: The Art of Doing Twice the Work in Half the Time (Book) 
👉 Tiny Habits  (Book) 
👉 Episode 42: Habits, Context and Designing for Behavior Change with Andrew Webb
👉 Agile for Instructional Designers (Book)

Did you know the LX Leader is currently ranked in the top 40 L&D podcasts? Check it out and THANK YOU for listening! 

Support the show (https://www.patreon.com/lxleader)
Greg Williams:

Alyssa, I'm so excited to have you here on the show today.

Alyssa Erickson:

Thanks so much, Greg. I'm excited to be here.

Greg Williams:

So for those of our listeners who don't know you, could you talk just a little bit about what your current work looks like, and what what your role entails?

Alyssa Erickson:

Sure. So I'm a learning experience designer at Qualtrics right now. And I'm a part of the global enablement solutions team. So basically, we create learning solutions for the sales and CS teams at Qualtrics internal employees. And day to day, my work varies quite a bit. But I oversee our curriculum and our onboarding for new hires. And some days I might be developing elearning, and more in the weeds. Other days, I might be leading Scrum teams, with other learning experience designers who are elping me develop curriculum. ometimes I'll be on calls, onsulting with trainers and ther people in the company who re looking to improve their earning solutions. Sometimes e'll be working on a larger ompany initiative and coming up ith a more comprehensive nablement plan for how we can upport learners before during n after a learning experience, ncluding the results are mpacted the initiative. And ometimes I'm just jumping in here needed. One of the values t Qualtrics is being scrappy. nd I feel like a lot of times 'm just being scrappy, and elping people where I can. I ant

Greg Williams:

to, I want to maybe talk about that as we're going to discuss agile because I used to joke around with peers a lot in my last job about that term, scrappy, sometimes can be crappy. It's like, and I don't think they're the same. And so I think there's an element to that of like, how can you work scrappy and still deliver without, without feeling jaded? Or like you're, you're doing subpar? Work? I don't know if those? those tensions make sense to you?

Alyssa Erickson:

Sure, definitely. I like that distinction, because it's important to be flexible in the work we do. And I think when we say scrappy, we're getting out that we want to be able to not get caught up in processes so much, though, we recognize that they're helpful. We want to be able to pivot easily in a project and experiment and try new things. But there is always that risk of it not being the best quality, which is where you get into the more crappy territory.

Greg Williams:

Yeah, yeah, it can be difficult, um, and Qualtrics is a technology company. And can you talk a little bit about sort of the nature of the work of Qualtrics. And just a tad more about who who are the learners that you're working with most regularly?

Alyssa Erickson:

Sure. So Qualtrics is an experience anagement company. So they reate software and solutions to mprove experiences. And this alls in several different reas, including customer xperiences, employee xperiences within a company, nd then brand and product xperiences as well. So I love hat because as a learning xperience designer, I'm always rying to improve have xperiences as well. So with the nternal employees that I upport, which is mostly sales nd CS, we're essentially just rying to help them be uccessful at their jobs, give hem the tools that they need o, to help their clients see he value of experience anagement and how we can help hem improve experiences in heir companies.

Greg Williams:

Okay, no, that that is interesting. might feel a little meta sometimes this year, like, I imagine you use Qualtrics tools like to improve your learning experiences, or do you? Is that something that is outside of your purview?

Alyssa Erickson:

Yeah, that's a great question. We definitely use I mean, Qualtrics is sometimes seen as a survey company. And we actually do a lot more than just surveys. But we do use our survey tool to get feedback from our learners on a regular basis, whether it's new learnings, or live training experiences, or ad hoc, and we're trying to learn more about them. We also recently started and I don't want to get too off track here. learner diagnostic using our 360 tool. Essentially, we see it twice a year, and we send out this 360 to sales reps and their managers to assess themselves in certain competency areas like how am I doing with competition, like am I able to speak while the competitors and they rate themselves and then their manager rates them. And then they can look at their results and get some customized learning solutions or recommendations based on the areas where maybe they're falling a little bit short, or the their reading of themself is different than how their manager read at them.

Greg Williams:

That's cool. And I've heard of doing that just like in general with employee satisfaction or employee performance, but it's really neat to hear that you're doing that in the realm of learning on a specific domain. That's pretty cool. Now, we set off our our goal today is to talk through agile a little bit. And for listeners, I was particularly interested to hear about this from Alyssa because she's done extensive research in the area, but then has also worked to apply those principles in various areas. And and so I feel like there's a lot of great things we could dive into. But maybe For starters, we could just briefly define what agile is, and its origins for those who maybe aren't familiar with it as a project management way of working, and how that might intersect with instructional design theories in practice.

Alyssa Erickson:

Sure, yeah, I want to start with a disclaimer that I love talking about agile, I'm not I don't consider myself an expert, but I have had a lot of experience and have enjoyed researching it in the past. So if I were to define agile, simply, I would say that is a project management approach. And it originated in the world of software. So actually, it's an interesting story where a group of software developers came together in Utah in the Snowbird ski lodge, and this was 2001. And they decided there must be a better way to manage our software projects. And they saw a lot of problems with the current way they were doing things with the waterfall methodology, which was a more linear approach to projects. So they came up with a manifesto and 12 principles for agile development. And since 2001, many different industries and areas have implemented agile and adapted it to their own fields, including instructional design. So agile is meant to be very iterative. It's based on having continuous feedback and improvement, and is a flexible approach to project management where you can move between phases of a project. So if we're thinking of this in terms of instructional design, some of our listeners might be familiar with the acronym Addie, which is a really common instructional design process. And Addie stands for analyze, design, develop, implement, and evaluate. And some people interpret Addie as being a step by step process, something that's linear, moving from analysis to design, development, implementing then evaluating at the end, however, I others say no, we need to look at this more iteratively. And I would say that's where agile intersects with instructional design. When we can take something like Addie, for example, and think of it as a an iterative process. Where, for example, you might start with analysis, and then move to designing and developing. And then that iteration, you come out with something that works, it might not be perfect or beautiful, but a working prototype or something that works that you implement meant, and you test with learners, maybe. So they're the imp of Addie, and then you circle back again, you get some feedback and then you develop design and Follow up again. Then you circle again to getting feedback from learners and continue those iterations. So yeah, in short, you can think of Agile applied to instructional design by thinking through those phases of Addie in a more cyclical way, then you might when you're just thinking a linear add IE.

Greg Williams:

Yeah, and I know. So we've talked about, you've talked a little bit about agile, and you mentioned waterfall as kind of this linear thing. And something I know we've talked about before is thinking about waterfall. It's not bad. It's not bad. Like if you do waterfall you're not, you know, evil or anything. It's just that certain ways, project management approaches, like you're saying, can be conducive to certain sorts of products or things that you're doing with waterfall then is organized with maybe for large projects, where one phase must be done in order to move forward to the next. Is that accurate?

Alyssa Erickson:

Yeah, exactly. And I'm glad you brought that up. It's not to say that we all need to be 100% agile in the projects we're working on. There are some distinct advantages to a more linear process, and it might fit certain projects more. But yes, like you said, waterfall is seen as more linear or traditional in its approach, where you have discrete phases that are a little bit more rigid. It's not as flexible. So you can't really jump ahead to one phase of the project. And you don't really go back either. But yeah, An example might be of like berbice, fits well, manufacturing cars, you have an assembly line where the cars moving forward on a conveyor belt, and things are being added to the car as it goes in a very linear fashion. And then it's tested at the end. So there is definitely a time in place for a more waterfall or linear approach to things.

Greg Williams:

So and maybe listeners are more in tune than I am with this. But as I've delved into the world of agile, there's things that you hear that come out where it's like, Is that an agile project management approach? Is that something different? So things like Scrum, or Kaizen or Kanban boards and all these things? And it's like, how do these pieces fit in? I don't know if you have a sense of some of those terms and what that means for the world of agile.

Alyssa Erickson:

Sure, yeah. So there are several different frameworks within agile that people use to make their projects happen. And you mentioned Scrum. So that term comes from the sport of rugby, where a rugby team. And I'm not an expert in this part, but they are essentially heads down, locked together, trying to move things forward. And that is what a scrum team does it in working together closely communicating, and trying to move a project past any roadblocks that might get in the way. So a scrum team is that kind of team in Agile, they're moving forward and oftentimes in in a sprint, so a sprint is a defined period of time to complete a set amount of tasks. So sometimes a sprint is one week, maybe it's two weeks, but they're saying, okay, we are going to get all of these things done. And we're going to work together as a team to overcome any roadblocks to make sure all of these tasks get done in the sprint. So those are two key terms that you might hear in Agile. And then you mentioned convent, as well. So there are different systems that are commonly used to organize tasks in in agile and Kanban is a good example. Maybe a scrum team is working in their sprint using a Kanban board. And one way to visualize this is let's say you have a big board on the wall and different sticky notes. And each sticky note represents one task. And there are several different columns on this board. The first one is often a backlog. So a backlog of sticky notes or tasks that need to be done. And when a scrum team gets together to plan out their next sprint, they'll look at the backlog. They'll say, okay, what's the definition of done? Let's, you know, scope this out a little bit. And once they've determined that that task should be in the sprint, that sticky note or task moves to the to do column. So you have the backlog you have the to do. And then as they're going in the sprint, they'll assign themselves a task and move it to the in progress column, and eventually move it to done. Maybe there are a couple of columns in between like QA or testing. But the idea with combine is that you're continually moving those tasks forward. And it's very visual.

Greg Williams:

Yeah, it's it's like a way to easily see the work and allow people to kind of be a little more autonomous in moving the work forward rather than waiting for everything to be assigned or something along those lines.

Alyssa Erickson:

Exactly, and something that I didn't mention with the term Scrum and sprint. So I talked a little bit about how waterfall applies to car manufacturing, maybe as an example. And one interesting example of Agile being applied to car manufacturing is actually the company Toyota, they decided that they wanted to make it less linear process in developing or making their cars. So they put these cords above their production lines. And if there was a problem with the car, going through a process, any employee can pull on that cord and the production line would stop. And that team would gather around and try to fix the problem before continuing the the line again. And I think that's a good example of Scrum. When there's a problem, the team works together to make it move forward so that they can complete their sprint

Greg Williams:

seems like communication and like the courage to speak up, play a big role in all of that.

Alyssa Erickson:

Absolutely, yeah. I mean, that is one of the key principles of Agile is close communication, even daily communication. In the scrum team is emphasized having a daily standup is very common, where you it's very short, and you're standing up so that it doesn't go too long. But everybody talks about Okay, what did I do yesterday? And what I'm, what am I going to work on today? And what roadblocks Do I have, and then the scrum master on their team would be the one to help get rid of those roadblocks and help the project continue forward.

Greg Williams:

So in thinking about these different approaches as waterfall and agile and various tools within each, some more traditional and some relatively new, my assumption is you don't you you don't necessarily have to do one or the other. But there might be a way to blend these together. I wonder if you could talk a little bit about about how we might have a hybrid approach.

Alyssa Erickson:

Sure, yeah. Hybrid approaches to project management are very common, I think more common than the pure waterfall or the pure agile. Like I said, the Agile methodology has become more popular since 2001. But that doesn't mean that everybody's doing it in its purest form. And what I like to think of when we talk about hybrid is basically you have a spectrum between waterfall and agile. So you might think waterfall is on the left agile on the right, hybrid is anything in between. So I would say in the world of instructional design that most projects fall in between waterfall and agile, because agile is created for software development. The nature of projects and instructional design make it close to impossible to be completely agile. But it doesn't mean we can't implement a lot of the principles. And when I worked on my thesis project, and we can talk about that a little bit later, I did some research and found that most companies identified themselves in the hybrid area somewhere between waterfall and agile and how they were doing their project projects.

Greg Williams:

I'm interested in what areas do you feel the most tension for which an instructional design project can't be agile? I mean, what what's limiting it to being like a full on product software development team?

Alyssa Erickson:

Yeah, I would say one limiting factor is a culture at an organization, if the culture is used to a more waterfall process, and that's the tradition, then there can be some resistance in implementing agile principles is just different. And the nature of the work of the projects you're doing in instructional design, a lot of times we have several projects going at once, not just one project at a time. And that means that we're juggling a lot of different things at once, and they're in different phases of the project at once. But another reality for instructional designers is also that sometimes we don't have a specialized team, who's helping us move forward. Sometimes we are a one man show, or jack of all trades, and don't have that team of specialized workers to help with different phases of the project. And one other thing I'd like to point out is that the space or environment that you work in, it can also be a limiting factor in implementing agile. Sometimes you the ideal would be to have the entire scrum team in one room throughout the day. But sometimes, just by necessity, they they're on different teams, so they're in different rooms, or you're in a pandemic like COVID this year where you can't be face to face with your team and need to rely more on digital tools to have those daily stand ups and to collaborate.

Greg Williams:

Yeah, so it sounds like there's a lot of kind of structural barriers that would make it hard for a team to act in, you know, sort of pure agile and like you said, That doesn't matter. Certainly not necessarily the goal here is to, you know, be a pure, purist with agile, but something I thought about too, seems difficult compared to like, if I'm on an agile software development team to create an app, where the goal is a transaction, like a purchase, or, or something like that. But that action by the user is very discreet compared to let's say, I'm creating a leadership development learning program. The transaction is much more ambiguous and long term it feels like, right, like, my goal is to help them become a better leader. And hopefully, I've broken that down as a part of an analysis as to like, what actions they would be taking to signify these become a better leader. But it's just so much broader and difficult to pin down then like, Oh, you know, they purchased this plan on an app, which makes the goal and the Agile development and testing so much more focused, I don't know if that makes sense for what I'm talking about the level of focus for the goal of the user or the learner.

Alyssa Erickson:

For sure, I really like how you put that and it's true. Many of our tests and projects and learning experience designer, more ambiguous and aren't as cut and dry when it's finished, you're continuing working to help us learn. And though you can be developing prototypes and things for people to test, and you can have a minimum viable product showing, okay, this is a working course or something, it's not quite as clear cut as, okay, this is an app that does XYZ, and it definitely meets our objectives with instructional design, it takes a lot to know whether or not you're meeting your objective, you know, you're trying to see if you're influencing behavior, or if you're even making an impact on business objectives.

Greg Williams:

Yeah, um, so we've talked about kind of the definitions and the overall meaning of these terms. I'd love to hear some examples from your own experience in practice as how you've seen these project management approaches in action, so where would be the best place to start?

Alyssa Erickson:

Sure, let's start with when I was first introduced to agile, which was in my work at independent study at BYU, the university I went to, I was an instructional design assistant. And this is actually what inspired me to research agile for my thesis in my master's program.

Greg Williams:

So you were working, and you were a graduate student at the time? And then you're introduced these ideas. So how, how did project management work? Or look like when you were there? And mean, did it change as you were learning? Or did you apply those principles later?

Alyssa Erickson:

Yeah, so I worked at independent study, during my undergraduate and my graduate years. And I saw this change in 2016, where previously, the teams at independent study, were using more of a waterfall approach, or a typical Addie linear approach to their project management. And that kind of looked like, you know, you had this this instructional designer, and they were essentially the project manager of the team. And they would be given a course that they needed to develop. And first, they would, you know, analyze what the needs of those courses were and create an outline, then they would meet up with the professor, and basically wait on the professor to get all the content for the course. So sometimes that took a lot of follow up, and, you know, maybe prodding to get the content they needed. And once they got all that content from the professor, they could start designing a little bit more reviewing the content and organizing it. And then in the development phase, there were several teams that independent study, like editing, we have media teams, like illustration, and animation. And so those teams would work to develop the assets of the course, the editors would work on making the text flow well, while the media teams would create videos or images and other things. And then the instructional design assistance, would put all of the things into HTML once they were ready. So from there, the course would move into the testing area and have some quality control, and then finally be open for enrollment. And in this process, you probably heard Addie embedded a little bit in those steps. There wasn't much wiggle room for moving between the phases, you were basically waiting on other teams to do their chunk before you could start working on your area of work. And though it was predictable, it sometimes resulted in bottlenecks where you were waiting on other teams like I mentioned, and courses would be basically at a standstill at certain times. So it could take months, two years to finish the Out of the university course. Yeah. So that was one example of more of a waterfall method before 2016 independent study, where it was just hard to predict the costs and deadlines of a given project.

Greg Williams:

And so these are university courses. And you're developing, it's like you said, could be months or years. And as you were there, then you started studying agile. And did that change then after 2016? It sounds like there was a time that that approach shifted.

Alyssa Erickson:

It did, yes, a new leader came in to independent study. And he had worked in the world of software. And he saw great potential for implementing agile. So he took the whole team through an agile training, and they started implementing this methodology in their coursework. And it was really fascinating as just a student employee to see how this changed the way people worked, which is what got me interested in studying it for my thesis.

Greg Williams:

Yeah, so what what changed? I mean, did suddenly everyone is doing the same thing, but just like faster, or? Yeah, I'm curious to know exactly like, what that difference looked like.

Alyssa Erickson:

Yeah, so the way that teams work together was a big change. Instead of working very separately in passing the project from one team to another, they created Scrum teams. So the instructional designer became kind of the scrum master and the product owner in a way because they would not only oversee how Scrum, worked on their team, but they would also prioritize the tasks that the team worked on. And then the actual development team that worked for that instructional designer consisted of student employees from those different teams I mentioned. So you might have one editing employee, one illustrator, one instructional design assistant, one video developer, one quality control person. And that's what consisted of the scrum team, or that's what the scrum team consisted of. So that was one thing that changed is how teams work together. And then also, they started working in sprints. So in this context, a sprint was usually working on one to two lessons at a time. So rather than working on the whole course at once, which would be 12 plus lessons, they split it into chunks, say this sprint, we're focusing on lessons, one and two, maybe. And they do that for a couple weeks, finished the sprint and then they actually implemented a little jog period, it was one week, where they would slow down and reflect on how the sprint went, and then plan out the next sprint.

Greg Williams:

Yeah, I am going to be having Megan Torrance here on the podcast pretty soon. And something that she mentions in her book is kind of, she didn't use the term jog. I like that. It's a jogger Walker, or something where you could also use that time maybe for subject matter experts to review what you've produced in that sprint or acting as kind of proxies for the learners or depending on your context. Maybe you do get that piece out in front of learners as you're doing your retrospective or reflecting on what took place in preparing for the next sprint. I don't know if you saw that their independent study or in other places.

Alyssa Erickson:

Yeah, I like that. It definitely is a good time for that review with stakeholders, independent study, I wasn't exactly sure as a student employee what was happening. So I'm not entirely sure if the professor would take a look, you know, each time we developed one to two lessons or not. But I know right now, in my work, we definitely look at it that way we work in on my current team in Sprint's to develop curriculum. And usually we'll start by doing kind of a prototype that works. And we'll get it in front of our stakeholders and give them about a week to review, which also gives us time as a team to either be working on moving other projects forward, or reflecting you know, on how that last sprint went.

Greg Williams:

Yeah. So you kind of had a front row seat, though, admittedly, you can see behind the scenes or behind the seat, given your your role, which I I totally understand. But you have this front row seat to a big change in how instructional designers and other content developers were working. And you mentioned you did it then a thesis is kind of lit a fire in you as to understanding a little bit more about agile and how it might apply to instructional design. I wonder if you could talk just a minute about your research questions, and maybe what are one or two takeaways you had from that work?

Alyssa Erickson:

Sure. So in the research, I decided to approach this analysis of how instructional design and agile work to independent study through the 12 principles of Agile actually, so I met And that manifesto and the principles that were created in 2001. So I, basically my question was, to what extent does BYU independent study, adhere to or not adhere to the 12 principles of Agile? And I looked at that through a few different ways through interviewing different stakeholders serving the different Scrum teams, and also observing the scrum teams and how they work together. And essentially, what I found was that they adhere to about 50% of the principles of Agile in this case, and so they definitely fell into that hybrid area that we were discussing before, where they were able to implement some parts of Agile pretty closely to, you know, the, what you would call the pure implementation of agile, but some things just due to the nature of the work and the way teams were set up, even the way the building was set up, made it so that they couldn't implement certain principles.

Greg Williams:

Yeah, and we talked a little about some of the other barriers earlier too, as to why why agile in its full glory, might be tricky for instructional design teams. there for those that were resistant, or, and maybe it's just people in general, I know are often resistant to change, including myself, and something's coming. But agile seems to be really focused on embracing change. And how have you seen that? I guess that mentality come across in what's made it easier for folks to decide to adapt or adopt agile principles where they might normally be resistant?

Alyssa Erickson:

Yeah, I like that question a lot. Because it is so common to resist change, I think when we find a way of working and we get used to that it can be hard to shift. And it becomes almost a paradigm shift if you're going from waterfall to agile. So some things that help I think, is having leadership on board and supportive of this new culture of embracing change and being flexible and processes and implementing something like agile, that would definitely be one. Something else that might help is a willingness to be flexible in how teams are organized. And even where they might be sitting. You know, can you reorganize the office structure so that Scrum teams can sit together and be together throughout the day? If you are in person? Or can you explore different tools that will help you work better as a team, like maybe slack for communicating or Asana or Trello, for creating project boards, like a Kanban board to make the work very visible and transparent. So I'd say those are a couple of things that might help. But it's true resistance to change is a real issue when it comes to switching project management methodologies like this. And in the case of independent study, you know, it made sense, the editing team was very used to working on all of the lessons at once rather than just one or two at a time because they wanted to be consistent in the way that they edited. And that was easier to do it all at once and harder to have that consistency when it was split up.

Greg Williams:

Yes, like you mentioned before, there's structural things that can make this different parts of it more difficult. So I'm wondering then, if you had other workplace experiences where you saw agile used and wondering as you're talking to that if we can extract some of the principles there and maybe think about how one could approach a project differently, because part of my fear in our conversation here is our audience might have a degree of understanding of things we're talking about, and maybe some that's not and one thing I felt in myself is this fear of change to agile can be exacerbated by like, I don't even know what agile is. So I don't know what we're changing to and that that makes things even more difficult and ambiguous. So that's a long winded question. Let's start maybe just talking about any other experiences you've had and observations. And then we can get into a little bit more of that tactical conversation of, of how I could go about planning a project differently if I'm thinking with an agile mindset.

Alyssa Erickson:

Sure, yeah, it's a good point. Until we have some more examples of how people have implemented agile, it's hard. It's a very abstract concept. So one example of how I've seen it work was in my first job after graduating with my Masters, I worked at a company called state food safety, and they create compliance courses for workplace safety like food safety, and I was impressed when I came in because they were awesome. They were already using a pretty pure form of Scrum or agile in their scrum team. Yeah, it was great. They pretty much use the book by Jeff Sutherland. He's one of the founders of agile. He wrote a book called The Art of doing twice the work and half the time. And we pretty much use that as our playbook on the team. And the way that looked was our team consisted of, well, me, I was the only instructional designer on the team. And then there was an editor quality control person, there was a programmer, a video editor, and an artist or Illustrator. So we all had pretty clear roles on the team. And also, we had, you know, very clear roles when it came to having a scrum master one person who basically oversaw the how of how we did agile, so he would make sure we were adhering to principles of Scrum and agile. And then we had a product owner, which was our boss, who looked over the business priorities and helped us determine what we should be working on in a given sprint. So the way we work together to make it a little bit more definite, was each week, we would meet for a sprint planning session. And we would look at our backlog and the tasks we had ahead of us. And we would decide what we wanted to take on for the next sprint. And part of that was something called planning poker. I don't know if you've heard of that. But essentially, what we would do is vote on how much effort we thought each task would take. And there are different ways of doing this. One way that we use was using the Fibonacci sequence of numbering, which is like 0123, and then it jumps to five 813 21. So the gaps get bigger as you get larger, and it actually becomes a really fun way to estimate the effort of a project because you vote on okay, how much effort Do you think this will take? And everybody anonymously submits their numbers? And if there's a discrepancy of maybe two numbers, or more than you can talk about, okay, why did you rate it so high? or Why did you rate it so low, and then rebuilt as a team. And having those numbers attached these projects helps you see how much you can accomplish in one sprint, or your velocity, and then helps you know how much you can take on for future sprints.

Greg Williams:

So these numbers, they don't represent hours of work. It's you said effort. Can you talk a little bit more about that?

Alyssa Erickson:

Yeah, so it can be hard to not connect it to intervals of time, I think sometimes when I voted, I would think, Oh, this would take me about two hours. So I'm going to load it to the team eventually got really good at saying no, this feels like it's an eight. And that doesn't mean that it takes up eight hours of work. But it's just like, the way that we estimate the amount of effort for a task, this is an eight, it's going to take some more time and effort than maybe a two or three.

Greg Williams:

And so then, as you figure out your sort of velo ity score was that like you ad up all those together? And the at the end of the sprint, you ee, like how much you did? And hat was sort of your help, do you then inform your next estim te? Or how did that how does hat velocity score factor into the work the team d

Alyssa Erickson:

Yeah, exactly what you said we would add it up at the end of a sprint. And sometimes it takes a few Sprint's to get a good average of what your velocity is, and it takes a while for the team to get really good at making those estimates. But you can start seeing like, okay, our team can take on about, I don't know, 80 points total this week, it was probably more than that. Then you can more easily plan out future sprints and just know how much you're capable of as a team.

Greg Williams:

That's so powerful. I know estimating is something it's often a shot in the dark. And depending on your organization, if you are a freelancer and you're eager for work, you might say yes to do something without fully understanding the depth or internally. I know I have stakeholders internally, who will say, Hey, can you do this? And when can it be done? And it's a tricky situation to be in. And this seems like a powerful way to get at that though. It looks like it takes a lot of time and structure to get there.

Alyssa Erickson:

Definitely, yeah, estimating is not an easy task. And even in that team, we did our planning poker for a long time. And then after a while, we got so used to working together on and what we could accomplish, we sort of moved away from using those estimates. And so we became a little less strict and how we implemented Scrum in that way and started just being more flexible in the way we thought about tasks. And I think we stopped using the numbering system,

Greg Williams:

period. So when you're estimating on these tasks, like what what makes up a task is it like I'm trying to think create a story reboard or create a design document or or like, what did that look like?

Alyssa Erickson:

Yeah, a couple examples would be creating a storyboard Exactly. And then it might be just editing one video or one section of the course. And sometimes we'd have to split things out if it felt like too large of a task. And the numbers helped us figure that out, too. If it was going to be over 13 points, then we're like, Okay, is there an opportunity to split this up a bit? One way that I thought was really clever. So Megan Torrence, you mentioned her work and highly recommend her book, she has some suggestions for making sure that tasks are not going to take more than I think it was 30 minutes to maybe four hours of effort, like a half a day of effort. And if it's larger than that, then splitting it up.

Greg Williams:

Okay, so you'd have these different tasks, and then you'd be able to estimate and gather them. That's that makes sense. With all of that work, then you you've moved on, because you're now at Qualtrics. And as you've mentioned before, the structure and the makeup of both the people on the team, your physical environment, and more, can really influence how, how a team works. So what does that look like, in your current role?

Alyssa Erickson:

Yeah, so my current team is made up of learning experience designers, e also have a project manager. ut essentially, we don't have he same specialized roles that explained that we had at state ood safety, you know, we don't ave an illustrator or an edit ditor, people dedicated to hose things. So the way that we ork together differs. And I am lad that Qualtrics is willing o let us be scrappy, and xperiment with processes. As 've overseen the curriculum, 've been thinking of different ays of implementing agile, or a ybrid method of Agile in what e do. So one example of that s, in a set of courses that ere expected to complete in a uarter, I would organize a crum team. And we would decide ho's working on what course and ecide on what our sprints would e. And usually, we have pretty imple outline of the Sprint's, uch as, okay, this week is oing to be dedicated to nalysis and having a kickoff eeting. And these two weeks are oing to be dedicated to evelopment and getting a first ersion out there or a really olid prototype. And then here's going to be a week for ur stakeholders to review that nd give us feedback. So that's n example of how we've mplemented Scrum on a smaller cale on our team. And we have ried using tools like Asana to reate a Kanban method of racking tasks. And that ctually kind of fizzled out for s, it didn't quite fit our eeds, because the company lready has a way for us to put ur weekly tasks in the system. nd so it felt kind of edundant, having in two places, nd it wasn't getting updated as uch. So it definitely takes ome intentional effort to mplement some of these ifferent tools. And sometimes t might not fit. So I'd say tay flexible. If you're hinking about your own team and our own projects, and how maybe ou can implement agile, stay lexible, look at those agile rinciples, see which ones make ense for your team and maybe teratively or gradually start o experiment with them.

Greg Williams:

Yeah, I'm glad you mentioned tools, because tools are our that their instruments that are only as good as the way we use them. And I found that that is tends to be another one of those barriers, like you were talking about, where if the team can't agree kind of where they're doing the work, you know, where, where are we going to visualize this? And if if everyone's not using it, or, or even if it's just a general system, it can be really difficult to have that tight communication.

Alyssa Erickson:

It's so true, yes, you have to find what works with the processes that are already going on and the culture of the team. But that doesn't mean it's not worth experimenting and seeing, okay, is there a way we can change what we've been doing?

Greg Williams:

And so in your role, they're called tricks. You mentioned you have these different planning sessions where you kind of identify what you want to accomplish. Do you have like a regular sprint cadence? And follow some of these same principles you've discussed, like around Scrum, or does that look a little different?

Alyssa Erickson:

Yeah, so it looks a little bit different. We meet once a week as a scrum team for curriculum to plan out what we're going to do we actually do that question of, Okay, what did I work on last week now, what I'm planning to work on next week, and what roadblocks do I have? So instead of having a daily standup, we kind of have this clear meeting instead? That's one adaptation we've had. And then, yeah, from there, we, we work together and we usually use slack to communicate throughout the week. If we have any roadblocks that come up day to day, we We'll use our digital tools like slack to communicate that.

Greg Williams:

Now, is this distinctly separate from like a regular team meeting? Or how does all of these, I've heard them called agile ceremonies? Or just meetings or operating mechanisms? How are they similar or different than more traditional, like, one on ones with your manager, a team meeting or a department meeting and that kind of thing?

Alyssa Erickson:

Yeah, for us, we have a weekly tactical meeting with our team. Usually, that meeting is talking about items of business or, or things that the whole team should be aware of, but doesn't get into the nitty gritty details of the tasks that we're working on, and how we can remove roadblocks. So I'd say that these sprint planning meetings essentially, are with the objective to really look at the tasks we're going to be working on and what might get in the way and how we can help each other as a scrum team. Whereas other meetings, and one on ones might be a little bit more focused on the big picture or things that the whole team needs to be aware of, rather than the specifics of the tasks and projects?

Greg Williams:

Yeah, that's helpful. I know, for many folks meetings are not probably the most exciting topic, and yet we're in them so much, at least I feel like I am. I feel like it definitely warrants time and energy to think about how one is running meetings or participating in them. And whether that's actually helping the needle move on the declared work you want to do in a given quarter or a year. Okay, so with all this, this might fall flat on its face, but this won't be a full on roleplay or anything crazy like that. But I wondered if you could with him for a minute with me. Maybe think through a hypothetical, or it could be based on something real, I don't know, situation where we're we're going to kind of go through some of this Agile process, if we were to think I'm going to maybe put out a scenario that's, you know, fairly standard and could be approached in a waterfall method. And then I'd love to hear your takes on like, how we could tweak that to work more agilely? is that sound? Okay? Sure. I love this idea. Let's jump in. Okay, let's say I am working with a group of sales folks. And I'm getting feedback from stakeholders that they are not hitting quota, they seem a little stressed out. But their sales are not going through. And the business leaders think it's probably a lack of knowledge. So let's get them trained up. So they'll hit quota. Can you create a learning solution or a learning course to solve the problem? Now, we could take this scenario a million directions, right? Like let's do a deep dive real analysis with their stakeholder and all that. Let's say we've done that, and we've kind of got a direction to go. Normally, from waterfall, I might say, Okay, I'm going to map out my learning objectives. Alright, I'm going to do kind of the basic analysis of like, Do I know their learning environment? Do I know who they are as as learners. And now I'm going to create my objectives, maybe an outline, maybe storyboard because I'm going to do an E learning, I've decided on that, I'm probably going to then move my team towards like, Okay, we've got a good plan. And maybe a suite has approved the design document, which has gone from half a page to like 15 pages, with all the things and I decide, all right, this is looking good. And then we start developing out the elearning, based on our storyboards, and it's all great. And then we scheduled the training with the different sales leaders, we implement it, we get a survey and sales rep say it was pretty good. And then we watch to see if it's made a change to their sales numbers. And maybe it does, maybe it doesn't. And there's that. So if we were to rewind and say, like, let's look at this with a more agile mindset, can you talk me through like, what are some specific things we might do to achieve this objective, but maybe more rapidly or more effectively with an agile brain?

Alyssa Erickson:

Yeah, okay. I like this challenge, because what you outlined is a very typical approach. And, you know, it could be effective, but I'm excited to apply an agile that lens to it. So yes, taking that problem of salespeople not meeting their quotas. Let's just say in your analysis, we saw that one of the big problems was that the sales people weren't asking enough questions. In their conversations. They were just jumping to solutions, assuming that okay, this shiny piece of technology is going to meet the buyers needs, but they really needed to do some more discovery or asking good questions to understand buyer pain points. So that ends up being kind of the the problem underlying behavior that we're getting To address with. And in making this a more agile process, I think one thing to consider is okay, how can we split this up into more manageable chunks that could become iterations of the course. So perhaps you focus just on the objective of, you know, wanting to have a sales person, ask a question, instead of just talking and create a short learning, maybe just a micro learning with an activity that helps reinforce that behavior and remind them to respond with a question. And so you could create a storyboard or, or outline of this and run it past a stakeholder. And I would say, even including the target audience, or the learners would be very valuable. So having a rep take a look and say, You know what, this actually helped me with this behavior, and then moving to actually create a working prototype of that. So maybe you use a tool like articulate rise to quickly create an outline of what this would look like, or, you know, without high fidelity images, or fancy animations, and activity that that would work and be testable. So that's one way you could iterate and start looking at this project with an agile mindset and test that with a group of sales reps, or your learners get their reactions and feedback, and then do another iteration to make it a little bit more. A little bit more professional or fancy looking. Yeah, does that make sense?

Greg Williams:

Yeah, I think the biggest thing that I'm hearing what you're saying is, like, let's break this down. And let's keep a really razor sharp focus on the objective here that like the result, right. And, you know, we, as I mentioned, we could take a full on rest of the podcast or another podcast to talk about analysis, and whether trainings actually even needed and whether of course, is the actual solution, right. But I want to set that aside for a second, because we're focusing on this project management. It seems like what you're describing is not crazy different, like you still need to develop a thing, right, and put it in front of someone. But instead of like, Alright, let's develop this over the next month or over the next three weeks, it's what could we do to get this in front of someone at the end of this week? And then see if it's starting to make a difference? Or if the reaction is such that we think it's going to help us get closer to the goal? I don't know. Is that a fair summary of what you're describing?

Alyssa Erickson:

Yes, definitely. And I'd say it also gives you that flexibility to make changes. Because if you're testing it with someone, you're seeing that it's not hitting the mark, or there's some kind of business change that is like, Oh, actually, we're going to use this messaging when we sell then you can easily make that change, because you haven't gotten too far in the process. And you can flexibly go back and make a quick redesign and then test that iteration again. So that's another advantage of an agile mindset is, you don't have to be stuck with what your initial analysis told you. You can learn along the way and make changes based on the needs that you see emerge.

Greg Williams:

Yeah, that he evaluation is looping regularly. And I imagine as you're getting the feedback, whether it's from your learners, or the stakeholder who's saying, actually requirements are changing, instead of having that sinking feeling in your heart, like Dang it, those awesome animations, we spent three months on our now mood. It's like, Okay, cool. Let's swap that out. And let's, let's get this updated. And you really realizing those things as a part of those sprint planning sessions and retrospectives really reflecting on success? Like, I guess, if you're not having those, then then you can't move as nimbly.

Alyssa Erickson:

That's very true. Yeah. And then you can also be, as you're testing out, maybe one of these micro learnings can think about the whole learning experience, it doesn't have to be just like one e learning course, or one training. It's like, how can we continually reinforce this concept with people? So maybe you do a set of micro learnings that come out at different times? Or maybe you think about how managers can help reinforce the learning and their team trainings or one on ones? And so I think this agile mindset can also help us see different solutions, and not just get stuck in a one size fits all training solution.

Greg Williams:

Yeah, I think that's so important. And it goes with what we're kind of describing is not everything needs to be a training and one way maybe using agile is to focus on that end result and maybe a job aid or knowledge article or, you know, a desk drop is more than sufficient to help get to the goal. This is wonderful. Thank you for going through that. typical example with me. And I know it was fairly simplistic, but I know it's helpful for me to kind of illustrate and put color to some of the things we've been describing. As we're wrapping up, I'm, I'm curious if there has been something that you haven't talked about, but that you feel has been a really significant learning experience for you and your own development as a person or professional. I wonder if you could share a little bit about that.

Alyssa Erickson:

Yeah, as a learning experience, designer, I'm definitely someone who loves to learn. And lately, actually, one thing that has been a great learning experience for me actually emerged from one of your podcast episodes, Greg, it was talking about behavior change, and tiny habits, bJ foggs model, and essentially finding ways in my daily life where I can see a trigger or some way to remind myself to do a little habit. So one example has been, I've been trying to learn a little bit of Mandarin Chinese. And I kept forgetting to use this app on my phone, hello, Chinese. I just couldn't remember to do it during the day. But I use that tiny habits approach to decide, okay, right after I finish lunch, I'm going to pull out my phone and do it right here. And for physical fitness. Another example is, after I go to the restroom, when I come back to my desk, instead of sitting down, I'm going to do five push ups. So I think there are a lot of ways to apply that idea of behavior change and finding tiny habits to even learning experience designs, and how we can look at people's habits and help them form triggers in their days to remember to do certain things, like with our example, like, how do we help them remember to ask a question, instead of just talking on a phone call with a client?

Greg Williams:

That's great. And it's funny, I have the same physical fitness goal and have it as well. And I've been wondering, when I go back to the office, am I gonna be? Am I going to still do push ups next to my desk? Or am I going to be too ashamed and embarrassed? So now that I've publicly talked about it, maybe I'll commit to doing push ups regardless, even though I'm not in my own office anymore?

Alyssa Erickson:

We should normalize this. Yes, I've had the same concern, you know, is this going to be socially acceptable, but maybe it starts here, people can? Yeah.

Greg Williams:

Oh, that's wonderful. It's a great learning that continues to learn is that that habit framework is really powerful. And I'll be sure to put a link in the show notes to bJ foggs website where it has that model, and also a previous episode I did with Andrew Webb, about some of those principles. I'm wondering, we've talked about a lot of things. And for some folks, if they're really new to agile principles, it might be kind of overwhelming. Is there maybe one suggested action for someone listening right now that you'd recommend to, to just get started in Agile?

Alyssa Erickson:

Yeah, I would say start small for sure. And think about maybe just one agile principle that applies to the work that you do. So you could even just Google principles of agile and take a look at the list and see what resonates. Maybe it's simplifying your processes. Maybe it's getting continuous feedback from stakeholders, maybe adding just one more round of feedback or trying to have more consistent evaluation happening. Getting things in front of your learners might just be something small, where you see an opportunity to add flexibility or iterations to what you're currently doing. But yeah, find what works for you experiment. Maybe try a new tool and see if it works. And yeah, just keep in mind that a hybrid approach is not a bad approach.

Greg Williams:

You've mentioned a couple of resources. Other other any other resources recommendations you have for folks to learn more about some of the things that we've discussed?

Alyssa Erickson:

Yeah, I would definitely recommend Megan Lawrence's book, agile for instructional designers. That has been a really great guide book for me. And she has a lot of great articles online as well. And then that book, I mentioned that we use that my one job, which is the art of doing twice the work and half the time by Jeff Sutherland is really good tactical book with lots of examples of how Scrum can be used in different work settings.

Greg Williams:

Wonderful. Well, Alyssa, this has been a really great walk through many experiences to get a sense of agile. And I appreciate your time preparation and thoughts and sharing them with me and everybody listening. Of course. Yeah, it was my pleasure. Thank you so much, Greg.