In 2022, Dashe & Thomson collaborated with The American College of Chest Physicians to develop an interactive eLearning card game for COPD diagnosis and treatment. Due to complex and constrictive timelines, the Dashe team chose to implement some elements of the agile project management approach to maximize efficiency and collaboration.
Following completion of the project, Dashe Project Manager Samantha Romo sat down with Dashe CEO Rose Benedicks to discuss the success and potential future use of agile strategies in learning and development.
What was your experience with agile before this project? Can you briefly describe the scope of the project?
I didn’t have any experience using agile project management methodology before this project. I knew what it was and that it was a common practice used primarily with software development, but I hadn’t really thought of agile beyond that. I will say that after you, Rose, mentioned it, I did A LOT of research on how it could be implemented for an L&D project. I read blog posts on how other people used it, thought through the Agile Manifesto and how that could be applied to our team, and then mapped out everything we knew about the project using the agile methodology.
This was your first experience with agile. What made you think this game project was a good fit?
Agile was useful in this project because our client wanted a complex game completed with a very quick turnaround. They wanted to showcase it at an annual conference, and we had only six weeks to create a game from start to finish. If we wanted to use the traditional waterfall project management approach, we wouldn’t have time for all the review cycles or a distinct design and then development process. The agile methodology fit the timeframe and enabled us to deliver exactly what the client wanted, quickly.
I knew agile PM would provide us with a faster start, would keep our team more in touch with each other, and would eliminate the starts and stops for review cycles (because we’re doing them live) that you would have in a traditional project.
What elements of agile did you use? Which ones didn’t you use?
The most important element of agile that we leveraged was the constant connection of the whole team, so I guess you could say scrums. We started off with scheduling two touchpoint meetings and a live review session each week. In a traditional agile process, we would have met every day, but that just wasn’t possible given the team structure. We did use the standups as scrums, though, and covered what our sprint content would be for that week. We ultimately chose to use one week sprint periods instead of the traditional two weeks, which deviated slightly from standard agile structure. These slight tweaks allowed us to meet the exact needs of the client.
The other important element of agile framework that we used was continuing development cycles – after each live review, we jumped right into development again, making edits and updates as part of the next sprint.
In a traditional agile framework, parts of the project would be released while other parts were still in development. Agile lets you get to an MVP and maintain a backlog of features to integrate, but that’s with a traditional use of agile in software development, so we didn’t use that here. Well, actually, toward the end we were putting out releases that met the minimum requirements for legal reviews, user testing, and so on. So perhaps we did, at least a bit.
There is another place where we deviated from agile: Usually in agile your developers are leading the standups and discussing what their tasks are for the sprints, and we didn’t really do that. Instead, I think I played more of a management role of what those tasks would be instead of letting the team decide. And took a little stronger role in making sure we were on track.
Essentially, we used an agile approach with me as the project manager and scrum master.
What parts of our traditional “waterfall” PM structure did you use?
We still did the traditional internal and external kickoffs and because the client had the content for us in a storyboard format, we got started quickly. If they hadn’t, we would have had to do some typical waterfall process to get that content ready. That’s really it.
What worked?
Having a team that was onboard with the idea was critical. If we didn’t have the team ready and available to work as one and stay close, you know, ready to move quickly and available for the standups and live reviews, it would have fallen to pieces. It worked because the team was available to run this as a mingled agile-traditional process.
Weekly sprints were also very clear. It was nice to have a specific list of what needed to be done in each sprint. And that evolved.
Standups and live reviews really helped to make sure everyone was aligned and on track for the week. The live reviews kept us moving forward quickly because we could start developing the very next day off of the feedback—since we were discussing it live, we were able to make actionable decisions right then and there, and then continue in the development loop. Continuously updating the project was really the key to this project’s success.
What didn’t work?
I don’t know if we would necessarily change this, but because we (fortunately) were provided content and because we started development of content immediately, we did have to backtrack when content changed (mostly due to legal reviews). This caused changes at the end of the project that we wouldn’t necessarily have had to update if we had a waterfall process with a gate for content finality. So, while we were still developing, we had other review cycles going (with legal) that had to be addressed after the fact.
I’m not sure if we would change anything. I thought it went very well. And so did the client.
We haven’t had our lessons learned yet, because they have some 2023 regulation changes we need to incorporate.
On second thought, if we were to do it over again, we would include legal in the review cycles. Now whether they would actually be able to do that or not, I don’t know.
Would you use the agile approach again?
Yeah, absolutely. It was a worthwhile experience, both in a challenging sense and in the sense of doing something different and successful.
If the timeframe required it and we had the right team like we did this time, it definitely sped up the project and if needed or wanted it’s a valuable method to implement.
Another reason I would do it again is because every single person on the project knew what was going on, what needed to happen, and could make it happen throughout the entire project.
What advice do you have for anyone who wants to use agile?
Do your research and make sure you understand the methodology. After you have your understanding of how you want to use it, know that you don’t have to follow the agile method 100% for it to work in L&D. You can use parts of agile and waterfall—intelligently—to achieve what’s needed. Use your team to help you understand what’s needed, what to add, and when to do it. Let them help you define the sprints. Make sure you’re ready to be a fast starter and able to give continuous attention throughout sprints. You have to be ready to know how the history of the project informs the rest of the project very fast because you have those continuous development cycles and not a lot of pause.
