Shifting Gears: Making a strong transition to CS486

Overview:

Students in the CS Capstone sequence often have the impression that CS486 is "just more of the same" as CS476 was. While this is true in the sense that you are still working on the same project and the same team, CS486 really is a different dynamic, notching up the level of intra-team organization, independence, and productive collaboration required. The tips listed below emphasize some of these differences and highlight areas that have historically been somewhat problematic for Capstone Teams. Make sure this is not you!

How to succeed in CS486c, Capstone Design:

Be ready to invest more time

• CS476 was a two-credit course, of which we generally spent one credit in the class room, and the other assigned --- along with the rest of the "out of class" hours (2-3 per credit hour, as per ABOR guidelines) -- for working on the project as a team. By contrast, CS486c is (very purposefully) a 4-credit course, and there are essentially no in-class hours. This means that each person on the team should be planning and spending (4 + (2-3 * 4)) = 12-16 hours/week moving the project forward. And that's for each and every team member. This time will need to cover meetings, technology research and, of course, code implementation --- so good time planning is required. But mostly it's important to recognize that you'll simply need to put in the time to make your project succeed. This is very much like real life in the consulting biz...

Invest in team-building

• A major goal in CS476 was to give teams a "light-duty" chance to get to know each other as a team, sort out any speedbumps, and generally find an efficient way to work together. That foundation will be put to the test now, as expectations go up and deliverables are due. If your team has not really "come together" very well in CS476 (but was able to limp on through anyway), then right now at the start of CS486 is the last good moment to address it. If you have team dynamics issues that you are having trouble solving, you should not hesitate to ask for help: go to your team mentor or the course organizer --- either individually or as a team...or perhaps first one then the other --- and discuss the situation. A major learning objective for this course is learning effective team collaboration. Don't be embarrassed if it didn't "click" right away. This is a skill to be learned like any other.

Be proactive about slacking and other negative teaming behaviors!

• Inefficient/vague task distribution and the resulting inefficient/vague/non-existent task completion that resulted might have still be survivable in CS476. Certain more motivated people could jump in for the slackers and compensate to still arrive a good outcome. This is (a) not a sustainable model in the long run...and the real world you'll be facing soon is a very long run!; and (b) this would severely impede the product that your team could produce in the end.
• It is tempting for "active" teammates to more or less ignore the "less productive" teammates, figuring that doing a bit more work to make up for them is easier than going through the time and awkward discomfort of taking remedial action. Do not fall into this trap! There are any number of reasons why this is non-productive: it perpetuates (and even validates) the negative behavior, you yourself miss out on a super valuable experience in responsible team management and conflict resolution, and dragging a dead weight along with the team is actually much more work than resolving the situation (either by fixing it or firing the offender).
• Dealing with conflict is never fun or easy...and most undergrads tend to avoid it at all costs. But this is not realistic or productive professional behavior, and the sooner you learn how to manage non-optimal team dynamics effectively, the better you'll be prepared to succeed. Bumpy team dynamics happen continually in real professional practice...so use this chance to learn how to negiotiate these waters.

Prepare to be more independent

• In CS476, we met at least once a week as a class. This time was used for lectures, updates, and presentations...but also served as a nice "metronome" to pace yourself: you knew what things would be due, you knew that these would be discussed in the class meetings in the form of small progress updates, reminders from the professor, and so on. In short, CS476 was a stepping stone towards indepedent project planning and management. Team were nominally responsible for getting the work done...but there was still a lot of structure provided by the prof and the class meetings.
• In CS486, we move another step towards what you'd experience as a real software consultant, namely, it's totally up to you to decide how to tackle the project, plan out a timeline, and then make sure that you are making appropriate progress in all areas. Sure, we have some deliverables and design reviews that can serve as mile markers, but many fewer than in CS476. There will effectively be larger chunks of time in which it will be up to you to decided on directions and make progress. The course asks you to step up to this new professional identity...and very bad outcomes can result for teams with the attitude of "nobody is pacing us, so we'll just drift".
• The solution: the "project plan" that you have had to outline and present several times (written and oral) is not just something you have to do for presentations; it is an essential tool that you should learn to help you plan and organize your effort throughout the term. In real life, the entire project runs on the timeline established by the project plan, which is maintained by the team lead. Weekly (or more often) reviews of where you are on the plan are common, so identify and address slippage before it becomes project-threatening.

There are, of course, many other "best practices" in planning, running, and deploying software projects. The goal here has been to simply highlight a few common mistakes made by teams that create stumbles (or worse) in ramping up to the CS486 semester. For many more excellent discussions of best practices in project planning and implementation, have a look at the recommended readings listed in the syllabus.