Agile Methodology Meets Backward Design: Transforming Faculty-ID Collaboration in Higher Education

You know the drill: You're a few weeks into a course development project. You've had your kickoff meeting with faculty, and, if you're using backward design, one of the first things discussed was completing the course map before moving forward. You're set to meet weekly, but now you're waiting and exchanging emails about learning objectives and course mapping just to get started on development. Eventually, you give in and start designing with only a partially complete course map. Throughout development, the faculty member keeps delaying or shifting the course map, adding "just one more topic we have to cover," while you're trying to explain why the outcomes or objectives are not measurable or that the outcomes and assessments aren't aligned. Wiggins and McTighe (2005) might call this the faculty focusing on the input, and the instructional designer focusing on the student output. Either way, you feel like the design police, they feel micromanaged, and then the project falls behind due to scope creep. Sound familiar?

This dynamic seemed way too common in my work as a new instructional designer at a large regional community college. Despite my best intentions to create collaborative partnerships, we inevitably fell into predictable roles: they were the content experts sending me materials, and I was the person who managed technology and made things look nice in the learning management system.

About Me: How I Discovered Agile

In 2021, about a year after my transition from full-time faculty to full-time instructional designer, I participated in a 48-hour international virtual hackathon where I served as project manager for our second-place team. While I felt comfortable in team management, I'd never had formal training in project management. When I started researching project management, I discovered Agile Scrum.

According to the Agile Alliance (2025), Agile methodology, originally developed for software development, centers on iterative progress, collaborative decision-making, and rapid response to change. Rather than following rigid, sequential phases, Agile Scrum teams work in short cycles called "sprints"—focused work periods typically lasting 1-4 weeks. Teams create working prototypes (Minimum Viable Products or MVPs—basic working versions that can be tested and refined) early and improve them based on continuous feedback. Key Agile principles include prioritizing individuals and interactions over processes, embracing change rather than following a fixed plan, and maintaining close collaboration between all stakeholders throughout the project (Beck et al., 2001). What drew me to Agile Scrum wasn't just its efficiency, but its emphasis on shared ownership and equitable partnership—values that seemed directly applicable to the faculty-ID collaboration challenges I was experiencing.

A few months after the virtual hackathon, a colleague offered an Agile in Education Scrum Master course. Learning Agile impacted my approach not only to organizing development, but also to communication and teamwork. It immediately enhanced my collaborations and course development.

Why Backward Design + Agile?

Backward Design (Wiggins & McTighe, 2005) provides a rigorous three-stage framework: (1) identify desired learning results, (2) determine acceptable evidence of learning, and (3) plan learning experiences and instruction. This ensures alignment between what we want students to learn, how we assess that learning, and what activities support it. However, in practice, Stage 1 often becomes a bottleneck—faculty struggle to complete comprehensive course mapping up front, delaying development and creating hierarchical dynamics in which IDs become enforcers of the framework.

Agile Scrum methodology offers a solution. By breaking Stage 1 into collaborative sprints focused on individual modules rather than entire courses, we maintain Backward Design's alignment rigor while avoiding the paralysis of upfront planning. User stories (brief descriptions from the student perspective: "As a [type of student], I want [goal] so that [benefit]") keep Stage 1 grounded in real learner needs. MVP prototyping allows us to move through all three stages for one module, test it, and refine—rather than attempting to perfect an entire course before any validation. The sprint structure (short, focused work cycles with regular check-ins) maintains momentum, while the "backlog" (a prioritized to-do list) ensures we never lose sight of the remaining modules. Essentially, Agile provides the collaboration tools and iterative structure that allow Backward Design's pedagogical framework to function as intended—as a partnership rather than a hierarchy.

What I Tried

After my Agile Scrum Master certification, I realized Backward Design and Agile could complement each other perfectly. Some of my recent courses where I integrated this approach include a Sociology course and multiple OER basic language series courses. When I approached faculty with the idea of trying something different, their responses were immediately positive. Our plan was to write user stories and create MVP prototypes for the first course content module that we could review, test, and refine iteratively, rather than trying to perfect entire courses before getting any feedback.

The Six-Step Process

Step 1: Blueprint Together - A 1-hour collaborative session developing course-level outcomes and first module-level objectives together. Both parties are working on Zoom, writing, discussing, and revising in real-time. Results: outcomes neither could create alone, establishing trust that allowed faculty to draft the following module objectives with me refining language asynchronously afterward.

Step 2: Write Student/User Stories - After discussing examples, faculty developed user stories reflecting diverse populations: "As a heritage speaker..." "As a complete beginner..." "As a religious studies major…, I want [goal] so that [reason/benefit]" (see Appendix for detailed examples). This kept us anchored to real student needs.

Step 3: Break It Down - We defined the minimum viable product with assistance from course mapping through backward design, creating a prioritized module backlog with clear "done" criteria. Each module functioned as an MVP—complete enough for student learning, designed for iteration. We used Google Docs for tracking progress.

Step 4: Sprint Cycle + Development - Focused 2-4 week cycles with specific development goals. We included 30-minute to 1-hour sprint planning meetings every few weeks, creating regular celebration and course correction opportunities. These sprints allowed us to visually see progress, address challenges, devise solutions, and move forward.

Step 5: Structured Check-ins - Weekly 30-minute meetings with set agenda: What we completed, current challenges, next sprint needs/action items, and scope changes (technology or content shifts). These were more effective than lengthy status meetings.

Step 6: Review and Celebrate - End-of-sprint demos, documenting lessons learned, shared ownership and pride in collaborative work.

What Actually Happened

Relationship Transformation: All faculty members expressed that they felt valued for their teaching expertise while learning to trust my learning design expertise. Decision-making became truly collaborative—both perspectives shaped final activities.

Enhanced Alignment and Consistency: The collaborative approach helped faculty understand how backward design creates stronger courses. For example, when we initially planned traditional grammar quizzes for foreign language courses, our joint review of user stories and language proficiency benchmarks revealed a mismatch—our learners needed conversational skills. This led us to redesign assessments around authentic communication scenarios, creating better alignment between stated outcomes and how we measured success.

Course Quality Improvements: Increased collaboration led to innovations neither could create independently, like interactive podcast lectures, AI tutor-supported language proficiency development, and creative project-based assessments where students created scenarios using Adobe tools. Regular sprint reviews allowed mid-development stakeholder feedback and iterative improvement.

Unexpected Challenges: OER courses require more extensive development work, and foreign language courses compound this with 5 credit hours and numerous formative assessments. Arabic and Hebrew's right-to-left text orientation created significant technical challenges in third-party tools (H5P, Playposit, Panopto). The podcast-learning approach, while innovative, created timeline challenges as faculty worked to create captions in English and Hebrew.

Reality Check: Timeline outcomes varied significantly by project complexity. Sociology, with simpler content requirements and only a 3-credit course, completed in 5 weeks versus the typical 8-12 weeks. The first Arabic and Hebrew OER course took over 16 weeks due to right-to-left text challenges with 3rd part tools, but subsequent courses became progressively faster as we refined our approach. Having an MVP and a completed first course established the foundations and templates that enabled significantly faster development for the second, third, and fourth courses, provided the content was ready. While individual project timelines varied, the course series approach demonstrated clear efficiency gains, and teams consistently found the process more collaborative and productive.

Your Implementation Guide

Before Starting: Begin with your standard kickoff meeting to understand the course, students, and project scope. Then introduce the collaborative, iterative partnership model, framing it as one that honors both content and instructional design expertise equally. Choose accessible tools, such as Google Docs or another project management tool, that both parties can access and use comfortably.

First Blueprint Session: 60-minute collaborative outcome development. Ask questions drawing out faculty expertise: "What would successful students do?" Guide toward measurable outcomes without controlling content.

Sprint Structure:

1. Planning (30 min): Review backlog, choose 1-2 modules, define "done" criteria

2. Mid-sprint check-in (15 min): Surface problems early, adjust scope if needed

3. Review + Retrospective (30 min): Demo completed modules and gather feedback, especially valuable if students or student workers can test your work. Then briefly reflect as a team: what went well, what to improve in the next sprint.

Adaptation Tips: Simpler content allows 2-week sprints covering multiple modules. Language courses, especially OER, may require consideration of 3rd-party tool testing.

Troubleshooting:

1. "More work" concerns: Emphasize different work feel—once the MVP is complete, work becomes more iterative and efficient

2. Resistant faculty: Start with one element, demonstrate value through small successes

3. Timeline pressure: Focus on quality improvements and partnership satisfaction

Measuring Success

Immediate indicators: Both parties actively contribute to discussions, share decision ownership, and collaborate on problem-solving.

Medium-term: Strong outcome-assessment-activity alignment, faculty willingness to repeat the approach, and improved student engagement evidence when possible.

Simple tracking: After each sprint, ask—What worked well? What would we change? How satisfied are you with your accomplishments?

What's Next

This approach became my default for course development partnerships. I've adapted it across content complexity levels and am currently developing templates for other instructional designers. The most exciting development: faculty members now request this collaborative approach for new projects.

Your Turn

Start with collaborative outcomes and first module objectives development in your next project. Spend one hour co-creating the first module's learning objectives instead of asking faculty to complete a course map independently. Pay attention to how the dynamic feels different when both parties contribute expertise equally.

Think of it like learning relay handoffs—you wouldn't perfect your technique by running solo laps. You need to practice the exchange with your teammate, adjusting your pace and timing until the baton transfer becomes seamless. Some faculty will have a different running style, others will need more practice with the handoff, but every partnership has the potential to cross the finish line stronger together.

Document your experiments and share what works in your environment. The instructional design field benefits when we move beyond solo sprints toward partnerships that leverage everyone's professional expertise.

References

1. Agile Alliance. (2025). Agile Essentials: Agile 101. PMI Agile Alliance. https://agilealliance.org/agile101/
2. Beck, K., et al. (2001). The Agile Manifesto. Agile Alliance. http://agilemanifesto.org/
3. Wiggins, G., & McTighe, J. (2005). Understanding by design. Association for Supervision & Curriculum Development.

Appendix

User Stories for Hebrew 101