The All-Novices in the Cooperative Game

I am about halfway through Alistair Cockburn‘s Agile Software Development: The Cooperative Game, second edition. The book provides an excellent and thorough coverage of agile methodology development, which dovetails nicely with my need to develop an effective methodology for Fall’s game programming course. I have taken copious notes and written several times in the margin, “How will this apply to CS315?”

Chapter 5.1 was added in the second edition in response to the myriad misunderstandings of the agile manifesto. In this chapter is Cockburn’s first explicit consideration of dealing with an all-novice team, which is my situation in the Fall. This paragraph is from p258, in a section addressing the misconception that agile methodologies only work with expert developers.

If I had a project consisting only of novices, I would put my money on their doing better with an agile rather than a plan-driven process. I can’t imagine novices coming up with a meaningful plan from the beginning, or delivering a successful project by sticking to that plan, or updating the plan every time they found a mistake in it. An agile process would call for them to work together, integrate frequently, test their code, show their results to their sponsors and users, and update their plans and working practices accordingly. With this approach, they would have a better chance to learn and improve within the project.

I have been using agile methods to varying degrees in my project-oriented classes, and I am certain that they engender learning and improvement. I think it’s worth teachers’ time to look at the best practices espoused by the signatories of the Agile Manifesto.

This has important implications for classes, especially project-based, studio-based, or otherwise constructivist learning experiences. Perhaps the most important is that it is the students’ right and responsibility to modify the environment after each iteration.  If students are the owners of their learning experiences, then they must be held to the same level of citizenship as a programmer on a software development team. I find that there are two impediments that challenge this, namely the professors’ and the students’ comfort with conventional objectivist designs. The sooner we can break both populations’ addictions, the sooner we can get on with learning.

Further on in the same section, Cockburn tackles the problem of the ratio of novices to experts. In dealing with an excess of novices, in situations in which getting rid of them is not an option, he recommends:

Use an agile process with the smallest number of people possible to get the job done; let the rest of the people do anything they want just so long as they don’t interfere with the progress of the development team. (Emphasis in original.)

There’s a convenient solution to a production-intensive learning experience in which firing personnel is not option. Of course, these folks should not expect “A” grades.

(I plan on writing more about how Cockburn’s observations and advice can apply to the design of project-oriented courses, but this particular paragraph inspired me to start tonight.)

Tags: agile, cockburn, cs315, project-based learning