I would like my students to get the most out of the course by experiencing an agile development structure in their projects. Currently I give 5 assignments, each building on the previous one and adding to the complexity of the final product. Although this is far from letting students experience "real" agile development, it is a first step. How can I incorporate an agile development methodology backbone to the course, letting students experience it first-hand? The courses are taught in Python (CS1) and Java (CS2) and this is an Applied Information Technology program.
Agile is great, but it's mostly about how to manage the development process, interact between the different parties involved, communicate status and break down larger projects of work into achievable segments. When you're trying to understand what a loop/function/class/object/etc is there's really no need to also think about the software engineering issues for larger projects, teams, etc. Students only have capacity to learn so much and I'd argue it's counterproductive to have them spend some of their attention on learning agile.
By all means talk about it if you're looking at software engineering practices, but it shouldn't be a focus.
Test driven development might be ok to teach, although I suspect it will just complicate things for new students.
Agile is about more than software engineering. The individual practices of, for example XP, are just good programming practice. In addition they can be incorporated into your pedagogy. Test First, for example, helps students to get it right, but also to avoid writing things unnecessarily. "Just make the test pass." Likewise, Pair Programming can be used to make the learning a more social process and to help students help each other get over the inevitable humps. But that assumes you, the teacher, enforce switching of roles, both within a pair and within the entire class.
You can, especially in early assignments, provide the tests, or at least some of them. The negative aspect of this is that the tests include the names of public methods of the classes as well as class names. This implies that you have done some of the design of the solution already. This has positive pedagogical implications for beginners who often are stuck on a blank page, not knowing where to begin.
Finally, here, you can present early problems as a "product backlog" rather than a long description of the problem. Again, this implies that you have decomposed the problem yourself into meaningful chunks. This too is helpful to the beginner.
So, you don't need to think about Agile Development in the large, just about which practices enhance student learning. In general, take a more explicit role as Customer/Product Owner so that student program becomes a conversation.
I think it is a good idea to introduce students to Agile concepts, since they're likely to see this in the real world. However I wouldn't dwell on it too much. Some people, even on real projects, get so caught up in the lingo, point systems, tools, etc. that managing a project takes on a life of its own.
A lightweight Agile process that would fit into a classroom situation could be as simple as 1 or 2 week sprints, with a planning meeting at the beginning where tasks are estimated, brief daily morning meetings (scrums), and a post-mortem on the last day. Scrums should be brief, focusing on tasking and eliminating blockers.
This kind of process really only applies to team situations so if the students are working solo it might not reveal much to them.
Uncle Long Hair gave a perfectly good answer. I'm adding information about a particular CS course for high schools that does include Agile. The Project Lead The Way curriculum for AP CS Principles has students divide their work on a project into a prioritized backlog and divide the top backlog item into a sprint task list where each item on the list can be accomplished in a small amount of time. Students aim to knock out two sprint tasks per session, and a sprint lasts a week. Work on a project might last two weeks. A sprint lasts a week with Scrum standup at the end of the week, where students report progress. That's not really what is supposed to happen in a standup, but it works in the classroom. The teacher serves the role of the Scrum master.
Students are exposed to the lingo with a "Scrum in 10 minutes" video. After they've done it for a few projects, Scrum poker is added in one activity because some teachers and students find the mechanics fun and lets the class talk about the importance and difficulty (especially for beginners) of estimating how long something will take.
For some teachers, once or more during the year, pairs create the problem they intend to solve and then swap with another pair and solve someone else's problem. This provides a client, albeit without engaging the community.
Ensure that you have experience first
The worse thing you can do is tell them that they are doing agile, but then do something that does not work. (This seems to be the normal approach in industry.) It will lead them to think that agile does not work. So first ensure that you have a good grasp of the concepts.
Select some useful agile practices
«Test first», and «one thing at a time», are very useful tools in teaching (but without automation, until later). Having students just do one thing at a time, can help to rid the feeling of being over whelmed. Planing a test before writing code, helps students to think about what it is that they are trying to do. Another similar technique is «re-write the assignment in your own words».
«Pair programming» from XP, is also useful. Groups and pairs have been shown to help learning.
«You are not going to need it»: is there anything that you are producing, that you don't need yet. Don't produce it until you need it.
«Automate it»: So you got to the end and did not need a flow chart, so did not make one. But the examiner insists that you need one in your design. Therefore use a tool to generate one from you code (they will never know).
«Do the simplest thing that will work»: Why complicate things. This could mean using techniques that you already know; using a library;
Use a «revision control system»: This allows you to exhibit «courage», as you will not loose all of your hard work.
Accept «feedback», try things, make mistakes, learn from them.
In writing this, I have just selected agile/lean practices will enhance my teaching and students learning. The others can wait for another day. Tell the pupils that you are doing this: tell them that you have selected a sub-set of practices, and why.
It has been a long time since this question was asked, but in the meantime, we have begun to incorporate something rather kanban-ish into our senior year capstone course at my school.
We did a large-scale curriculum review with industry engineers, students, teachers, guidance counselors, and college professors, and we decided to integrate agile into our senior year capstone projects.
Many of the answers here seem to reflect upon whether you should do this at all, but since we are actually doing it, I thought it might be worthwhile to explain what we have done and why.
What we are doing
Our projects are roughly five months long, and typically involve working with an outside client. We are using trello boards with roughly the following setup (student initials have been blacked out):
Sprint meetings with our student groups are roughly once every two weeks. Students place there goals for the next week in "To Do" and create a card color for the week. By the end of the sprint, the goal is to have all of those cards in "Testing" (or in "Blocked") and to have a new batch of cards (in a new color) in "To Do".
At that point, we have a weekly meeting to talk over their progress, look at the project and the code, check in on their communications with the client, negotiate the next set of goals (or the next date), and award grades for the sprint.
The process helps keep things moving in the classroom during such a large-scale project, and familiarizes the students with some industrial practice. It was nevertheless important to us that the process itself remain simple and low-overhead enough as to not step in the way of the work itself.
We are not far into the projects yet, but so far, things appear to be going well, and students have expressed that the process has remained helpful. If the students begin to report that it is not helping, then we will revisit the requirements and make modifications as needed. At the end of the day, we are transplanting an industrial process into the classroom. The translation does not have to be exact to be in the spirit of the original, and if it must be modified in order to function in this environment, then that must be okay.
Ultimately, it must be of use within the projects that the students have in front of them, or it will feel like a chore instead of a helpful organizing process. That is (and must be!) the final arbiter of how to organize an agile process in the classroom.