A Job for Teamwork: Issue Driven Project Management

Usually whenever I hear the word teamwork, I can't help but think of all the bad experiences that I have had when teamwork was a factor in completing a task. In such situations, a lack of communication between team members usually lead to hours of frustration at the progress being made(or,not being made) coupled with,as I often find out, a final submission that usually left a lot to be desired(what can I say, even I sometimes can become quite the perfectionist!).
Despite my prior experiences,collaboration with others is often a must in software engineering, especially for large-scaled systems, and even for, in this case, issue driven project management.
Joining together my skills from a previous post on WattDepot katas, and a brief introduction to the basics of continuous integration (CI) via Jenkins my team and I were were thrown face forward into the the pool of issue driven project management with a project that develop a command line interface program to understand various aspects of energy use in the Hale Aloha residence halls. Our project called,hale-aloha-cli-chair(command line hack for accessing information resources),upon invokation, enters a loop in which you can enter commands for the program to execute.
While the project itself seemed straightforward, mixing in the element of teamwork made IDPM more stressful than I could have imagined. In the beginning, it was less so since issues were successfully created and chosen to complete by each respective team member. However as time progressed, communication between all of us became strained, to the point that by the time the final submission was due communication was almost nil and there were a higher volume of last minute commits to the system. I had hoped I could have had an experience that was devoid of such stress, but when each member of the group is a busy college student juggling many things around at once, I think, how could I expect anything different?
Despite the stress mixing teamwork produced, I think we all did a good enough job with the project. Though the amount of work done by each of us could be considered slightly less that equal, each of us were successful at implementing the required functionalities of the project (all except a User Wiki guide, that is!) and extensively testing each of the functionalities with automated quality insurance tools such as PMD, checkstyle and FindBugs.
All in all, it may have not been the experience I was hoping for, but it definitely was an experience worth having. I think it has prepared me to be more productive at facilitating a more effective chain of communication and doing my best to keep that chain from being broken, in addition to keeping productive levels relatively high for the next time.