UMass offers a software engineering course (CS320) that teaches the software design process — on real projects, with real teams. It is managed by select students who have successfully passed the course. Below are some rules I (tried to) live by while managing my 12-member team.
- Never have a meeting without a clear agenda.
- Never have a meeting without setting the end time.
- Stick to the end time. When time’s up, pack it up and plan the next one. (aka: Don’t punish others for your own poor planning)
- Make the call and move on. Decisions are temporary.
- Resist the urge to make every single decision. As a manager, your goal is to keep everyone on track, not micromanage the project.
- Be prepared to quickly jump in and take a more active role if the team is languishing for direction.
- Maintain an environment where everyone has an opportunity to have their opinion heard. Some people write better than they speak; make sure both channels are open.
- Encourage ownership. Every person should be able to point to something they are responsible for. Corollary: don’t say “We should fix that bug.” Say: “Bill, you should fix that bug.”
- Maintain a mailing list and updated contact information that everyone can see. This is a no-brainer, but some managers either don’t do this or are slow to realize it’s needed.
- Have a process for updating members who don’t come to meetings. This may encourage absenteeism, but full attendance is the exception rather than the rule, and without a process for managing and tracking decisions people will miss crucial information.
- Don’t wait until the day before the due date to get together — that last day should be for polishing your work, not frantically starting the milestone.
- Let your team set the pace, but veto anything unachievable or overly optimistic. They’ll be more inclined to meet a deadline they’ve agreed to, but more so if they came up with it themselves.
- Short milestones are better. In my experience, about half to about three quarters of the team are going to need micromanaging, and will need to be babied from one step to the next. PLAN FOR THIS.
- Keep pinging team members for updates and force them to get on the ball; most people aren’t going to do anything on their own until 1 or 2 days before the submit date (and that’s dangerous) unless you prod them like cattle.
On team dynamics:
- Don’t overestimate your ability to “get it done alone.” CS320 teams will often agree to work on their own, but most won’t do a thing unless they are in a meeting.
- Make sure there’s good cohesion. Don’t put all your groups into silos. Personally, I make my entire team work on and present documents as a whole.
- Despite the previous bullet point, it is easier to divide up work vertically than across each MVC layer.
- Having an authority on each aspect of the project is a good idea. Generally, there should at least be an architecture mastermind, a database guru, a UI pro, and a system testing fiend. These same people lead the requirements and design all the way up to the implementation of their respective module. If you’re lucky, you will get 1 or 2 people to actually fill these roles; if not, you’ll have to be all 4.
- Make sure the team understands what all the definitions are first, as well as the overall format of the requirements document.
- Use clear, concise, plain english to start.
- Functional requirements dominate; UI mockups are worth their weight in gold.
- Don’t start until every single coder has the required software and environment set up. You will personally set up every single person’s environment, or someone will not have the environment set up. Have a meeting, visit their houses, set up remote hands — whatever it takes. If you think people can follow a set of instructions that involve downloading an installer and clicking next-next-next just because they’re compsci juniors — well, you’d be wrong.
- A remotely hosted database is easier than setting up 15 MySQL installations on all 3 platforms.
- Use a proper issue tracker, and make sure everyone knows how to use it. It’d be crazy not to have one, but surprisingly some managers don’t.
- Make sure you teach people how to use SVN. Or maybe don’t bother. Most people will be unable to continue if there’s an SVN conflict — either troubleshoot each one individually, or set up a procedure for reverting local changes.
- There will be SVN conflicts.
- Some members of your team will inadvertently not know how to code. At all. Make sure they work for their grade by reading a ton of basic things like how to manipulate strings or write functions to keep them busy.
- If its a particularly long meeting, make sure there’s food and drink to keep people alive. As tired as it is to joke about EA, this isn’t EA.
- The team succeeds or fails as a whole. Avoid singling people out for praise, and be candid about feedback.
- Conversely, don’t publicly point out individual failures. Unless they’re yours.
- Set the right expectations early on. Some people think they can coast through with little effort, so you have to be vigilant about making sure everyone does their fair share, or the ones actually working hard are going to feel like suckers — and that’s dangerous for morale.
- Go to your own meetings. If your team is roughing it out with an all-nighter, you need to be there too, even if it’s just to crack jokes and fetch pizza.
- After each milestone, get together to talk briefly about how things could’ve gone better, and brainstorm ways to avoid repeating the same mistakes. Embracing failure is key to improvement. This is a tired platitude, but I know of very few people who actually practice this advice.
- The tell-it-like-it-is style of self-assessment works, but only if that’s really what you’re doing. Don’t sugarcoat the truth to your groups, but try not to turn feedback sessions into demoralizing whine-fests.
Prepare for this to take over your life for a semester. Even if you already feel like you were doing all the work in 320 (which is probably why you chose to take 529), this will be more work.
Finally, my last point is the most important: You have to play the hand you’re dealt. Inevitably, things will not be going to plan, and you can’t expect to use the same failing approach but expect different results. As they say, that’s the definition of crazy. Software engineering isn’t a particularly hard course, if something isn’t going right, it’s usually the manager’s fault. And in the rare case that it isn’t, it’s still your problem. Deal with it.