Posted by Joel Low on 4 October 2013 | 0 Comments

Tags: , ,

Working in teams adds a non-constant overhead to working in any project. Yet, for anything non-trivial, teams are necessary. As per my exposition last week, I was writing about how working as a team could be more effective if I did certain things differently. This week, we're honoured to have Jim Gan (we -- Colin included -- calls him Uncle Jim, with good reason...) share with us his experiences in CS3216 last year, as he went about his final project.

I guess this is a good start... with Mid-terms and all this week I doubt many people have started working, but we'll see. Personally, I've just finished 3 mid-terms this week, going to clear up my 4 assignments due next week, then whatever time left will be used for CS3216. This week, I need to get a dev and test environment working. Never worked on Ruby before. So I've made my milestone for this week relatively simple.

So, onto our original discussion.

I liked how Uncle Jim framed his presentation. He was not there to pin blame, he was not there to say that this or that way of doing was superior over the other. He was there, presenting the facts (and opinions -- to get into the psyche of those parties involved in the project) and wanting us to form our own verdicts. This is good -- management "science" doesn't have absolute answers. Well -- most sciences don't have absolute answers, either. So I guess he's less OMG (old, mean, and grumpy) than he makes himself out to be...

The thread that joined all the different experiences he related to us was one of hope. I think that idea resonated time and time again, and I think that's one thing that as a species we have learnt to rely on. What keeps us going is really the belief (or knowledge) that no matter how crappy things may seem, things can only get better. I will remember that for the times I'll need encouragement.

There's a few review questions; I think I've shared some of these in class already, but let me just expound on it further here. I'll assume throughout these reflections that I'm answering on my own behalf -- doesn't really make sense to analyse a hypothetical that cannot happen to me, right?

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

I'm pessimistic. And a control freak.

With these two traits in mind, I think it's only logical that not to give any control and authority to this fourth voice. I will ask him for advice. I will analyse his choice of platforms. I will scrutinise his decision making processes. Hopefully, if I come up with the exact same conclusions he has, then fine. But if I don't, sorry, I know you mean well, but it does not stand up to logic. You can be helping me out in my project, but when push comes to shove, you will abandon my project for your own.

I cannot let a person who will abandon my project have any say in the running of the project. Not negotiable.

I won't tell the guy off in those exact words, definitely needing to sweeten the language, but that's my thinking.

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

I've shared in class what happened to my team. Like I said earlier, I don't want to assume a hypothetical that cannot happen to me.

The first thing, as someone else in the crowd suggested, was to cut back on features. Take your list of things you intended to do, find the minimum set that satisfies what your job is, and then run with that. That works all the time, unless you planned just for the minimum set in the first place (then really you didn't plan enough.) You can't expect to deliver all 9000 features you wanted, but so be it. Circumstances are circumstances. Make the most out of it.

The other thing which did happen to me, was to tank. Team members not doing what they should have done? Products need delivering? Bite the bullet, take all the crap that the world is throwing at you, and make your own miracle. It's happened once. I don't think it's not going to happen again. It's never fun when it does, but should it happen, being technically competent means you have the choice of doing something.

Whether one should do it is another matter altogether. In school, we don't only have CS3216, we've got other modules too. So it's your choice.

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. Not having enough people. This led to Uncle Jim's team needing external help. I think this is classic: I seem to always find myself working in teams with insufficient people. I don't think I can give any better solution to "do your best." We build competency by going to hell and back -- I don't think there's any way you can short-circuit that evaluation. You can however make the trip less painful by being mentally prepared. If you go in with the attitude that you are going to take lots of punishment, when the punishment comes, you find it's less punishing than you expected it to be, and you're more resilient than you usually are.
  2. Agreeing on a destination, but not the route. This was a constant source of conflict for much of his project. The team, though small, could not agree on the way forward because they all saw things differently. This is slightly easier to solve: surrender your decision to your team leader. Make sure you pick the correct person, however, and make sure everyone is willing to adhere to his decisions (otherwise the existence of such a person is moot)
  3. Indecision. Strangely, the team was small and still could not come up with a decision -- something as simple as deciding between whether to use HTML5 or to go native. It could be due to the lack of technical expertise, but I think if after 2 weeks or a month the decision isn't clear, something is wrong. Maybe the approach taken by the team is wrong. I don't think much was expounded on that, so I can only hypothesise.

Wow. That's a long post. I really need to get onto my other modules.