How to build up a software development team ?

Question

Hi,

We are a group of students that would like to build up a small software development team. Within this team every one has the knowledge of programming, but the problem is that we don't have the group work experience. We don't know how to distribute the tasks. every one has the experience of working by his own; but now we want to share our knowledge all together to be able to develop bigger projects.

What is your own experience about working in a group; where you have started? and how you managed to work in a team?

Please write down you experiences or redirect me through a book. Thanks in advance for your support.

Answer 1

Ship it! A Practical Guide to Successful Software Projects might be helpful.

Also, a few other tips for beginners starting programming teams:

1. Use a source code control system. It's the right way for everyone to have the same code to work on, and to avoid accidentally deleting files or overwriting someone else's changes.
2. The way to work together is to communicate. Everyone should know what everyone else is doing, or else you'll end up getting in each other's way.
3. A programming team is a social system, and requires stable social dynamics to avoid falling apart. So, if there are two people who want to be in charge, your team will break up (just like a band where two musicians have different artistic visions and aren't willing to compromise to work together). The corollary to this is that nearly every new team will lose at least one person, because they're not as committed to the project, or not as capable, or don't get along.

Answer 2

I am currently project managing a group of second year students through a group project, and in my second year was a member of a group project.

In my opinion, you need a leader, someone to take charge and organise things like task priorities etc. It's best if you can all agree on issues like this but having someone who can steer or moderate discussions is very useful.

You absolutely must learn to be 'egoless programmers' if you're working in a team, i.e. you need to work together for the greater good (as cheesy as that sounds...). Knowledge has to be shared throughout the team and there should be a climate of collective code ownership so that everyone is happy to accept constructive criticism and individuals are happy to improve the collective codebase even if they didn't write the specific code.

I second the idea of SCRUMs. In case you've not heard of that, what it is essentially is having a daily 15 minute meeting (this can be less than daily depending on how much time you are willing to dedicate to this project) where each member of the team tells the others what they did the day before, what they plan to do today and any problems they had completing their tasks. By highlighting any problems/obstacles it should allow the project manager/or the rest of the team collectively to help the individual overcome the problem.

I would recommend looking at tools such as Pivotal Tracker and Basecamp (both free) to easy the burden of project management slightly.

Also, in case you don't already, you absolutely must use some kind of version control software (I'd recommend Git or Subversion) so that you can easily share and work on the code together.

Also I would consider pair programming (where two of you literally sit at the same machine coding away on tasks) or at least code in a common, communal area so you can bounce ideas and issues off each other.

It's easier if everyone codes against a set of agreed up-on-standards as well. It's not really important where you put your brackets or how you do you're tabbing but it's more important that everyone agrees and does the same thing.

A final thing to consider is what you are wanting to develop, that may require a whole extra thought about marketing/ideas generation/business issues etc. I'd go for a web application but that may not be of interest to you.

If you are going for your own products, be prepared to throw away many ideas or to change them. Iterate through the design and release early so you can get feedback from real users. A common quote is "if you're not embarrassed by version one you waited too long".

Peopleware is a good project management book about the social side of management and eXtreme Programming Explained is good if you're interested/believe/agree with the agile/XP ideology (which not everyone does).

Good luck!

Answer 3

You may quickly run into some non-technical challenges. Back when I was a student, I was unprepared for these things, so I'll show you some of my scars in the hopes you can avoid them.

The first issue, and the toughest, is that somebody must be "in charge". You're all students, so I expect that you're all essentially peers, and probably friends. This could lead you into a pitfall where you try to run everything democratically or meritocratically.

That works for the technology side of things, but will hamper your ability to execute on the business side of things.

I've been in several partnerships. In the successful ones, there was a decider.

It's not a power trip, but it is about speed of feedback and execution. You see, the most important thing a startup needs to do is learn and learn rapidly. There are a few proven techniques for learning and adapting. Most of them come back to having a clearly understood person who has the last word.

A few books I'd recommend:

• "The Fifth Discpline", by Peter Senge.
• "Execution", by Larry Bossidy and Ram Charan.
• "Confronting Reality", also by Larry Bossidy and Ram Charan
• "Chasing the Rabbit", by Steven Spear
• "The Principles of Product Development Flow", by Donald Reinertsen
• "What to Do When You Become the Boss", by Bob Selden

None of these are specifically about a software company, but they all address running companies in general.

A great cautionary tale is in "Dreaming in Code", by Scott Rosenberg. It's the story of a group with unlimited talent, vision, and (nearly) funding. It doesn't end all that well.

The next big issue to tackle is finances. Seriously. Before you even start to talk about your product vision, marketing, or work breakdown, you all need to have an open and frank discussion.

• How much money do you need to live on? For how long?
• How much money do you expect to make from this venture?
• Is this a "built to last" or "built to flip"?
• What kind of competing offer will pull one of you out of the group?
• Where is the funding coming from? How much will the investor take out of you?

Mismatched answers to any of these questions can, and have, killed companies.

Answer 4

Thank you all !

I have got very useful answers. I appreciate all.

tnx a world .

Answer 5

A big question, without a doubt.

I could go on about social, financial and managerial challenges, but I'm going to stick to technical and organizational because my comments here can be straight to the point and provide palpable value.

1. Use a distributed version control system. Mercurial, Git or Bazaar should fit the bill: I can vouch for mercurial. All of these are platform independent, extremely fast and will provide the state of the art code versioning and a lot of flexibility for a team-in-the-making.

2. Use an issue tracker with at least the basics: it should be web-based and be able to describe at least the following: issue name/developer/priority/value/estimate/status/project/type/comments fields. I've found Mantis to be very usable.

3. Use a time tracker. Seriously. It's a tool to help you clearly see where your spending your most valuable resource: time. You may or may not think this is easy, but answering questions like "what did the team spend the last 3 months on?" is not nearly as easy as people sometimes imagine at first. It's a way to know what others are working on, compare how much time you needed to complete something compared to what you estimated in advance, correct future estimates based on prior errors and make decisions based on this experience. I find slimtimer.com to be the closest fit to what I need.

4. Some sort of Scrum approach probably works best in your situation: focus on making things that do something as soon as possible and than expand their capabilities. If (without experience) you get into a situation where you've released nothing for 3 or more months, it's likely you'll either work 70-hour weeks for weeks/months to catch deadlines, blow the project or both. Having a working release every 2 weeks would be very good.

5. You all know something about or are willing to learn how to set infrastructure up. Don't. At this point, it's much, much quicker, easier, and most importantly, more reliable to lean on external services. If you develop open source code, you have it all set up and available (sourceforge.net being the obvious, but not only example) for free. Otherwise, consider purchasing or using free services on the web to spare yourselves as much as possible from anything distracting you from what you do best: design and implement software. Google docs is probably a 100x more useful than 100 MS Office when you're working with joint documents.

6. Do this before you have a spouse and kids. :) You'll need and want to work long hours regardless of how good you are and this is good, but your window of opportunity is 5 or so years. After that, a 40-50h week will be just about all you can muster, which may or may not be enough when time and energy are your key resources.

In summary, version your code, track issue in a dedicated tracker, track time because you will never become too good at time estimates, use an agile/scrum approach to reduce risk, make sure you're not daydreaming and are heading in the right direction, use existing services if they provide 80% of the value, start as quickly as you can.