|< Day Day Up >|| |
To get started thinking about teams, I want to touch on a few of the “soft” (nontechnical) issues involved in team management. I’m not going to try to cover the management field in general. Instead, I’ll just mention a few areas that have been important on my own small teams: choosing a structure, tracking progress, and avoiding your own incompetence.
If you get interested in this subject, much has been written about managing people in the software business. The classic in the field (and a book well worth reading) is Tom DeMarco and Timothy Lister’s Peopleware (Dorset House, 1999).
One of the decisions that needs to be made early in the team-building process is how the team will be structured. Two of the most common alternatives for small teams are to set up a community of equals or a hierarchy. Each of these has its own pros and cons.
In a community structure, each person on the team is recognized as being equally capable. While different team members will work on different tasks, team members are expected to be able to step in and work on whatever area of the project needs the most attention. Decisions on a community project are typically made by consensus and may require extensive discussion before everyone is in agreement.
A hierarchical structure is more typical of for-profit software development by established companies. Such a structure has one manager (most often with a title such as “program manager,” though there’s no reason that the manager can’t be a developer or a tester) who makes the major decisions and to whom everyone else on the team reports. Hierarchical teams are often structured with people in non-interchangeable roles; there will be a tester, for example, who does nothing but test even when development is lagging.
Are there other potential structures? Sure! For example, you might have a community of experienced developers, each managing a hierarchy of less-experienced developers. But these more complex alternatives tend to be used with larger projects than I’m focused on.
My own personal preference for small project teams is to set up a community of equals. Such teams can be harder to set up, but I find working in them to be more fun. However, there’s no reason why your preferences need to match mine in this area. What’s more important is that the entire team be clear on how things are organized.
If team members can’t agree on a basic structure, the team is unlikely to be able to produce any software.
Whatever your preference for team structure, it’s important to keep track of what everyone is doing and whether they’re running into any problems. Depending on the tools that you’re using in your development, you may get some tracking as a side effect. For example, you can configure some source code control systems to automatically send e-mail whenever a new module is checked in. Similarly, some build tools can update a web page on your intranet whenever a new build is successfully tested.
In addition to these moment-by-moment updates (if they exist), it’s helpful to get a sense of the big picture on a regular basis. For small teams, I like to keep the level of formal process to a minimum. One method that’s worked well for me in the past is the 3 3 report. This report might go to all team members or only to the project manager, depending on how the team is organized. The key is to have each team member produce such a report on a regular basis; I find that weekly is usually the right frequency. As its name suggests, a 3 3 report contains three lists of three items each:
Three accomplishments for the previous week
Three obstacles to progress from the previous week
Three plans for the coming week
There’s no need to be completely dogmatic about the number of bullet points in each section. If you’ve got four accomplishments, or only two obstacles, that’s fine. The important thing is to make time to step back once a week and be sure you’re still on track. In a community team, you should also commit to watching everyone else’s 3 3s and offering suggestions when you have them. In a hierarchical team, the team manager can watch for trouble signs. For example, if the same obstacle appears week after week, the team member may need some help in moving forward. Having items appear in plans for one week and then never show up in accomplishments for the next week can also be a problem.
The Peter Principle is a bit of satirical sociology from the late Dr. Laurence J. Peter: In a hierarchy, every employee tends to rise to his or her level of incompetence. Dr. Peter managed to get several books out of this sentence, but while his books are enjoyable, you can understand the principle without reading them. In most organizations, people are promoted when they do their job well, but never demoted unless they do something truly dastardly at the company Christmas party. The end result is that people stop getting promoted when they stop doing their job well, and languish in a position that they can’t really fill.
In many software organizations the Peter Principle is evident at work. Successful developers get promoted and turn into unsuccessful managers of developers. In fact, the problem may be worse in software than in many other industries, simply because of the gap between what developers do and what their managers do.
If you find yourself managing a software development team, it’s worth taking some active steps to avoid falling afoul of the Peter Principle yourself:
Don’t take on a big team as your first management task. Start small.
Set aside part of your time to handle management chores, such as reviewing the weekly 3 3 reports, settling disputes among team members, and providing guidance for any team members who appear lost or confused. Don’t assume things will just take care of themselves.
Pay attention to the natural authority distributed around the team. If you’re working with good people (and you should be), they will have good ideas that you never thought of.
Take advantage of the literature on software project management to learn how to be a better manager. An excellent (and not too long) starting point is Jim McCarthy’s Dynamics of Software Development (Microsoft Press, 1995).
Of course, as a developer-turned-project manager, you do have one big advantage: You understand the development process, so you’re likely to be able to understand what the rest of the team is telling you. Just don’t let the attraction of actually writing code keep you from doing the necessary management tasks.
TECHNOLOGY TRAP: Big Process in Little Teams
As you’re reading about software project management, there’s one thing that you should be aware of: Much of the literature presents processes and methodologies as if one size fits all. That is patently not true. Small teams have a different dynamic than big teams do, and can get by with far less process. In fact, too much process (defined as rules to follow, paperwork to fill out, and required tools and procedures) can be fatal to a small team’s chances of actually shipping a product.
There are any number of formal processes out there for developing software, from the Microsoft Solutions Framework (MSF) to the Software Engineering Institute’s Capability Maturity Model (CMM). Each of them specifies a method for developing software, often with a set of design documents that need to be produced, specific modeling requirements, and so on. While these methods can produce excellent software, they can also impose a tremendous overhead on the development organization.
It’s worth browsing through the software management literature to look for practices that might apply to your team. A good starting point is Steve McConnell’s Rapid Development (Microsoft Press, 1996), which presents a smorgasbord of practices. But implement new bits of process carefully and gradually, and try to measure whether they’re actually helping or hindering your team.
|< Day Day Up >|| |