Team Dynamics

Team dynamics has always been a sticky issue to deal with. One of my key goals of joining CS3216 was to learn how to work with talented people from different disciplines. I enjoy working with my Assignment 1 group (Chun Mun, Viet Tien and Soedarsono) a lot. There's nobody playing the clear role of the leader because we are all leaders in our own areas of expertise. We make important decisions together and leave each other to work on the fine details. Because of our pretty diverse skillsets, when someone faces difficulty in their work, another will be able to step in to help resolve the issue. It is awesome. (:

That said, I have had horrible experiences working in teams before too. In those cases, I usually ended up solo-ing a huge part of the project because the other members were not sure of the requirements, could not deliver the work in time, or were just plain irresponsible.

It was really unfortunate that Uncle Jim's team ended up with only one coder. But I believe that could have been prevented from the start. Being in CS3216, even though it isn't a pure software development class, software development is still the core of a product. How can a software startup survive without a development team?! If I were Uncle Jim (a non-developer), I would have went around trying to form/land myself in a team that consisted of at least 2 coders, as soon as possible, to prevent myself from ending up in such a situation where actions could not live up to the imagination.

How much control and authority would you have given to this fourth voice in our choice of platform (HTML5/native iOS)?

If someone were nice enough to help out in somebody else's group out of goodwill and at the expense of their own free time, I think I would have absolute trust in him/her to make the best decisions for the group. Also, given the circumstances of the team, this fourth voice seems to be the most technologically knowledgeable person around in the team and he would be the most suitable to make the decisions. I'm sure he would make the best decisions for the team (since he is also indirectly involved in the process) and make life easier and better for everybody. The fourth voice is also likely to choose a platform that he is strong in. A developer should be familiar with their tools because it can speed up the development process greatly especially when time is tight.

However, I think it's only right for everyone in the team to be well-informed regarding the matter, hence I would also do my fair share of research and consult the other gurus in class to get their opinions. Most ideas aren't new. Almost every "new" idea is a rehash or combination of existing ideas. Take a look at what and how others are building/have built similar products and learn from their experiences.

With the deadline just 2 weeks away, how would you, as project manager, have resolved this problem if it were to occur within the team?

Honestly, I'm appalled that they actually thought of testing two development tracks in parallel given the amount of manpower and time they had. Are two weeks really sufficient to reach a stage of development that can reveal the critical issues and problems with each platform?

If I were the project manager, I would definitely be cutting features of the product. Doing one thing and doing it really well, beats multiple half-baked features that don't fully work. Also, I would be keeping a lookout for tools and frameworks that the team can exploit to speed up the development process. Rapid server-side solutions such as Parse and Firebase will get the back end up and running in a matter of hours. I also wouldn't bother with styling the application because that takes up a huge load of time, will leave it looking like the default interface. Functionality > Looking pretty when there's no time.

What are some of the issues that we presented that could have happened to any team? List down 3, and talk about how you would have resolved these issues.

1. Conflicts

This happens in every team. It is only normal to disagree, it only goes to show that the members are opinionated and are concerned with the project. However, the team should not spend too long arguing it out. Internal voting can be done as soon as possible to arrive at a general consensus so that the team can progress. Also, everyone should try to convince each other and be convinced by the decision made so that there are no hard feelings and the harmony of the group can be preserved.

We are all human. Hence sometimes we let our emotions get the better of us and we vent our frustrations at our team members. As a team, we're all in this together. People bond through shared suffering and this is just another instance of the painful process. Try to tolerate with each other and trash things out as early as possible, before misunderstandings escalate into serious conflicts.

2. Unrealistic Estimations

In the book Rework by Jason Fried, Founder of 37 Signals, he mentions that most teams have unrealistic project timelines and that most peoples' estimation sucks. We tend to be overly optimistic about our own (and possibly team members') abilities and propose a very ideal timeline for the project. This does not work out most of the time due to the unforeseen circumstances. I would suggest a milestone-based approach where the team tries to attain that milestone together and helping out any member that falls behind. A team is only as fast as their slowest member.

3. Mismatch of Skillsets

Since the team members are set in stone (kinda), the team should change what can be changed: their project focus. If there is only one coder present, then the project should probably be something less technically challenging and have a heavier emphasis on the UI/UX and content.

A very good example of a CS3216 project that isn't super technically challenging to build, but manages to impress people would be Letters to Amanda. They have a clear value proposition and handles it extremely well.

Final Words

Now I appreciate why we were made to read Rework and Mythical Man-Month back in CS3217. In some cases, good project management skills can be more important than the technical aptitude of the developers.

Will be starting on my final project this weekend. Apprehensive but excited at the possibilities. (: