views:

694

answers:

8

I am currently a grad student, but I was in the industry for a few years before going back to school.

I am in a class which involves teams of 4 working on fairly ambitious projects. As a result of having been in the industry, I have a lot of "software engineering" experience my fellow teammates lack (they are using SVN for the first time this semester). They are all very good programmers; but they don't have a lot of experience in building "real stuff".

Since I had a fairly concrete vision for a project, and my teammates did not, my idea is the one we will spend this semester working on. On top of that, as a result of my experience, plus the fact that I admittedly have a somewhat strong personality, I've become a de-facto team lead -- established weekly meeting times, assigned initial tasks, etc.

I want to avoid the trap of being so forceful with my ideas for what we should be doing and how we should be doing it, that my teammates feel like they have no say and become uninvolved and detached.

So here is the question:

How can I keep my team of undisciplined but talented programmers motivated while enforcing basic best practices (version control, milestones, etc) and a coherent project vision?

Edit: Thanks to everyone who answered so far. I think I've overemphasized the "software engineering" aspect of things; I'm also looking for ideas for how to encourage my teammates to contribute to the design, and feel ownership in the project which is at the moment a little bit "The SquareCog (and friends) Show!"

A: 

offer non-monatary prizes or awards

Give them their own areas to "own." Even though they may not take pride in the project, they will want to make their own areas excel. Make they question, can their area be refactor or improved. It will make them learn new techniques or practices.

Allow them to learn by fire (in small phases) and then show them the correct way. Let them fail doing it their way, but allow time for them to do it the proper way.

Update:
Sorry to make the above sound like the team-leader would be the one in control of what is correct. It is mean to be more of a code-review that can be done by any one on the teams. They can move forward with the changes/refactor together as a team.

Glennular
Non-monetary prizes and awards are a good idea, but they really need to go hand in hand with a mechanism for lowering the barrier to entry for whatever practices you want your team to follow. This can be managing things yourself (more) or simply getting them over mental hurdles.
Cody Brocious
He's their peer, not their tutor. He wants to be a team player, but encourage them to use good practice - not teach them per se.
CJM
CJM, If the (ad-hoc or otherwise) leader of a project isn't teaching the other people in the project, he's not doing his job properly, IMO. They go hand in hand.
Cody Brocious
That's an arrogant stance. They are his peers, not his pupils or subordinates. They have more to gain from exercising their own skills rather than simply follow him. They need an opporunity to express themselves, not just coy and unappointed leader.
CJM
+6  A: 

The best method I've found has nothing to do with code: team lunches.

Get together in an informal setting where you each talk about your problems, concerns, ideas, etc. This helps team unity in a way that very little else does.

As for the actual code side of it, minimize the amount of work they have to do to work inside the framework you want them to. If you want them to use tickets, do the actual management side of things for them -- have them tell you what the ticket is and have you do the actual legwork of managing these things. This seems like it'd take a long time, but overall it's minimal compared to the cost of poor communication and coordination. It pays off very quickly.

For version control, show them why it truly benefits them. Programmers pick up on ideas and run with them when they see they actually help them rather than just being a PITA.

Cody Brocious
Team lunches with BEER.
Kevin
Cody, those are both good ideas. Kevin -- hah. I wish I could upvote a comment!
SquareCog
Tickets, Version Control....I think we may be over engineering a school project. If the whole course is the project then maybe, but for a normal course which is mostly exams/homework and the project is 15-25% that stuff may be more of a time waste than a help as may group lunches be. You are killing 1 hour per week/day that they could be working.
Cervo
A: 
  • The project should be interesting enough to keep them involve
  • the technology should be also recent
  • let them know this is how the industry moves and that they will gain the necessary experience to be in top of other programmers
  • offer prizes and punish those who break the build
  • rotate the positions let them test their ability to lead
Oscar Cabrero
As their peer, he can't necesarily dictate the technology or the project content, nor can he necessarily dictate roles or 'punish those who break the build'.
CJM
+1  A: 

I've been in a similar position a number of times.

Sometimes I just take charge, and be damned. Fair enough.

And many times, I resist the urge; I try to encourage my colleagues to take the lead. Sometimes this works, sometimes not.

And sometimes, I just come clean. "I seem to be taking over, as is my nature. But I don't want to railroad you guys. Anyone else fancy taking the lead? If not, are you happy with what I have already suggested? Speak up if you have any good ideas...". Again, sometimes this works, but not always.

Ultimately, you can 'lead the horse to water'... Projects need the lead, if no-one else rises to the challenge, it is better that you do.

Once you have the lead, lead by example...

CJM
Although I agree entirely with your answer, I don't think this addresses the question. The question was more along the line of how to herd programmers than how to take the lead of a project.
Cody Brocious
I disagree - he has become the team lead by default. He is happy to lead, but doesn't want to leave them behind. I'm suggesting he lead, but by consensus... Offer, rather than force.
CJM
+1  A: 

How about the Scrum (even if you don't call it that). Gives everyone a chance to have their say, and you listen. As the forceful personality giving the others a real chance to communicate what's on their mind (not yours) is a good step towards harmony.

On top of that they will learn from your tech experience, you will learn from their ideas and enthusiasm. A good leader is always open to communication, you set the direction and vision (and you did choose the project) they come up with the clever ways of doing it.

MrTelly
+3  A: 

I think developers are really practical people.

Play with those traits of typical developer personality: 1. Creativity 2. Curiosity 3. Practicality

Following your direct example, source control:

Most of us (I mean by my own experience) will fail to see the point in source control in the beginning (just because), so always keep them aware of the reason behind using source control.

Another thing is.. who decided to go on SVN? There are alternatives, I for one would fight to the teeth not to have SVN because I am a Git! (pun intended)

Instead of pulling them by the nose, you should/could have explained to them:

We need source control, find one you like and lets vote it out what we use to control the source.. this way there is a common ownership..and not just a follow the leader exercise.

Another thing is, be flexible in what you implement.

Draw out a plan on necessities, but try to be ready to implement them as the need arises, or as it becomes obvious to all that x, y or z practice should be implemented.

Have them need to implement the tools and resources and planning techniques you know by having them come to you for advice. (this doesn't mean you can't lay out a best practices blog internally or some other way of giving them access to this information beforehand)

Developers like to learn and grow, but we need ownership and understanding in the direction we are going.

If you try to force feed and drive them too much, both you and them will just lose motivation, enlightenment requires self driven forces.

Ric Tokyo
good ideas, upvoted! As far as SVN -- that was just an example. They are using SVN for a different class, as well, so only having them learn one source control system seems like a path of least resistance (plus it's the one I know best...)
SquareCog
Yea, I think any source versioning/control is better than none.For those who don't know what I meant by saying I am a Git, it means I like to use this:http://git-scm.com/ I used to be very much into SVN before stumbling into that..
Ric Tokyo
Meanwhile holy wars over version control are again time spent not working on the project. I would let each person work however they want.
Cervo
Ric Tokyo
A: 

I am doing my masters degree currently and have had frequent group projects. It is not unusual to have only 1 or 2 members of the group doing the project. Not just from my projects but talking with other people. Basically what you said about the "SquareCog" and friends show is not unrealistic.

Really the more people you have on the group the lazier people will be. Also the more time lost communicating with them as they invent tons of ideas that they have no intention of following through with. It is well known that there is a point where extra programmers do not help the project anymore. There is only so much you can break something up. Over doing it will slow things down more than just giving a part to one person and create more dependencies.

Also the average student has a comfort zone, so even if you can get them to do some work, the will stay within their comfort zone. Someone has to leave their comfort zone for most projects (unless someone already knows the information in the class) to succeed. Most of the time I find that I am the only one willing to do that in my group, and some groups have no one. The most radical example was a 7 person project where almost no one did anything. One other guy was willing to do some light sys admin tasks and then the web design, that were within his comfort zone. One girl did some database design (and I do mean some because I basically did the design as a high level outline that she formalized with column names/data types). The rest did absolutely nothing. The class was distributed systems, so someone needed to learn JBoss (and Enterprise Java Beans), Amazon Web Services, etc... But it doesn't matter the class. In a data mining class, someone will have to figure out which techniques to use and how to use the toolkit.

Also many students are not good programmers. In fact there was someone in one of my groups who couldn't program at all. Really based on his description an MBA sounded like the right degree for him, but anyway he went through with the Masters in CS by farming out his programming to friends/contractors... Many are just terrible programmers and not just in style, they couldn't debug hello world with visual studio.... Rather than understand what went wrong they will just keep adding code until it works by coincidence.

One thing that happens quite often is that people come up with fairly ambitious projects that are not realistic for a semester. Usually I end up taking he scissors and cutting it to a barebones project and offer that once we finish the barebones part, then we can refine it and add the more advanced stuff. What almost always ends up happening is that people drag out finishing it and in the end after we get the barebones done no one wants to do anything additional.

There are 2 types of grad students. Full time grad students who take 4-5 classes, in which case they cannot afford to spend 40/80 or even 20 hour work weeks working on the project. Or part time grad students who have a day job, in which case they take 1 or 2 classes and have a full time job so they have even less time. I would say as a general estimate you can figure 6 hours of homework per graduate class (most will spend less). Assuming a normal class, probably 3-4 or that needs to be spent on studying/reading for the class. This leaves 2-3 hours per week per person to work on the project. Even getting that much would be good.

Some of the ideas floated like team lunches are not realistic at all. Many grad classes have group projects, and the full timers can't do 4 or 5 team lunches per week, that is like 5 hours of wasted time per week that could be spent on a rpoject. Also there may be money issues if you go to restaurants and expect all to buy lunch. And for someone who goes part time like me, I'm not going to do a team lunch because I work 9-6+ or 8-5 on college nights.

Probably your best bet is to find people's comfort zones and figure out tasks you can assign to them. Also to identify the freeloaders and not waste your time with them.

Also using version control for a school project seems like overkill. If the whole class is just the project maybe not. But assuming it is a normal class with lectures, exams, and homework assignments with the project done on the side, then any time spent on infrastructure is time you are not getting the project done. Really, though unrealistic for a professional environment, school projects are like start ups. Get them done, even if the code is a mess. You can always clean up later. But if you don't get it done, your grade will suffer. And in reality once it is done, I don't want to clean it up and no one else does either.... Getting everyone to use source control (unless you share a machine) would waste a lot of time with set up issues, and adjusting people to using it. i don't know what your project is. But with many graduate projects you have to do some research/experimentation and then the programming code is relatively simple. One class got me with a 5,000 line project, lucky it wasn't a group project.

Again on the project keep it simple. You can just coordinate the parts, assign the different parts and as they are done check/test it and then integrate it with your version control and leave them free to work on the project whatever is most comfortable.

Many will be happy to let you design the thing, implement the thing, and then learn absolutely nothing and just get the grade. It is their loss because they won't get the lessons of the project. But they are quite happy with squarecog and friends being just squarecog. Some will want to contribute something, but they are in the minority. If you get one of them great for you!!! Also watch out for over engineering. You have to look at things realistically. 3 hours per week per group member would be great, but I find even that is unrealistic. When a project is due sometimes you might get 5 or 10 hours per week from someone who slacked off. But you can't expect more.

Cervo
A: 

How to Win Friends and Influence People has the following suggestions:

Fundamental Techniques in Handling People

  1. Don't criticize, condemn, or complain.
  2. Give honest and sincere appreciation.
  3. Arouse in the other person an eager want.

Six Ways to Make People Like You

  1. Become genuinely interested in other people.
  2. Smile.
  3. Remember that a man's Name is to him the sweetest and most important sound in any language.
  4. Be a good listener. Encourage others to talk about themselves.
  5. Talk in the terms of the other man's interest.
  6. Make the other person feel important and do it sincerely.

Twelve Ways to Win People to Your Way of Thinking

  1. Avoid arguments.
  2. Show respect for the other person's opinions. Never tell someone they are wrong.
  3. If you're wrong, admit it quickly and emphatically.
  4. Begin in a friendly way.
  5. Start with questions the other person will answer yes to.
  6. Let the other person do the talking.
  7. Let the other person feel the idea is his/hers.
  8. Try honestly to see things from the other person's point of view.
  9. Sympathize with the other person.
  10. Appeal to noble motives.
  11. Dramatize your ideas.
  12. Throw down a challenge & don't talk negative when the person is absent, talk about only positive.

Be a Leader: How to Change People Without Giving Offense or Arousing Resentment

  1. Begin with praise and honest appreciation.
  2. Call attention to other people's mistakes indirectly.
  3. Talk about your own mistakes first.
  4. Ask questions instead of directly giving orders.
  5. Let the other person save face.
  6. Praise every improvement.
  7. Give them a fine reputation to live up to.
  8. Encourage them by making their faults seem easy to correct.
  9. Make the other person happy about doing what you suggest.

In addition to this, "Top Three Motivators For Developers (Hint: not money!)" notes the Autonomy, Mastery, and Purpose ideas that can also be great motivators for people when it comes to creative work.

JB King