kerimsatirli.com

Team dynamics and the lack thereof

posted in College on January 16th, 2008

Yesterday marked the conclusion of our most recent project, the current batch of juniors at CMD Breda have now officially concluded the bigger part of their study and can now move on to internships, minors and other awesome stuff.

Yesterday marked the conclusion of nine weeks of hard work and lots of annoyances for just about everyone even remotely involved with our group.

As always, our group consisted of students representing the four different majors our faculty offers and that is where the problems began: traditionally speaking, a faculty like ours always attracts more media designers than technologists, there are generally more interface designers than marketeers / project planners and with projects that rely heavily on the technical side of things and good branding, this, eventually leads to problems.

It is said that the first few meetings of any group are essential. Think of two dogs that meet for the first time - they will sniff each other out, try to gain as much information about the other as they can and then move on. During the next meeting, they will have some sort of idea of what to expect and based on that will either take a friendly or hostile stance towards the other.

This is the very spot where it went wrong for our group. Our first meeting ended in a situation where no one was willing to be the team leader and I can understand that; after all, leading a group of five is no easy job, let alone a group of 32 other students, but in the end, if your major includes the very classes needed to lead a team, namely project management, team building and all, you should at least be capable of taking the helming and steering the group towards a mediocre final product.

Now, do not get me wrong, I am not bitter or harbor any hard feelings, not in the least, but I feel that there is a great number of things that could have, that should have been done better.

The biggest issue I have with this project is that we worked in teams of 33 people where everyone seemed to have the same voting rights. Democracy is fine and all that, but as long as everyone can veto many things, the outcome of a project will be uncertain.

I believe that, if the project were to have internal representatives that would be allowed to vote (and represent a group of say five or six people) and that those votes were to be considered final, that we would have gotten through the planning / brainstorming stage a lot faster.

Another pet peeve of mine is that our group had little to no regard for application development protocols. I do, of course, realize that with things like this, last-minute changes are part of the whole deal and I would not mind those changes if they were only to fix a bug or two, but if those changes include building new features, days after a feature-freeze has been issued, I get annoyed.

I get even more annoyed when the building of those features results in bugs that kill other, more essential functionality of the main application due to a lack of testing (which was my fault however).

I am a technologist at heart, I suck at designing and I know that, but I try to make up for that lack by knowing just about everything there is to know about the project at hand and I dislike it when people tell me to do things differently when I know that that my solution is going to be used in the end.

One such situation occurred with the building of one of our sub-sites; back in November, I suggested that we include a member registration system, because it would not make sense for everyone to be able to upload data to the site, but I was veto’ed against. A couple of weeks later, all of a sudden, the request for a member system came in and I had to realize it, long story short: I believe that I understood the way the whole thing would have to be set-up a lot better than those that actually envisioned it.

After weeks of work, much of it being redundant, as in: building features, removing them and rebuilding them, we finally entered the home stretch and with only a couple of days to go, I was confident that we would be able to pull it off (we did!), yet, for one reason or another, it had to be a lot more difficult than it should have been:

Everyone who has ever worked with a live audio / video feed knows that a script is an absolute must, not because I have a hard time remembering things (I do), but because it is essential for everyone involved to know when something is going to happen and how long it is going to last.

It is safe to say that the team involved with the live feed begged for a script, yet we did not receive one. Due to the shuffling of the various clips, we could not make our own, yet the team lead had the audacity to complain about the clips not being played out perfectly in the dry-run.

These things simply annoy me to no end and I am happy, very happy that we are finally done with it. I have learned a lot in the past nine weeks: a bit about streaming with the Flash Media Server and the Darwin Server and a whole lot about team dynamics and how the lack thereof can make everything exponentially worse.

tagged with:,