Section 7.4. General Smells

7.4. General Smells

7.4.1. Burnout

Symptoms

One of the worst smells a team can exhibit is burnout. One of the goals of the project should be to produce a well-functioning and productive team. When engineers become bored or disconnected from the project, their productivity goes down, and they can become a drain on the enthusiasm of the rest of the team.

Possible Process Innovations

Sprint Planning Meeting or Iteration Planning Game

One source of burnout can be a lack of belief that the project can succeed. Impossible schedules and unreasonable demands drain everyone's enthusiasm. These strategies can ensure that the team has input into the plan. This helps ensure that they believe they can succeed.

Sprint Planning Meeting, Iteration Planning Game, or Kanban Scheduling

These planning strategies have an interesting side effect: because each engineer is selecting the tasks he will be responsible for, this promotes ownership of the tasks and can be an opportunity to expand his expertise into new areas (provided he is allowed to give an estimate that includes appropriate learning time).

Sprint Review

Demonstrating the progress that has been made at the end of each iteration can build confidence and momentum.

Individual Evaluation Strategies

Strong management can aid the planning strategies in helping people extend their capabilities and interests. Appropriate individual metrics and evaluation can encourage everyone to learn about new technologies and new areas of the system, which will increase everyone's enthusiasm for the project and the team.

Source Code Refactoring

Working on code that contains "broken windows" can be demoralizing for engineers because in general they prefer to build and work on systems that are well-designed. Seeing a lack of quality in the code can make it seem like quality doesn't matter, so why should anyone bother improving things? In these cases, training in refactoring techniques and allowing appropriate time for the refactoring activities inherent in every development task can improve team morale in addition to improving the quality of the product.

Pair Programming, Team Ownership of Code, and Open Workspace

The cohesion of the team is one of the best defenses against burnout. All of these techniques promote team cohesion and encourage the team to prevent burnout on their own.

"Gold" Cards

Iterative development has a very strong and repetitive rhythm that can leave engineers feeling as if they are slaves to the process. Iterations become mechanical, and boredom can result. "Gold" cards encourage engineers to break out of the rhythm for more open-ended explorations.

7.4.2. Engineers as Bottlenecks

Symptoms

In traditional organizations, there are often engineers that are "experts" in specific portions of the system. Usually, they are responsible for all of the changes anyone makes to that portion of the system. In an agile organization, those "experts" can become bottlenecks. If an iteration requires significant changes to the expert's part of the system, too much of the work may require that expert's time, leaving him overworked and everyone else idle.

Possible Process Innovations

Pair Programming and Team Ownership of Code

Paying attention to agile values, the solution to this problem is to have the expert share her expertise with other engineers. When other people are comfortable with that portion of the system, the expert will no longer be a bottleneck (though she may still be the expert). Having the expert pair with a number of other people on tasks affecting that portion of the system will help other people learn to work on it. This will promote team ownership of code, which will reduce all of your bottlenecks.

Individual Evaluation Strategies

It's important to recognize that the expert may find sharing his information to be quite threatening. His status in the traditional organization came from the fact that he was the only person who understood that portion of the system. He needs to understand that the team is not trying to take his status away. The negotiations involved in developing the expert's performance evaluation criteria can help him learn to play a larger role in the design of the entire system and in the education of other team members.

Pipelining Iterations

Finally, if it is impossible for the expert's knowledge to be shared effectively, pipelining might help you spread his effort over multiple iterations and reduce his impact on any one iteration. However, this has some significant risks. First, he'll probably be developing code that does not have customer visibility, so he won't be getting any feedback. Second, this is going to require a longer-term plan that may turn out to be invalid as the customer sees the deliverables of each iteration. Finally, you have segregated that individual further from the team, which undermines the team's ownership of the system. This strategy goes against many agile values. It should only be undertaken when there is no alternative. At a minimum, pair another programmer with the expert in the hopes that the paired person will be able to bring the expertise back to the team.

7.4.3. Floundering

Symptoms

Floundering occurs when the team or an individual doesn't know exactly what needs to be done. In these cases, engineers are very good at looking busy but are not making optimal progress on the required tasks.

Possible Process Innovations

Spring Planning Meeting, Iteration Planning Game, or Kanban Scheduling

The primary source of floundering is lack of a specific iteration plan. Any of these techniques will let the team specify all of the things that need to be done in the current iteration and help them negotiate who is responsible for each task. These techniques only require an hour or two at the beginning of the iteration, and they let everyone see exactly what needs to be done for the entire iteration.

Daily Scrum/Daily Stand Up Meeting

Regular status meetings can reduce floundering by giving each engineer a regular opportunity to talk about anything that is preventing her from making progress so that the team or the team leader can help eliminate those problems. In addition, having to report progress to the team every day encourages people to stay on task.

Burn-down Chart or Informative Workspace

Making the status of the iteration easily available can help everyone see when progress is not as expected. Given that information, the team will readily detect any floundering and eliminate its cause.

Pair Programming or Open Workspace

Often, individuals flounder when they are having trouble finding a good design or making a piece of code work. Having teammates close by to bounce ideas around can help people get unstuck very quickly. In addition, there is a certain amount of peer pressure to keep working when colleagues are close by.

Backlog

When a team nears the end of an iteration, sometimes they finish tasks early and have nothing left to do. In these cases, having a backlog lets the team find another feature that the customer wants and that fits in the time left, so they can deliver one more feature. Alternatively, these lulls at the end of an iteration can be filled by having a list of non-deliverable tasks that would benefit the team. These could include things like researching a new technology or developing or deploying a technique or tool to help the development process.

Change Iteration Length

It is very hard to flounder when deadlines approach, so one strategy to manage floundering is to shorten the iteration length. This has two effects. First, it makes the estimates more accurate and therefore the plan more realistic, so the team knows better what needs to be done. Second, it makes the deadlines closer, so there is less room for floundering at the beginning of the iteration.