We capped enrollment at 240, but we may end up with less than 40 customers (we target 6-person teams).
So, suppose two teams work simultaneously on different designs/implementations of the same customer-facing app. What pedagogical benefits might we derive from that? That’s where I want your opinion.
The project includes 4 two-week iterations, each including both a customer meeting and a meeting with a TA. Before iteration 1, the teams have initial meetings with the customer to understand the business need and do some lo-fi UI mockups and user stories for the first few features.
Let’s call two teams working on the same customer app the Blue and Gold teams for that app, so I can describe our proposals:
Option 1: Team rotations.
- Iteration 1: Each pair of teams of six works on initial set of stories agreed upon during initial customer meetings.
- Iteration 2: Two people from the Blue team will change places with two from Gold team. The remaining 4 Blues will have the job of bringing the two Golds up to speed (via pairing, reviewing design documents, etc) so that the Golds can contribute, and vice versa. After the two-week "visit", the Blue visitors will report on how easy it was to come up to speed (both how helpful the Gold "hosts" were and how clean the code was, allowing them to understand the code rapidly), and the Golds will report on how good of team players the Blues were; and vice versa.
- Iterations 3, 4: two other people change places, so that after 4 iterations, everyone will have been a visitor for 1 iteration but every team will always have 2/3 of its "permanent" members working.
- (Variation: iterations 1 and 4 are the complete team; iterations 2 and 3 have three team members swapping places, thereby forcing a change in pair-programming behaviors as well.)
- direct experience coming up to speed on and adding value to "legacy" code, which would allow us to eliminate the separate legacy code homework (in which people add features to the open-source blog engine Typo; it’s a decent assignment but certainly not as realistic as this!)
- direct experience onboarding new people
- possible motivation to make your code cleaner and better documented knowing that someone outside your team may be looking at it next week
- more time involved for customer
- possible drift between Blue and Gold which may be harder for customer to keep track of
- may interfere with "team spirit"
- may be too much of a discontinuity so that it interferes with project progress.
Option 2: Design/code reviews.
One or more times during the 4 iterations, Blue will review Gold's design and code according to a detailed rubric. Gold's project grade will depend in part on the reviews' comments and Blue's will depend in part on Gold's assessment of the thoroughness and helpfulness of the reviews (for example, can Gold identify one or more things they'll do differently or refactor based on the review).
- no logistical issues
- makes design/code review a first-class citizen (though we would have code review be part of Option 1 above as well)
- no additional work for customer
- avoids possible project progress issues that could arise from team-swapping plan.
- less "skin in game" when reviewing code than when asked to add value to it
- forgoes experience of modifying (vs just understanding) legacy code
Option 3: your great idea here.
How else can we turn the "bug" (not enough projects) into a pedagogical feature? Comment here, or if you prefer, email me!