You read about agile curriculum development on the internet. You attend conferences to learn about it. You even discuss it with your colleagues. But what is holding you back from making the leap?
About four years ago, I was that person. I had impressions of what agile curriculum development would mean to me and my team. It held me back. Below are the reasons why I resisted, and what follows are my thoughts on those reasons.
My original blockers were:
- It is a heavy lift
- I need to be technical
- I won’t get buy in
- My team’s productivity will slow down
- What I am doing is working
It is a heavy lift
Doing something new and different can be a lot of work, at first. Moving to agile curriculum development requires new ways of managing projects, team members who are trained in the methodology, and tools that support the methodology. So yes, there is some heavy lifting to do; there’s no denying that. I have found, however, the effort to be worth the results. Agile curriculum development is a concrete method to which team members can latch. The team accountability and self-ownership gains are extremely valuable.
I need to be technical
Agile may have started out as methodology for technical implementers, but it has evolved to be more business friendly. You can use the techniques for just about anything; from coding software to, yes, even planning a family reunion. You do not need to be technical to learn about Scrum roles and ceremonies, Kanban boards, and team velocity. You need to be someone who thinks like a project manager. Getting organized and aligned to the methodology is the biggest barrier.
I won’t get buy in
I work for a software company already using agile in the engineering side of the house. They have teams well-versed in the use of agile implementation best practices. I was able to align my groups to the Engineering group; a group much bigger in size and more well-connected than my training and development group. I utilized that relationship to get buy in from my business stakeholders.
The move to agile meant iterative training content. Stakeholders were used to seeing fully published courses they could promote or add to their learning paths, not a module here or a video there. Was there some resistance? Absolutely. But when they saw that they could get smaller pieces of learning content that was more closely tied to new features and functionalities, they found that waiting for the done-done courses was not as critical. The chunking of content also made it easier (not perfect but better) to get SME’s to review content.
My team’s productivity will slow down
Ok, I’ll be honest: sprint 0 and sprint 1 were not great. But by sprint 2 things got better. Now, many sprints later, the teams run smoothly. They have a strong handle on how much work they can do in any given sprint. They constantly discuss ways to be more efficient. And because of the tracking in scrum, I can better predict when training content will be available.
What I am doing is working
When I was doing more ADDIE like development, I knew that training content was either in progress or done. But everything seemed to take so long. I also had a hard time reporting status to senior management.
I researched other models such as Successive Approximation Model (SAM) and Rapid Application Development (RAD). They felt like models trying to make agile work in their familiar, already known curriculum development models.
For me, it was easier to go all in agile and adapt it to what I liked best about curriculum development methods I had used in the past. The benefits for me are tangible. I have content that is done-done at the end of every sprint. I easily report status to my leadership. I have teams who are accountable for their work. There is no going back for me.
Have I given you something to think about? Are you ready to make the leap? A simple internet search on “Agile Curriculum Development” will get you far. But if you are ready to get started, talk to someone like me who has done it.
