1. The team engagement practices that were both used by my team and useful to the project were:
Documentating our meeting and tasking members after the end of our meeting is a good practice we used to help teammates enagage and track the progress of our project. Regular meetings via discord Staying unified, we use team email account to communicate with you and clients, we take praises and responsibility as a group. I think this has helped us stay happy with our team and engaged.
Since our team was not able to meet in person, we did not really have team engagement practices. We did, however, have a lot of virtual meetings, which picked up in frequency as we got further into the semester and the project. In these meetings, the people who were present were actively working and mostly engaged. In our regular weekly meetings, where everyone was present, it was more difficult to have everyone participate and be engaged.
Regular meetings kept people engaged. Also having 24/7 acess to each other through instant messaging allowed us to all remain consious of our expatations and obligations.
I found that consistent team meetings were the best way to measure and maintain team engagement throughout the semester. Having a near constant rapport with the team motivated members to work to benefit the other group memebers they were growing friendships with. Additionally, the team meetings themselves gave everyone a chance to talk about and show what they were doing, or in contrast, show that they hadn't actually been doing much. An extension to this, demos during the meeting were much more explicit ways to measure team engagement. Someone may be able to say that they are working without having any code to back it up, but having a discrete demo showing of their work affirms their engagement.
The biggest thing that helped us was syncing everyday and making sure that each teammate's tasks were visible to the entire team. By meeting everyday, we made sure that we all made consistent progress, and using a Trello board really helped us organize our thoughts and plans.
Letting us make big decisions on our own; Advising regular team meetings; Peer evals every week (except that apparently none of mine went through because they were due before work ended, and nowhere when writing them did it mention when they were due; Weekly team meetings held in person (before Coronavirus) and zoom meetings Actively discussing and working on the project every day and communication through chat messenger Discord.
Our mandatory weekly meetings were the most beneficial way to keep the team engaged. By having a mandatory meeting at least once a week, we made sure that each member of the team knew what they were supposed to be doing at any given time. We were able to hold each member of the group accountable this way and make sure that no one fell too far behind.
Excessive documentation. Our team recorded everything that happened and it was useful to keeping the team on the same page.
We had a Slack channel as our main avenue for communication. Slack allows us to centralize and organize our messages and also tag specific people when necessary. We also had weekly and sometimes nightly meeting calls to talk about progress and work with others at the same time. It sort of replaced what would have been working side-by-side. The one downside to this method is that it was harder to get firm committments from some group members.
Consistent meeting times each week to know where we were at each week. Stand up channel in Discord for individuals to mention what was being done that day. Time logged onto the project was recorded individually with tickets on peer mentoring and notes. We could benefitted in a system to hold people accountable and for people to know what was expected of them. People on the team had to try to find ways to help.
Uh, I really don't know what to say here. We met everyday, the only thing that we used was just looking at the agenda and having frequest check-ups on our progress. We'd divvy up the task and have frequent meetings and made sure that we were ACCOUNTABLE.
the principles of agile methods. By incorporating the voice of the customer from the start and getting feedback on our project from Jess, Danny, QUEST students, and corporate partners, our team was able to make sure we were incorporating all different viewpoints to make the best final product possible. We also made sure we delivered our code in increments by building our a minimial viable product with an outline of a database system and API before building out these aspects to be the final product. Through doing so, we were able to get feedback early on and pivot in the right direction if a part of the project did not align with the expectations of our client. This made sure we did not devote a ton of time and effort to learn that we were not building something desireable. This circles back to putting people before the process. Because of my prior experience with QUEST, it was very important to me that we took an empathy-based problem solving approach not only because it is what QUEST preaches in its curriculum, but because I geniunely cared about the impact this project could have on Jess and the other QUEST stakeholders. By leading my team through this mindset, I think it allowed all of us to derive more meaning from the work we produced and to care more about the producing a quality product instead of merely a product that would get us our desired grade. Lastly, our team was able to embrace change throughout this agile process and adapt quickly as the world was turned upside down. Moving to an online environment did affect us each personally in different ways, but as a team, we were still able to push forward and get the work we needed to done in a timely fashion.
Frequent syncs: everyone being on the same page at all times is great for the team. The less time you have to catch people up, the more time you have to build. Don't ignore people when they have questions.
Camaraderie: everyone in archive liked each other, which made debates a lot less heated, and more effective. There is a mutual respect. I'm glad we were able to do this without in-person meetings. It is evident that groups how have internal resentment towards each other do not success. Disagreeing is okay, but making things personal isn't.
Meeting with the team on a recurring basis, atleast once a week outside of class. Using Discord w/ separate text and voice channels to organize communication. Using Trello to keep track of issues/in development components of the project.
For team engagement, we used the first and last 10-15 minutes of our meetings to talk about personal stuff. We talked about our hobbies, health, and other courses. This helped everyone feel like a valued member of the team, which improved everyones individual drive to work on the project. In addition, closer to final delivery we had stand up meetings daily to check individual progress on assigned work, and offer advice and help for those that were stuck. This engagement helped expedite the work that needed to be done for delivery, and also gave everyone a platform to bring something to the table
Using discord to communicate and make sure everyone is on the same page. Using google docs to collaborate on documents. Using svn to store the latest versions of the code.
Our team utilized a Discord server to create constant communication, sectioning off different channels for discussions about different sections of our project. Additionally we utilized frequent scheduled whole team meetings in order to stay on the same page of development efforts. These also often went into smaller breakout sessions with specific members about specific components.
It's hard to say what specific practices we engaged in. Personally, I think one thing that we did really well on is getting to know each other and being comfortable with each other. This is achieved by the fun and upbeat atmosphere we all brought to the table. This comfortableness encouraged us to share our thoughts and troubles openly as we get our way through the project. Every error or issue we run into, we have no issue sharing or asking for help. Matter of fact, the atmosphere we created encourages us to ask questions or ask for help and this also encouraged harnessed team engagement. This also got us comfortable to call each other out when something goes wrong or something needs to be done. The team engagement practices that were used in the projcet helped me understand and gauge what the team expected from me. The mentor site is a great example of this. Advice offered through this site has helped me address my weakness and maintain my strength.
Consistent meetings throughout the week and constant communication in our Slack group. Something that was also successful was when we had meetings, we would each take turns saying what we had been working on and what our individual goals were.
Team Voila's number one source of engagement throughout the semester was our discord server. It allowed us to always be within ping’s reach of any other member, and became the primary vehicle for our bi-weekly meetings one the end of the world struck in late March. Having regularly scheduled meetings twice a week was also crucial for our engagement, although as stated, these meetings obviously became virtual after the shutdown. The virtual nature of the project I think definitely hurt us in the long run, as some group members found it easier to skip out on meetings due to the lack of a face-to-face aspect.
Since we had dealt with engagement issues during the drafting phase, we made it a point keep engagement in our slack up. Engagement was also helped a lot from this point forward since we were building some friendships with one another on the team, so naturally we were talking more in the Slack. Having Trello boards for bug-bashing and other tasks was also useful for engagement, since we could keep track of who was assigned to what ticket. Also, since we were meeting nearly every day, it was useful to see who showed up to meetings (or if they didn't show up, who specifically said they wouldn't be there and checked to see what happened afterwards).
Frequent check-ins / meetings on discord. We met probably 3-4 time a week on average.
Weekly Team meetings. Having a place to be able to constantly engage the team and ask for help if necessary. Weekly advice helped reafirm that team members notice the effort place by others. Planning/outlining meetings = kept meetings more effective while also making tasking clear.
Our team used a multitude of practices to make sure that people were engaged and helping with the project. We started by holding weekly meetings on Monday. When we transitioned to online learning one of my teammates suggested a second meeting on Thursday or Friday. I later built onto this by suggesting a nightly meeting where people could log on (not required) and discuss the questions that we had or the blockers we were facing. Anything stopping development. It seemed that in a team project like this, people would wait until the weekly meeting to ask a question that was blocking their progress when a quick nightly call would suffice. This helped ramp up the progress we were making once we began writing code.
Having regularly scheduled meetings. Having an open slack chat where anyone can update others on their project or ask for help. frequently giving peer feedback. Having everyone state what they did each week at our meetings.
a) Having weekly meetings during which we would step through our Asana task lists and update what we're working on. b) The team feedback on the mentor site.
Weekly meetings, group coding sessions over zoom and almost daily standup during development.
0: Notekeeping. Beyond making collaborative docs for our meetings where we define that week's per-individual task lists and group decisions, creating and maintaining detailed technical documentation was crucial. We worked with a complex system (two package managers, different -- untracked -- environment files in different places, a GitLab repo shared by different teams), which responds badly to imprecise procedures. We had a document in OneNote that acted as a centralized knowledge base of how to build the codebase, detailing the process in steps, and this was updated with new information constantly. Many times, the refrain to someone reporting a problem had to be, "Follow the OneNote instructions." That's not satisfying advice, and people had to be told to do it repeatedly, but at least it was a complete, step-by-step, 99%-for-sure way to get a working build. Without it, every build problem would have been an hour of head-scratching triage and going in circles.
1: Scheduling After the lockdown, we maintained the same meeting schedule we had pre-lockdown, but the meeting was a Discord call (or a Google Hangout call when meeting with our clients) instead of in an Iribe conference room. These felt just as productive, and having a schedule forces everyone into synchronous voice communication, where most communicate much better than they can through asynchronous text.
2: Use of a good platform We use Discord for our day-to-day text communication and voice meetings. This is a widespread, familiar platform for (I think) all of us, and its featureset as an IM/conferencing client are unparalleled (being able to type monospaced blocks with syntax highlighting are unsurprisingly handy!), so it's been great for our engagement. It's not ideal though; even when you dedicate given text channels for different things, each channel is still a serial, vertical stream of information. Contrast this with Zulip (what our clients use), which is thread-based, allowing much more organization of info. That's been helpful, too, in a different way. Google Docs, naturally, has been of great aid too (to some professors' chagrin). One BAD platform was OneNote, which has a Google Docs-esque collaborative editing mode. It's to Google Docs what Zulip is to Discord in that it allows much greater organization of information, but it's VERY cumbersome -- slow to load, the collaborative editing is laggy and resulted in frequent merge conflicts, and it much more heavily skews toward non-technical documentation, meaning it marks things like "lowercase_table_names" as a grammar error, and there's no "Ignore all". If we used OneNote exclusively, as we planned from the start, I feel like our engagement would've been hurt by the attrition.
Weekly tasking meetings and Asana to keep track of task progresses was very useful. We used discord and text to send messages to each other. That may seem hectic, but I could always stay updated on what other people were doing with all these tools. The status reports were also good times to see how on track our team was compared to what we estimated.
XXX and I communicated primarily via texts and phone calls while collaborating in real time. In my effort to promote team engagement I would reach out to XXX and update him with progress that has been made on the app whenever applicable as well as asking (really telling him/delegating) tasks that he can/should work on to further our product. I really took on the leadership role in this group and wholeheartedly tried to maximize team engagement with XXX though as I have mentioned else where at times he was rather difficult to work with.
Constant communication, both in person and virtually, with the team and clients. Speaking out our opinions in order to avoid groupthink. Being honest with each other and letting everyone know if an issue arises that could adversely effeect everyone. Splitting leadership between multiple members who naturally take the role and have the know how to do so. Treating everyone with respect, and understanding their individual circumstances. Trying to maintain a steady workflow throughout the building process. Having allocated team time where we talk about anything but the project in order to better bond with each other.
The most impactful engagement tool we used was our "allotted social time". This time was really useful in developing a friendly atmosphear among team member and went a long way to develpe our engagement. Another important tool was our discord server, after the quarenteen began we were already set up with voice communication channels built into our typical communication platform which went a long way in keeping engagement up while away from campus.
We made sure to have weekly meetings to go over what we intended to get done for that week and how we were progressing based on our gantt chart we created. There became more frequent as we got closer to CDR and deadline. We also made sure to have some team time to relax and talk about day to day things.
Honestly, given the fact that classes were online, having Google Hangout Meetings were very important in keeping the team engaged. Had we been in class we could have just told the individuals that they needed to pick up the slack. But messages over Slack (no pun intended) were often times not enough. It was certainly easier for some members to distance themselves from the group when we moved online but the Hangout meetings were helpful in holding individuals more accountable.
setting expectations. regular standup. making engagement ongoing. keeping each other motivated. listened, responded and adapted as necessary.
Weekly tasking meetings: Our weekly tasking meetings ensured progress. Whether all tasks were completed or not, we always spoke to reflect on progress and changes. The entire team was very communicative, and everybody voiced their ideas, opinions, concerns, etc.
Asana: We used Asana for tasking, and it was very helpful in maintaining structure of the project. Many times, there were several things that needed done in different aspects of the team, so having a platform to see everything in one place was very useful.
Popup meetings: Many times throughout the semester, we would have popup meetings. These were quick 20-30 minute meetings just to touch base. Not everybody came, usually whoever needed help or wanted to demo something. This allowed team members to get closer with one another, and express themselves independently.
A team engagement practices that were used by my team and useful to the project was we created a Discord account. Using the Discord account, we were able to communicate quickly and event hold meeting during our time at home due to COVID-19. Another practice is we set up two meeting every week. One is on Monday at 7 pm and another on Thursday at 7 pm. We can change the time when there is a majority vote. This allow us to stay up to date on any recent change and give out task that needed to be complete before the next meeting. With a few exception, everyone show up to the meeting which keep everyone focus on the project.
Group 'bonding' sessions at the beginning of each meeting. We would discuss non-course interests and make sure everyone was doing ok with mental health and general well being. Additionally, something we should have done earlier in the project was group standups. We did quick standups during the last week of class to make sure everyone was on the same page and to give everyone a chance to discuss progress or problems they have with the project. This reduced the amount of questions members had to ask each other while developing considerably because it was known what was implemented, and what wasn't
2. If I could make ONE change to CMSC435 to make it a great class, it would be:
a) Shortening the scrimmage excercise period. If we had may be one more week for the big project, my team and I could have made more additional effort to make our product much better.
b) In addition to, that it would be great if the mentor site supports a feauture that allows tasking individuals with in a team. This will allow individuals to stay obligated to thier responsibilities with in their team.
While I wish this was in person, to allow for a better teamwork experience, the biggest challenge of CMSC435 moving online was team engagement. Because of this, it was more difficult to hold team members accountable if they do not attend the video meetings. If I could make one change, it would be something that would invite more team engagement.
I would find opportunities for more cross team interaction. I think we get stuck in our little groups a little too much, and seeing what others did more often could have benefited everyone's progress and helped keep perspectives in check.
I would say my biggest concern throughout the semester has NOT been actually building the product. With my group I've been confident throughout that we would build something really cool, and something that you too are happy with. Instead, I have been concerned about your emphasis on and the associated pass/fail nature of the final. At this point, I'm not really too scared. I know I put in a lot of work, and I've made sure to document my contributions and the status of the project throughout the semester. While I'm not looking forward to writing 20+ pages, I know that it won't be 'hard'. However, it would have been nice to know from the beginning that if a student (a) puts in the required effort and (b) clearly documents both their actions as well as the overall context of the project, then they have nothing to worry about. Despite working hard and documenting it, I was still needlessly stressed throughout the semester as I was never sure if I was doing 'enough'. And don't get me wrong, I get the importance of hanging that pass/fail final over our heads, but I think it would be better to sate the students with good intentions, while still scaring those who may not.
I already think this is a great class, as I have learned so much from this class alone. One change I would make, though, is removing pop quizzes and perhaps scheduling them instead. I think knowing that there will be a quiz on a specific day will drive students to more actively digest information in lecture.
If I had to choose one thing to change it would honestly be a page to view assigments, due dates, and which ones I have and have not submitted. I just realized that the "blog" was the place I was suppose to look for things. Honestly I would choose a new website altogether (whenever I typed into the submission boxes, an alert would popup half the time). And the link to that site should be put on an ELMS page so that students can go there when the class begins to find the page.
If the question is suppose to be related to content more, I would say that it would be nice if we took a deeper look at the actual software development process and common practices, as we did them for a project. I felt like this class was sort of just an informal discussion, accompanied by a big group project. This was a huge learning experience for everyone on my team, but honestly moreso about the technology than about the software development process. The proposal felt like the only direct guidance that relates directly to a real-world software dev scenario.
Allow more freedom in selecting projects and team members - especially allowing teams to pitch projects that may be of more interest may provide better overal engagment on projects since developers are more invested and engaged. There was certainly other projects this semester I would have prefered to work on.
I would make the action items more clear. There were a few times where I was unsure exactly what was due when and it was difficult to find the information in the blog. It would also be helpful if some of the assignments had more specific documentation. I understand that was one of the teaching points of the course but I felt like some assignments were very vague as to what the expectations were.
No legacy code projects. New systems only.
A longer timeline for testing would be nice. I think ours was shorter than expected because we had some functionalities sprung on us at the end.
My main issue was the randomization in terms of how a student got assigned to a project. I am saddened by the idea that my passion, engagement, and knowledge would have been in the right place on a different project, but I think you've heard this complaint before.
Allow teams to counter with their own project ideas by giving people an idea on what is on the horizon if we don't spend time in the beginning looking for a good project. I personally struggled with getting motivated for our complex and unrelatable use case. I also don't know how I was doing in terms of learning the engineering process since there is no way to measure it or get specific feedback until the final. I felt like I was forced to bullshit
Maybe those QOL changes. When you talked about those super-geeks who'd create a notification system for the blog, it really blew my mind. Maybe you're right and you really want to find those super geeks but hey, making the class more manageable with QOL stuff would help us focus on the project and be better prepared. (Well I understand that the alternative is the person having to manually to open the site themselfs SO MUCH WORK!)
the inclusion of one class dedicated to team bonding/ice breakers to allow us to better get to know one another outside of academia. By forming personal relationships and getting to know more than someone's strengths/weaknesses as it pertains to software development, I think there would be greater buy-in to the team mentality.
Put a female in every group if possible. Gender diversity is important in team settings. It's hard to be an alpha male when a woman is present. Alpha males listen to women more than they listen to other men. As a result, decision making would be more team oriented rather than monarchial in groups that face these circumstances. Furthermore, some males would boost engagement if a female is present for obvious reasons.
I would direct all projects to have some relevancy to current technology practices. It seemed strange to see several different web-application projects (excluding EMG) while my project was based on reviving some unused technology architecture from the 1980's.
Make the peer reviews non-anonymous. While it didn't become exceedingly toxic in my group, I can picture scenarios in which the peer reviews turn into a platform for people to degrade the effort and presence of their teammates to secure themselves a better grade. I also think that sometimes people give reviews, where they lack the context. An example being that I had reviews that critiqued my lack of speaking up. It was not necessarily that I was absent but more so was commmunicating directly with Will to get work done. Granted Software Engineering would warrant me to be more vocal and speak up, so I admit fault. Giving non-anonymous reviews allows members of the group to be more direct, and explain context behind why things may seem a certain way.
Making sure the concepts of what the projects actually are, are communicated clearly. For example if the topic was a project about something not included in the prerequisets for this course like dynamic programming make sure that everyone doing that project knows the fundamentals of dynamic programming (not saying this happened I am just using it as a hypothetical situation).
More clarity about what types of things would be expected during the final throughout the semester. I think the class could have benefited from more about what makes for a good ticket, or how to conduct various business activities frontloaded in the semester.
No coronavirus! is what I'd say But in all seriousness, I think one thing that can change to this CMSC435 class is the scrimmage. I like how I was thrown into the deep end immediately and challenged from the get-go, but the instructions were very vague. I remember my team from the scrimmage spending the first day wondering what we are doing. That was precious time wasted that could've been used for development and planning. I sort of understand the instructions are unclear on purpose to encourage asking questions but I don't think that'd be appropriate with the time constraint. So for the scrimmage, I think either making the instructions more clear (like having a more well defined end goal) or giving more time.
The fact that you allowed us to choose between projects has allowed many of the students to stay motivated throughout the project. I chose a project that would ultimately help learn a lot about full-stack development and accordingly I learned a lot during the project. There were times that I was frustrated in the project and my motivation was if I can get through this hurdle, it would help me be better at my job. and so I would like to thank you for picking a project that would benefit students throughout their careers. I know the project has opened my eyes and opened so many doors for me. The one thing I would change about this class is the way instructions are written for an assignment. Sometimes these instructions are long-winded and it would require a lot of time to just understand what is expected of us. so Making short and concise instructions would help students especially in the scrimmage.
I really enjoyed this class and I don't really have any b*tches, gripes, or complaints. I think the only thing that somewhat annoyed me in the beginning was that there was a complete lack of direction on what we should do for our project. However, I came to understand that the project and the lack of direction was extremely helpful in understanding how software development works in the real world, and creating a product completely from scratch was extremely rewarding. Although I suppose that one change could be to allow the groups to "roughly" choose what sort of project they want to work on. If a group is working on something that they're passionate about there will most likely be more engagement from all members.
I think it would be great if rather than teams having an egoless structure, the teams were more encouraged to designate actual roles. Having a leader who gets the final say on all design decisions can be a good thing and a very bad thing (depending on the leader) but it definitely is bound to simplify the decision making process and reduce costs by way of time input. I could see this system going haywire easily if, say, a group leader got burnt out and stopped engaging with the project (much like what happened in our group) but I also think that is a good learning experience nonetheless.
I feel like there could have been some kind of notifications for blog posts, but as we discussed in class the ability to make that happen on our end was there. Other than that, I don't think there are any more suggestions I could give, especially since this was a rather odd semester and you didn't get to teach it in the way that you normally would.
Maybe a section about learning how to use github. You don't need to abandon the svn, but I feel like a lot of software companies use github and some of us don't have experience with it.
I guess more statistics on personal development. One nice thing to have is like a weekly statistic where it shows how many hours you logged and your overall advice average.
One thing that might be beneficial to the students in this course is making the groups choose a specific development style (like agile development.) Then making sure that they stick to it. One of the hardest things to adjust to at my workplace over the summer was their development speed and daily stand ups with constant reports of the work that was done. It was very unfamiliar. This is the best opportunity in a class at UMD to be able to practice these skills.
I would prefer if we could pick our teams, and have more work outside of our group projects. Not saying this was the case for me, but if I was on a team that didn't work well, it would be unfortunate for my grade to be reflected mostly with the group work.
I'd like if we could have guided reflections. There were a lot of lessons packed into this semester that I'm still sifting through. I'd appreciate guidance in discovering where I can improve.
A more structured discussion of the theory so that students know what to read ahead of time and can refer to a schedule of discussed topics.
This seemed mostly true for all projects except Affordable, but I want to say: make all the projects "greenfield", bottom-up, as opposed to being about continuing prior work. There's no doubt a great pedagogical value in grappling with an existing codebase, but, on the other hand... it's so HARD! D: (Especially when it was overengineered by prior student teams who knew WAY more React than we did somehow.) Also, the fact that it meant our svn repo was superfluous and yet still maybe involved in this way or that because we needed to use our client's GitLab (which initially didn't work because the school network blocked it, meaning we had to make our *own* git repo) was cumbersome.
Maybe more smaller projects like the scrimmages with different people. Doesn't have to be coding, could be just some excercise.
Personally I would suggest that when opting to split a group apart you reach out to all parties involved to figure out what is going on. I am very proud of and happy with Scrapbook n' Look but it I feel that for a class built on collaboration and communication this decision was very uncharacteristic. I would be lying if I said otherwise, but I feel that this decision certainly impacted the learning goals that you set out this semester for XXX and I and every other CMSC435 student. XXX and I got something else. But again at the end of the day I do am very proud of our product and I think you will see that we put in our best effort for what we had to work with.
More personal team-professor meetings to further track, and motivate, student development. This could avoid leading students down the wrong path if in fact the professor has a better one that the students may not have thought/know of.
display what topics are going to be discussed in upcomming lectures on the course blog so that the support materials can be read before the lecture begins.
Maybe more opportunity to pick the project you will be assigned to.
Maybe a little less busy work once we have begun production. Some of the assignments were a little helpful like the status assignments, but even those were not taken very seriously by some group members and thus were not necessarily accurate reflections of our status. This means that these assignments ended up causing more stress than they should have as it was a struggle to get individuals to report fill out their work prior to the deadline.
All projects would be same level of difficult and require an even amount of work to be put in.
Check-ups: I liked the CDR. It was a powerful tool in constructively analyzing our product, and the design decisions we made. However, this being the only reflective tool from the professor, it would be nice to have smaller check-ups before and after the CDR. This is similar to private professor meetings, where teams could schedule a meeting and voice their ideas/concerns. But I think a more structured check-up would be helpful. It could allow teams to NOT fall into the rabbit whole, and get the spiritual guidance they need before making a tragic design decision that could really set them back. But this could also be used as a teaching mechanism to make mistakes and learn from them.
I would offer some support for the scrimmage. I was really confuse on what to do for the scrimmage because I never set up a server before and was constant looking for how to do it. I feel liek it would have been much more helpful to give a direction than to just say set up a server. Other than that, I do not see what else should be change.
Make peer reviews a little less anonymous. I would add a numbering system so that I can tell which reviews from each week are from the same person, but still wouldn't know the name of the individual. E.g., I could see all the reviews from person 3 were super flattery each week while persons 4 and 5 provided solid constructive criticisms that I can pay attention to. This would also help in the case of possibly toxic reviews to know whos criticisms I should be wary of in case someone is just putting others down without providing insight (this didn't really happen, don't worry!). Additionally, I would spend more time on how to write constructive peer reviews earlier in the semester.
3. The one thing that most gets in the way of me doing my best work in CS here at UM is:
Being a computer engineering major is something that I found it to interefere with my CS performance at UMD. As a CE major, I have the responsibility to find a balance between my electrical engineering classes and computer science classes. CS and CE majors take the same major CS classes atleast until CMSC 351, in addition CE majors take atleast 2 EE courses concurrently. Which means I had less time to work on projects for CMSC 131, CMSC 132, CMSC 216, CMSC 330, than most CS students. I understand I am responsible for spreading out my classes to avoid stress, but I really need to graduate soon. I finally end up in software engineering industry, which I could have achieved by just being a pure CS major. I am pretty sure I could jhave done a lot better if I was just a pure CS major.
Having to choose some subset of the many 4XX classes offered. While this is good for allowing me to choose specific topics and learn those in dept, it feels limited by the amount of space we have in our schedules, usually taking only about 7 4XX classes. I'm not sure how, but I wish we were able to cover more upper level topics, without sacrificing the depth of studying it.
The lack of structure in the whole program. Nothing leads to anything else. This felt like a capstone class, but I couldn't rely on my teamates having any skills or knowledge in particular beyond 216/330. There should really be more strict dependancies between classes, so I don't have to learn the same multi-threaded algorithms in 412 and 433. Also having units about P/NP and complexity theory in 351, 451, and 452 that all covered fundamentally the same ground feels like a massive waste of time. My final comment is that there really should be more of a focus on code re-use at the upper level. Yes some algorithms do really need to be implemented by hand to understand them, but not everything needs to be done this way. A solid handful of projects were trivialized by allowing access to existing libraries. Even beyond this, selecting the apropriate tool for a job is not something that we should have to realize, given how few of us do before being given the approval to go into industry.
The slog of general education classes I need to take, or the aimless credits I am forced to sign up for that get me up to full time student status. It is silly to require 12 credits yet only allow students to take at most 3 cs courses. All the time spent on ancillary credits takes away my focus from the classes I care about in the cs department. I also think that the whole system is fairly inefficient at transmitting information, but thats more of a philosphical issue. Especially with the online resouces computer science as a field has to offer, I could probably learn 3x as quickly in my own time in contrast to information based cs classes like 131 up to 330 and some of the 400's like databases/architecture, etc. What I liked about this class is that you can't just read a book to learn the content, the class was specifically about the long form project which works well in the semester timeframe.
Senioritis really got me at the beginning of the semester. I definitely wasn't engaged at the beginning, knowing that I don't need any of the classes I'm taking to graduate. What really got me locked in, though, is the cameraderie among the team. We all shared one common goal, and we did everything necessary to make sure we met that goal -- from long hours spent coding late into the night to making sure that we all had the necessities to efficiently contribute.
The inaccessibility of information, and usability of the website (specific to 435). Ex: If your internet isn't extremely fast and steady then alerts popup whenever you type into input fields. Ex2: assignments and due dates were extremely unapparent; I honestly do not believe I should have to fish through the blog to find assignments and due dates.
As far as the department as a whole, it honestly feels like not one person care about a single student. I have yet to find a professor that I feel wants to form a good relationship with his or her students in the CS department. Jim Purtilo was the first to express an interest, but by the time you take his class you have been conditioned not to care.
There are very few classes that put you in a situation where you REALLY develop software, usually you are putting in the last piece of a puzzle. I do not think this develops decision making or leadership skills.
Unrealistic expecations (explained more in next question)
Sometimes I feel like the quality of instruction is not up to par. Often a professor will read off their slides about a certain topic then assign work that is semi-related and have the students fend for themselves. There have been countless times where a concept from lecture felt extremely complicated, but when I searched online or spoke to a TA, it was just the way it had been explained in lecture that confused me. There is a very common feeling among undergraduate students that the professors don't care about their education.
Myself. I've struggled with motivation and anxiety issues for a long time. It made staying attentive and standing up against the team at critical points very difficult.
This semester, it was the lack of resources with the COVID-19 situation. I would've liked to use the upper floors of the Iribe building to work with my group mates. In general, time is usually the problem. It's always better to have more time to fix more issues. But it's not always available and it can't be available.
Having mismatched understanding on a topic with my peers. Students aren't always at the same level of understanding on the multiple complex specialties in CS. This backend heavy project was difficult knowing that I have never touched python. I also am stronger in my experience with mobile development front end than in web development with react and typescript which I also had less experience with than other students. Minor programming languages aside, I did not understand the foundation of what the project was supposed to be although I tried to in all of the preliminary meetings and readings of old papers.
Professors. A lot of professors are really knowledgable about their field but it doesn't mean that they are the best teachers. I feel like it's better to self study at times, rely on classmates, or the TAs. I don't know if I would put you in the category since this isn't a traditional class. I view you more as a Client than a "Teacher". But those acts of "tough love"( or maybe that's just my cognitive dissonance talking) did in the end, motivate me.
other commitments. During a regular school year, I dedicate roughly half of my attention to school and the other half to work, friends, family and other personal commitments. Being that CS is only of my two majors, it only gets 25% of my dedication during any given semester. While I have worked towards perfecting my ability to compartmentantalize and dedicate certain times to certain activities, sometimes, external life events gets in the way of my work. Whether that be conflicts among loved ones, mental illness factors, or even global pandemics, there are times when inevitable changes disrupt my working routines. This semester was no different, and while I did struggle to adapt at first, by the time finals week started to approach, I hit my stride of juggling all the balls I have in the air.
Exams. I don't believe that exams do much for computer science students. Hands-on experience is better pedagogically in regard to CS. Spending endless time retaining information that I could just Google is a waste of time in my opinion. We spend all day on our computers anyways. I feel the same way about our K-12 school system as well.
Ambiguous customer requirements. My project had a lot of details for my team and I to fill in, even with the direction given by the customer.
Comfortable environments. Working from home is one of these. If I am too comfortable I cannot work properly. I get distracted, slouch, doze off, and am all around unproductive. Generally at UMD I go to the James A. Clark building to do my work because the seats are stools and are uncomfortable. This gives me a drive to work hard and finish so that I can go home, and relax. I know this method might not be healthy, however it is something that has worked for me to get stuff done. In addition, having too much technology affects me. If I have acccess to the desktop I have at home, loaded with my games, netflix, and other distractions I can't work properly. It was something I had to work extra hard to avoid impacting this class. I would often delete shortcuts on my desktop that linked to my games while working on 435 and other courses.
Everyone else knowing a bunch of languages/programming concepts that I have absolutly no knowledge of despite attending every class and having completed all the required classes as them (This happens in 95% of the projects I have across all classes no matter what I do).
This semester it was the shift to working remotely. More generically throughout the 4 years I have been here I have found that the thing that is most obstructive to me doing good work is the way that deadlines tend to align across multiple CS classes, meaning there in the amount of time available for each.
Other than procrastination, I think one thing that gets most in the way is my personality of just wanting dive in. When given a project I have no idea how to do, I just start. I code by friction and I learn on the way. I never really had the patience to sit down to solely learn a new language or framework. This is great to make me feel productive but this bites me in the a** later. I learned this during this class the hard way. Like when I was assigned to do Stripe payouts, it took me much longer than I thought because I didn't take the time to fully explore how to do payouts. I didn't take the time to read through everything to understand it is a lot more complex process than I thought. So much lost time in helping on other stuff or help making the product better overall. This is something I need to improve on myself.
Balancing course loads is the one thing that gets in the way of giving my best work. This is something I have been struggling with for 4 years now.
Throughout my 3 years in the program I feel that it's the lack of downtime. Whenever a project is due the next one is immediately assigned. This can be pretty stressful when you're taking more than one CS class in a semester and there is constantly two or three projects due right on top of each other.
The one thing that most gets in the way of my best work is unfortunately myself, via procrastination. Although, I am happy to say (and I’m sure you, the instructor, will be happy to hear) that a course designed around prolonged effort rather than hackathons goes a long way to alleviate this problem. This is perhaps the least-procrastinated-upon project I’ve worked on in my entire UM career, with Team Voila putting forth a solid, maintained effort from week one.
Probably my own reluctance to study, but other than that I noticed some lack of resources this semester in a CS class (CMSC411) that I could have learned a lot of interesting material in, but it was an all-online class with NO lectures. All the material was taught via poorly written notes and miscellaneous resources such as youtube vides from around the internet that we accessed through ELMS. Furthermore, the exams were insanely long and difficult for a class that doesn't bother to even hold lecture. If I'm going into massive amounts of debt for a CS degree, I at least want to have the professor of a 400 level class put in the effort to teach me the material, especially at a school that's ranked top 10 in the country for CS.
I'd say being scared to start a big project. It can be overwhelming, but once you get into a groove it goes well (most of the time). I like to break things down into smaller tasks and tackle those.
There were some classes where there was a lack of guidelines on projects, hws, or overall class. This made it quite hard excell as it ended up being a guessing game. Additionally a conflict of dates on major projects.
The thing that gets in the way of me doing my best work is having all of our projects be so strictly based on a template of code that the professor provides. The objective of the project is to do something very specific to teach a specific concept. I understand that is for ease of grading and to teach concepts, but students are never really given the opportunity to create an application from scratch start to finish.
Underestimating my workload! When I receive assignments, sometimes I underestimate how much effort it will require, which leads to me procrastinating completing the assignment and feeling more pressure as the due date arrives and I realize how much work an assignment was. Because of this, I have learned to start working on projects as soon as they're assigned, and properly plan out my work!
Primarily myself and my own lack of project management skills. Lack of community. There are so many CS students and our work is often solitary save for the classes that ask us to work together. I've realized over the 4 years that those who succeed have strong relationships with their peers, but CS curriculum is necessarily individual.
My other class commitments.
Myself.
Lack of attendance enforcements.
For myself the biggest thing for me especially regarding projects in many CS classes is my lack of passion for that project. This is not a lack of passion for computer science or coding, I love computer science and I love what we do. But what I mean is the "fill in the blanks" projects -- projects that are essentially fully built but require us to build one or two specific components. For me it is hard to find passion in doing these projects and really I think these projects limit our learning outcomes significantly because in this way we do not need to even care about the underlining code just make yours work. I don't think its possible to remove these types of projects entirely from the CS cirriculum however the issue is when ALL projects are like this, even most projects while in the upper level classes (from my experience).
So this class for example or CMSC420 with Meesh, where it is a semester long project that you build from the ground up I feel that this is very rewarding and easy to build a passion for. My suggestion then would be to make more CS class projects designed like this and less so in the realm of "fill in the blanks" projects -- especially for upper level classes.
The lack of motivation to learn the material because it does not match my style of learning, which was not a problem in 435 because I was getting the hands on work that leads to something substantial which is the way I learn best.
Other courses. Typically during a semester big assignments tend to stack on top of eachother, so it wasn't uncommon to have an essay/term paper, a cs project, and other assignments all due on the same day or around the same time.
Big classes.
I have had a pretty good experience with UMD CS over my four years so I don't have many complaints. I feel the quality of instruction can vary greatly from class to class so more consistency in the teaching staff would be nice. Though I understand that will is not likely to be resolved anytime soon. But that being said I have enjoyed my time in tis department and have had mostly good experiences.
Professors not giving enough information on an assignment and not being available for help/answer questions.
Teaching methods: I have not enjoyed the teaching methods of college. Long boring lectures, with redundant slides have taught me nothing compared to REAL experience. I usually learn best on my own, through research or trial-and-error. Projects are helpful in solidifying a concept, but without application it holds little meaning to me. I have built maybe 5 things in college that I am truly proud of, and not because I passed all the tests on the submit server. Passion is important to me, and college has made me lose a lot of my passion for technology because my drive was overflowed with boring lectures, and useless old information. But the upper-level classes did bring back some of my drive, and I have made some cool projects in the past few semesters, so maybe this is the point and why classes are structured in this way.
The thing that get in my way is lecture slide some of the professor provide. I alway take note but sometime the class go too fast so I would look over the slide the professor provide. But some slide provided bare;y have any information so they were not helpful at all.
Every course requires me to go to their own website, piazza, gradescope, sometimes elms, sometimes their website, sometimes the grades server, etc. I wish CS here at UM would be more consolidated. Either use ELMS as much as we can or make a portal to keep submit/grades server, personal websites, Piazza, gradescrope, etc. all in one place.
4. The obstacles that prevent me from knowing what is expected of me in this degree program are:
There is no major obstacle I can think of that prevnted me from that. I really appreciate the school and degree program. In case there is any obstalce that prevented me from knowing what is expected of me in this degree program, that I am unaware of, I dont think it is the school's/department's fault. I am the one to be blamed.
Nothing.
There are no obstacles that stop me from knowing 'what' is expected. They are laid out clearly enough here: https://undergrad.cs.umd.edu/degree-requirements-cs-major. THe bigger problems are the why and what I've laid out above.
Degree program or this class? I've known the requirements of the degree from the start and I've had no issues as the resources detailing these requirements are pretty clear, in my opinion. In the class, as discussed earlier, I would have preferred to have more information on the expectations of the final earlier in the semester. Apart from that expectations were fairly clear.
I feel like there is a disconnect between a lot of the classes offered as part of the CS program and what is expected in the industry. Of course, the courses solidly cover the fundamentals and theory, but a lot of what I have learned has come from my internships. I understand that CS is a science and is supposed to also prepare students for possibly future careers in research, but I also think more courses larger than the 1 credit STICs involving more industry-related CS should be held. CMSC435 is a great example of such a course, and I hope the school adds more such courses in the future.
I hate to keep mentioning the 435 website but I have never had issues like I have had in 435 when it comes to the inaccessability of information. I would add that the CS program here has NO feeling of community, like say, the engineering programs do.
Vauge expecations, a vague syllabus, unclear directions and instructions on assignments and projects of what final outcomes should resemble.
Unrealistic expecations set forth by professors as well - when the average grade in some classes is 50-60% I think this says less about how difficult the material is and more about the professors teaching cabilities.
Mostly a lack of communication between the professors and the students. I will admit that I am half of the problem in this situation and there have been times where I should have reached out to the professor for clarification. The professors can be guilty of this too, thanks to vague syllabi or unclear project specs.
Confusing blog page posts. Especially at the start of the class I found it difficult to parse what was needed from me. I had to read the blog posts and scrimmage information over and over again to figure out exactly what it was I needed to do.
It's not apparent how the University's expectations for a graduate differs from the industry's expectations. I think this class showed me that. I've been just learning coding concepts, but the industry expects an engineer, not a code monkey. I'm caught between trying to expand my coding knowledge, but I'm not confident that it'll be extremely useful.
The ambiguity of the project I was going to work on was a randomization in how involved I could be in technical development.
Myself. Lack of Motivation. Also the QOL stuff mentioned before. At the beginning of the semester, I was categorized as a low effort member, and as such I'm on xxxx (which I'm thankful for). The material just wasn't that intuitive. I have to grade you poorly on User-Friendliness sir. That sort of compounded into disinterest in the class and made me dislike the class. I have a stubborn simply policy "If you don't like me, I don't like you." And it did feel you were out to get me which really made me feel disillusioned with the class.
the lack of consistency between professors. While in the Smith school each professor has the same setup of where to find the syllabus (which has expectations clearly outlined), where to submit assignments, where to see grades, etc. the CS department has no such thing. It seems that each of my CS professors have their own combination of external sites and systems for releasing courses informaion and where to submit assignments and get feedback. Having to juggle several platforms takes away time and mental energy that I could be putting towards the assignments I need to complete and makes it harder to understand the expectations for each class.
Projects/coursework here at UMD do a good job at teaching things that may have been hard to grab in lecture. However, as sad as it is to say, it's easy to cheat at any university. In some cases, ill-prepared students could be a result of their own "finesse" rather than the university curriculum. I've never really cheated myself on assignments I deem as useful towards my own personal development. I try and get the most out of those. But not everyone is like me; people don't always think big-picture. Because of this I feel like UMD has prepared me for my future endeavors, but those who cheat often are not getting what's expected of them.
With the breadth of different studies within CS (Machine Learning, Security, Natrual Language Processing, etc), it is hard for me to find my niche. It would have been nice if the projects offered in 435 also reflected some of this diversity; most of the projects this semester seemed to be different flavors of web-applications wrapped up with a database.
The advising process. When receiving advising from the computer science department, I was never suggested or guided towards anything. To go even further I have even been scolded by specific advisors for not bringing a fully-fleshed out plan of what courses I want to take that will get me to graduate. How could an intro computer science student know what path they wan't to take, when you don't get into the more niche topics of development until your 3XX and 4XX classes. It was taking my 4XX courses that really showed what was expected of me in this program. I do not mean to blame the advising department, however having more resources and suggestions could have gotten the gears turning earlier, which would lead me into investigating these avenues. With this would come the expectations of me while taking those specific paths.
Lack of communication and the general assumption that the person recieveing the instructions will simply know everything they need to know. This is not meant as an insult or a complaint (whenever I am asked to be honest about this sort of thing to my instructors I fear that I will come across as if I am ranting). I have been told that computer science types are just bad at explaining new concepts to others.
An overwhelming number of unclear syllabi.
This is a hard question. When I think about what prevented me from knowing what I need to know is usually trivial things like bad documentation, bad API or just bad comments. But even for these trivial things, it didn't take me long to find alternatives or solutions. So if I am to give the most honest answer I can, I would say nothing really. There aren't really any obstacles.
My major obstacle right now is the current situation with the pandemic. It is very hard to focus and get motivated when the pandemic is taking lives and the economy going down. I fear that I jwould be laid off.
Once you get to the upper level classes it seems that everyone knows completely different stuff. Because you can just take whatever upper levels you want, there isn't a strong basis on what we should actually be learning to make us the best computer scientist/software developer/whatever we can be. So I guess just the lack of direction once you finish 330/351 on what we should be learning. Something that comes to mind is that we wanted to use SQL databases for our project and thankfully xxx had taken the database course so she was able to work on the database for us, but if xxx wasn't in our group then we would have to completely teach ourselves database usage/management from scratch.
One of the obstacles is, ironically, over-specific instructors. This trait can be a blessing or an obstacle, depending on the class - for some classes, instructors grade based a rubric often unseen to students, so if it isn’t laid out ahead of time, it often seems arbitrary and unfair. I much prefer the 435 style solution of “do the right thing.” It is much more burden on the instructor to make sure students actually solved the problem if there isn’t a single cookie cutter solution, but this style much more accurately mimics real world problem solving than a 132 project description.
Nothing, really. I found that a quick meeting with my advisor was all I needed to know that I was on a path to success and that I was doing what was expected of me.
I can't speak to the CS program because I'm a CE, but I think looking on the department website would be a good place to look if I didn't know what was expected of me in my program.
When it came to advisors, missinformation or overall no clarification on requirements made it quite frustrating when signing up for classes. Additionally they were not able to give much advise on course selection.
Knowing what is expected of me in this degree program can be difficult at times as all the professors in it seem to have a different world view and objective with what they are trying to accomplish. Within the scope of 435, it was relatively clear from the start that you wanted us to take away valuable life skills and applicable skills to the field from this class. Because of that the class was taught in a manner that is different from most other courses offered at UMD. (I think in a better way).
The lack of conversation as for what a degree in computer science can be used for after graduating college and what skillsets can be taken from our classes so that I am aware of them.
I don't go out and ask.
I cannot think of any.
If imagining someone who could let me know what's expected of me in CS more than my professors already do, I suppose it'd be my advisor. However, my advisor is not a CS person, and, when asked about non-bureaucratic CS stuff (e.g., "What do you do in this one class?"), that limited her answers.
Nothing. I think the expectations are pretty clear.
Again this goes back to question 2 a bit in that I don't think this question is fully applicable to XXX and I being a two man group. There was always something to work on and it was a very clear cut path. XXX and I discussed what we wanted to build and our client meetings helped to further narrow and specify what we were going to build. These two movers built explicit expectations for our team at every point in development.
Most professors showing they don't care by simply throwing material on a wall and disregarding students.
You recieve confusing and sometimes contradictory information from university webpages and advisors for what requirements are fulfilled by what courses and if you have a question that requires knowlege not directly relating to cs courses they are useless.
Misscommunication from professors and he department
Like I mentioned above, so instructors are not as effective as others so knowing what is expected of me in an individual class is sometimes not clear. But for the degree in general I have not had any complaints about what is expected of me.
If there are not clear guidelines on a specific assignment or project then I am unable to know what is expected of me. Additionally, when a professor does not specific what his norms and expectations are at the beginning of the semester then I am left guessing.
Class size: Classes are so large that I am just a fish in the ocean. I understand this, and am okay with not being appreciated or acknowledged as a student. But I think having a relationship with professors is important because they have advice and guidance that could prove much more useful than anything they teach in lecture.
Lack of advising: There has been little recommendation from CS advising. They just tell me what I need to graduate, but not what I need to learn. I think advisors pushing students toward classes that align with their interests and passions would make the educational experience much more enjoyable.
An obstacle is that there are so many thing going int the program, there are a lot of news and events, that I get lost in what is expected of me in this degree. In addition, there is a lot of students so I never really have someone clarify what is expected of me in this degree beside doing good in class and understanding the concept given.
Each class just feels like I'm being handed a skeleton program and told to implement it. Rarely do we get to implement a project from scratch which I think would greatly improve thinking skills of CS students and provide a better example of what will be expected of us as employees. Otherwise, I don't really have any examples to point to regarding what is expected of students in this program.
5. The best way to predict when students will be compatible members of a successful team is:
When they show enthusiasm towards the project and think of the long term outcome of the project. In addition to that when they ask questions or show and effort to learn about the project they are/will work on.
Engagement and complementing skill sets
I'm not entirely sure, but what you did seemed to work pretty well.
I'm not sure if I can answer this well as I don't have everyone's resume to cross check how things turned out. I would guess, however, that the quality of the resume is a good factor in measuring expertise, if not expected engagement. I do agree that using the early assignments to guage student responsiveness is probably the best indicator to engagement that you will have access to. In terms of compatibility, I have no idea. That is something that is going to vary largely from person to person, and in my opinion can't be predicted based just on resume/engagement on early assignments, so its kind of a toss-up. Your best bet is probably to build some early personal relationship with each individual, which is something you pursue with the early professor chat. Perhaps make a bigger deal/give more attention to that early chat, while still making it optional to more clearly see which individuals pursue that option. Otherwise I do think that if you group up individuals that all have expertise and have evidence of engagement, they are likely to work well together regardless of personal compatibility.
I think that the Clifton Strength's measurements are a good measure of success. I'm sure engagement is useful to some extent, but I think that in an academic setting where people's jobs aren't on the line, some students (i.e., me) may slack off when those engagement measurements are made. The strengths measurements, however, do not allow for circumstances to pollute the results.
Depends on your definition of compatible and your definition of successful. The ideal compatible, successful team would involve a leader who is extremely adept at problem solving and decision making, and a team of equally capable members with their own strengths, willing to be led but also willing to ask "why" and contribute innovation. The truth is there is absolutely no way to truly judge the compatibility of a team without meeting each member and getting a feel for his or her character. The success of a team relies on their abilities as well as compatibility, and while it is a nice sentiment to think that compatibility is the more important trait, I would say ability is more important. A job done well is a job done well, and a job done poorly, in software development especially, can be extremely detrimental. At the end of the day each member needs to do a good job for all the pieces to fit right and run lean.
Similiar interests, mannersisms, clear communication and clear expecations of each other.
The strengths of each team member must be evaluated so that each student can be sorted into a certain role. Once this is done, students should be paired with those whose strengths will compensate for what they lack. If all team members share the same skills, it would create a work environment with little diversity. If a problem were to arise that falls outside of the specific skillset that the team possesses, there would be no one to pick up the slack. Diversity is key because each group member's perspective will add a different world view that may not have been previously considered. This allows for problems to be solved for a wider range of people which may not have crossed the team's mind otherwise.
The speed and simplicity of an early prototype is a good measure of a team's success. A team that can't get at least a basic product to test with in the first 2 or 3 weeks is doomed to find problems with their approach when it's to late. (like we did)
Throw them into a COVID-19 situation and see how much they engage with their team.
If they can communicate honestly.
Passion. Or maybe a common goal. Our team was real fired up to prove you wrong. I think it was in the 2nd week after quarantine xxx found out about the effort metrics. "Jim doesn't believe in us and expects us to fail." With that, and the fact that two members got the boot, we wanted to prove you wrong. And though that was the original driving force, the passion kicked in and we started to really care about Kive and wanted to make it good.
I'd say if you can give all the team members something they're passionate about (like a common enemy), they can pivot that passion into development
based on looking for comparable aspiration levels, differing technical strengths/weaknesses, as well as similar non-academic/professional interests. Aspiration levels are a great way of predicting how engaged students will be towards any project. By having students who are going to put the same amount of effort into a mission, one can minimize the amount of frustrations of uneven work contributions. Furthermore, team members need to have different strengths and weaknesses that pertain to the project so that each member can work on aspects of the project they are most interested in while still producing the highest quality of work possible. I think it's important for team members to have similar non-academic and professional interests as well to make sure that the members can empathize with one another and form personal connections outside of the task at hand. These personal connections can create a sense of unity and motivate people to continue to put forth their best work even when the team hits a rough patch.
I think you're metric magic worked, at least for the xxx group. Being grouped with like-minded people helped our group mesh on a personal level first. Once we all liked each other, getting over our shared natural laziness became a group effort, and therefore, was easier to conquer.
Are they willing to learn new information from team members of unlike mind? Do they contribute something to team meetings? Is it inline with the goals of the overall project? A compatible team member would answer yes to these questions.
If they have things in common. A good number of people in my group played the same video games. It gave us things to talk about, be excited about, and even to participate in with each other. It is having these things in common that make development easier. Sometimes conversations happen randomly, and for random durations. Multiple times through development I was in a call with another team memeber, and while working we would have these micro conversations, only to be interrupted by actual work. If possible, you should see if you can do an exercise on day one where you put a .txt file in the personal repos of people. That have genres such as (video games, movies, tv shows, running/jogging, football, socccer) etc. Have people check off which ones they are interested in, and you can use these metrics to assign people into groups that will have a higher likelihood that they have things in common. Of course, I would advise that this process be added on to your current process as I think you did a good job picking groups as it stands already.
If everyone on the team communicates readily, has good attendance, and is willing to work hard.
The members have complimentary strenghts and are capable of working with other team members. For example, a team with people who are only good at coding won't get far, while one with people good at coding and people good at business documentation and research will accomplish much more.
Good team composition is determined by many, many factors. But I think the most important factor team cohesion and engagement. I honestly believe that a good team is one that is made up of friends. They don't need to be friends before the formation of the team, they can become friends during their time together. Team members that share similar learning goals and maybe even similar skills are good together. But of course, a team of friends is nothing if they have no engagement, though not everyone needs to have equal engagement for a successful team, just sufficient enough engagement. This way, members with the most engagement become leaders and thus, they guide the team forward in a direction but everyone else is engaged enough to ask questions and make suggestions as well. This is my opinion for a criteria for students to be compatible members of a successful team.
The best way to predict students will be compatible is through surveys. I believe that surveys will give better metrics on how to pick compatible team members.
Communication and participation in project discussions. If someone never replies on Slack or doesn't attend meetings, that is a pretty good indicator that there will be some compatibility issues later. I think that as long as the team is composed of level-headed, mature adults then there shouldn't be any interpersonal issues within the team.
Give students an early chance to review team members without the team members themselves seeing the feedback. It is often apparent right from the outset if a team member is detrimental to the team culture.
Whether they are engaged in group discussions, whether they deliver something significant, and whether they are willing to do what it takes to get up to speed and get where they need to be in order for the project to succeed.
I'd say that students who have different backgrounds but have hardworking characteristics makes a successful team. We had a variety of talents on our team and that really helped us. Additionally, we were all pretty dedicated to the project since we all need to pass this class to graduate!
Overall engagement? Im not sure, I ended up in a good team so cant really complain. Also it is kind of hard to quantify good members as some of it may be influence by shyness/not knowing other classmembers. This can make many take the backseat and wait for someone else to take charge.
It is hard to determine when people will be successful members of a team without seeing them in the team environment first. The first project that we did where we were given the option to choose groups would be a good opportunity to get feedback on members of the class. I think the best way to predict this would be to randomly assign groups for that project as well and use the feedback from it to form the groups for the semester project. The difference being that this semester we were allowed to choose our group members and friends will not give honest feedback all the time.
By looking at their experience and amount of effort they want to put into the class.
If they want to be helpful, not immediately try to lead the group without any idea of where they're going
I don't think there is a best way to do this. It is up to the members to make the most of their experience together and work towards success despite inevitable challenges.
Whether they use the same communication platforms (e.g., Discord) and how responsive they are on those platforms
Their engagement in class as well as engagement in early excercises.
From my experience it can be very hard to tell right off the bat. Someone may seem very friendly, motivated, and commited to doing hard work but then when it comes down to it you really start to see otherwise. So to answer this question, I think that much more than just a first impression is necessary to predict whether or not a group member will be compatible with the success of a team. You might develop an idea of that person from a first impression but as I was said earlier you may be surprised when it comes down to it. So from my experience in this class specifically I think it really takes time getting to know the person and seeing what they say vs what they do and really learning about their character in order to accurately make this prediction.
Understanding the students goal. If someone is taking the course in order to build a great product they should be paired with someone else who also has that drive and desire. If someone else doesn't have that same goal, find out why and try to cater to their desires in order to get them on the same level as others with similar mindsets.
How they act in the 3rd or 4th meeting. Some students will come into a group with high energy and expectations and after a few meetings begin to loose interest, maybe brows their phones.
Getting along with one another. If someone is not talkative, unable to be friendly or removed, I don't want to work with them. Everyone on my team was willing to make small talk and try and get to know everyone as a person, which was really fun
This is a tough one. There are some members of our group that I thought would be very helpful at the beginning and turned out not to be. I think it might be hard to predict with only knowing them a short time but what I think there are two main components for what makes a good teammate. Number one is communications and number two is interest in the project or devotion to the project. With these two components an individual is able to learn what is needed and will be contributing in no time.
The should be predicted at the beginning of the class by assessing the way that contribute in class, the timeline they turn in assignments, the quality of the assignments they turn in, and the ideas they contribute. By comparing these actions and qualities in students to others will give you an idea of what team thy would do well. If there are areas they are slacking then it would be best to pair it up with a student who has strengths in the area they are weak.
Experience: Obviously a variety of experience is valuable for a team. For our team, some members had hardware experience, some graphics/design experience, some leadership experience, some everything experience, etc. and when combined, created a good mix of everything to come together to make a powerful and productive team.
Personality: People need to get along for a team to be productive. I think it's important that interests align, and that team engagement is equal among members. Also being flexible prevents arguments that lead to nothing but unproductivity.
Work ethic: Team members need to be part of the "team". This means everybody should contribute. If a person doesn't have a good work ethic, then they won't be valuable on any team, no matter the project/purpose. A team is an investment, of both time and person, so if you don't care, then there's no point.
When the student often talk with their team member, come up with idea for the project, and is willing to contradict idea that they don't believe is correct or inefficient.
A combination of engagement during the scrimmage, experiences from resumes, and results from the clifton strengths thing we did at the beginning of the semester. The clifton strengths thing was interesting to hear from people around the room how they were similar and different from me and each other. By having a combination of strengths, experiences noted on resumes, and equal engagement, you would have good metrics to form well rounded teams. I would also like to note that my team was pretty well rounded in terms of experience this semester so you could also just keep doing what you're doing currently :).