We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
That is, while there is value in the items on
- Responding to change over following a plan
the right, we value the items on the left more.
My brother-in-law and I have had many discussion regarding the merits of Agile development versus traditional requirements based development (frequently referred to as "waterfall" development). For me it was all theory, until recently.
This year I took a position as the director of online learning for a christian school in Michigan. One of the projects that I began was the development of a series of online Bible courses. These were courses that we could not find elsewhere and were forced to develop on our own.
In late spring we hired a company to assist us with the development of our first one semester course. The course was to be modeled off of an existing class that is taught at the school. The teacher of the course agreed to be the subject matter expert and modify his lesson plans for an online environment. The company we hired provided the curriculum designer and technical programming expertise.
Six months later our development continues and we have nothing tangible to review or display for our time, energy, and efforts. The process continues, but the going is slow. Until all of the lessons are written (we are on lesson 20 of 30), the design and technical implementation process can't begin. When the project finishes (and it will), the company will deliver the course to us in its final form.
As an observer and participant in this process, I can't help but wonder if there is a different way to develop courses. Could the principles of Agile development be applied to course design, significantly reducing development time, and lowering overall costs.
[side note: In no way am I insinuating that the company we hired to help us develop this course is doing a poor job. They have a well defined process and I am confident that the final product will be of excellent quality. This post is response to observations I have made about the process of course development in general.]
The Agile Course Development Manifesto:
- Assemble a small, focused team: curriculum designer, subject matter expert(s), and customer (school) representative that works together on a daily basis, not in isolation.
- Build and release small packages of content (lessons) to be assembled into a larger whole. Each content package will be fully assembled (content, media and assessment) and release on a weekly basis.
- The design team works together instead of as individual entities. The SME shares the vision of the lesson and the curriculum designer leverages technology to make it work, on a daily/weekly basis.
- As the understanding of the requirements and scope of the course unfold, the team response to correct and modify past lessons to support future lessons. All team members expect that change will happen and view it as part of the process, not as a situation to be avoided.
The typical Agile model of development avoids long lists of requirements to prevent bogging down the process. With course development, a change must be made to this philosophy in order to ensure the usability of the course. Prior to the start of development, a list of required state and national standards should be compiled to help guide the development. General assessment guidelines should also be determined (minimum number of multiple choice questions per unit, number of assessments, types of assessments, etc). True to the Agile philosophy, however, these specification can be modified as necessary throughout the process.
The application of this Agile form of development with the rapid release of course modules would allow the faster deployment of the course to students, even during development. Because long-term projects frequently stall due to poor communication and process bottlenecks, the Agile model has the potential to speed up the process. Faster development means more capacity to develop, which reduces overall costs.
This posts represents my first public announcement of my idea. Undoubtedly there are flaws and weaknesses in my logic for which I would seek your comment and review. If you would be interested in exploring this methodology with me further, please contact me so that we can continue this discussion and see where this idea leads.