Listening to the team
There is an old saying in software that goes something like this, “Scope, Timeframe, and Budget: Pick two.” Being a tester, I would rephrase this a little as, “Features, Timeframe, Budget, and Quality; Pick three”. It’s usually possible to hit all three of the first choice as long as you are willing to sacrifice quality. We’ve all seen products that do this. They have such potential, but just don’t work. Over the past year, there were lot of planning efforts going on around me and this was a great chance to observe different behaviors. One pattern I have seen a few times is worth discussing. That is managers trying to dictate all 4 aspects of a project. There are two ways this tends to happen: the dictatorial manager and the persuasive manager.
Before we jump in, it is important to define the four levers. Features represent the complexity of the product—how many things it can accomplish. Timeframe is how soon the product needs to ship. Budget is how much can be spent on the project. For software projects, this corresponds largely with the number and skill of people that can be put on the task. No discussion of budget can be complete without at least mentioning Brooks’ law. Quality is the ineffable attribute representing beauty, greatness, or merely suitability for a given task. In practical terms it means how many bugs are exposed by the product. Increasing the expectations for any of these increases the pressure on the project. Within reason, each can be relaxed to achieve the desired levels of the other three. It is important that managers understand that when they ask to increase features, they are trading off time or that when they ask to reduce time, they are trading off features.
The dictatorial manager is the more obvious of the two. This is the person that just says, “You will have the following specs done by this date.” Implied is that this will be done with a fixed number of people (never enough) and of high quality. This is the pointy haired boss from Dilbert. When the team raises objections, this manager is unphased. They stick to their position. If the team can’t get it done in the timeframe they ask for, they will find someone else who will. It never occurs to the manager that perhaps what they are asking for is impossible. The only good news is that this type of manager is often self-correcting. They are not enjoyable to work for. The best members of the team have mobility and will leave. This slowly guts the team of the most capable people and the project slowly fails. At a quality company this manager will be seen for who he is and removed from such responsibility.
The persuasive manager is less obvious but nearly as bad. This is the manager who convinces their team that it can do the impossible. In this case they don’t dictate an impossible situation, they merely get the team to agree to it. This manager is usually a really nice guy who just can’t say no. Instead they ask people nicely to sign up for everything marketing and upper management ask for. Their team likes working for them, it just can’t figure out why it is so over-worked. The quality of the project suffers as the team goes into an over-worked haze. This sort of manager is not as quickly self-correcting. The team does not leave except through burn-out. They don’t blame the manager because signing up for the work was their idea. Neither the dictatorial manager nor the persuasive manager will succeed. Both will usually ship something close to on time because they cannot admit failure. The quality, however, will be low. People stop caring once they are made to attempt the impossible. The team will be much weaker the next go-round because all of the good members leave through disgust or attrition.
A better model is to listen to the team. Most times a manager does not have control of all of the levers. Typically timeframe and budget comes down from on high. A manager cannot magically hire more people. Except through brinksmanship, they cannot cause the project to ship later. They do, however, have control over the expect level of quality and the number of features. A team will usually give signals if they think they are being asked to do too much. The wise manager listens to this and adjusts plans accordingly. This is the genius of systems like Scrum and Agile development. A tenet of these systems is listening to the team. Using a system of cost estimates and burndown tracking helps bring an objective view of the picture. Likewise, if the team hesitates or balks at signing up for work, a good manager will re-evaluate. This doesn’t mean automatically reducing the ask, but it does mean making sure you are convinced it can be done.
If a manager senses that the workload is too much, it is their responsibility to reduce it. As much of a manager’s job should be spent deciding what not to do as deciding what to do. This may generate heat from upper management who wants everything in a limited time, with a fixed budget, and at the highest quality. Helping upper management understand the situation and even taking the pain if understanding is not conveyed is the responsibility of the manager. If failure is inevitable, it is better to fail in a place of your choosing (that with the least impact/priority) rather than risk failure on a broader scale at a later date.
Comments
Anonymous
September 22, 2011
nice post Steve! 100% agree that the job of the manager is to allow amazing people to an amazing job. I have not met a lot of people in software who are no passionate about shipping a great product. When the team says it can't be done - most likely its because it really can't.Anonymous
October 30, 2011
www.dilbert.com/.../2009-08-12