If you’ve ever been in a small programming shop just starting up with a single project, you may experience some difficult situations arising from uncertainty over project roles.
The principal of the shop probably had the idea for the software and the technical skills to convince some backers that his idea was feasible. Then he discovers he doesn’t have time to do everything that needs to be done. He hires over time, a designer or two, a developer or two, and as the product approaches market maybe a server administrator and a help desk coordinator. Because it’s an evolving small shop, everybody has glided into a set of tasks they perform, but newly identified tasks can be problems.
Coordination of work, ensuring that subtasks are completed so that contingent tasks can start on time, is obviously an important factor. Unfortunately—the natural decider—the principal, is probably being pulled into essential business decisions and customer contact.
Being a self-starter, he might assume all his team know what needs to be done and who is best at each task. That is not a good assumption. In general, staff will choose to do things they are comfortable with, which are often not the things that must be done. (see Limits of Perfection for a situation with similarities.)
The principal, to free up his own time for tasks he alone can handle, should designate one member of the team as the team lead. That person takes the deliverable timetable the principal provides and breaks it into tasks the team must perform to meet the timetable. The team lead needs to establish the links and order between tasks. He or she (I’ll use he from now on, since I’m a guy) works out with the team who is best suited to do individual tasks.
When a staff which use to pick its own work items is forced to organize, it can be difficult. A kickoff meeting where the principal publicly appoints the team lead, he presents the project task timeline, and the rest of the staff give their feedback to the entire group is nearly essential. Typically such a kickoff should be limited to ½ to 1 hour.
After that, periodic meetings reviewing the status of tasks and contingencies, as well as inevitable changes, should be held and managed for length. The purpose of the meetings is to cover the points needed as quickly as possible. Meaning the team lead provides an agenda before the meeting—specific tasks that require status, alerts for changed requirements, open floor for comments should only be 5 or 10 minutes max. The team lead also needs to summarize the result of the meeting, for himself, the principal, and the staff. That includes at the report top—green, on target at current rate of progress for delivery date; yellow, something must change to make the date, identifying what is the problem and what is the suggested solution (more hours, shifted resources, whatever); and red, no way to make the date under the team lead’s control, i.e. with current staff, scope, and deadline, principal must decide which constraint can be changed.
Separation of Tasks
Just as in software projects, separation of functions among programs pays dividends, so does separation of tasks among programmers.
Features should be worked on in layers.
- Include or exclude decisions must be made by the principal
- Design, scope, and separation of functions should be made by team lead, or designer if the team luckily includes one
- Programming by the programmers
- System testing by testers or if none available, then by programmers who did not code that part of the system
- Help desk members should help with testing as well as critique documentation