Section 7.1. Non-value-adding Activities

7.1. Non-value-adding Activities

7.1.1. Replicating Fixes to Multiple Releases

Symptoms

One of the most common ways to waste time is replicating fixes from one release to another. For example, many teams have two development streams: one for new features and one that is the previous release into which only bug fixes should be added. When a bug is fixed, the engineer has to be sure that it gets into both releases. As the code bases of the two releases diverge, the probability that the fix won't be the same in both releases increases. This means that the duplication is going to require even more effort than simply copying the fix to multiple release streams.

In addition to multiple releases of one product, this duplication can also be caused by the need to have multiple versions of the same release. For example, a web-based product and a desktop product could share a common core, but lack of tool support may cause the team to create two copies of that core.

Possible Process Innovations

Configuration Management Patterns/Tools

Many of these situations can be resolved by reducing the complexity of duplicating changes. Providing tool support for the branching and merging of development streams can be helpful in addressing this problem. The merging capability is particularly significant because it eliminates the need to put changes into both streams. There are many strategies for the creation (and subsequent merging) of streams. Tool support for the selected strategy can achieve a number of simplifications to your process. The main goal is to minimize the duration of parallel streams because that will minimize their divergence and simplify the merge process.

Continuous Integration

If you allow branches for individual development activities, it is important that you require that those individual branches be used for only one task each and that they be merged back into the main branch regularly. Again, this would reduce the duration of each branch and minimize the chance that a merge will require effort.

Source Code Refactoring

If having multiple versions of the system causes the duplication of streams, restructuring the code with the goal of isolating the differences from the shared portion of the system may reduce the duplication. Essentially, there should be a common core of files that are shared for both versions of the system. Two separate layers implement the differences between the systems. Refactoring to maximize the size of the core would reduce the duplication in the other layers and would therefore reduce the number of changes that have to be hand-copied.

7.1.2. Difficulty Resolving Design Issues

Symptoms

In plan-driven teams, design decisions are often left to a small set of architects. However, in an agile team, everyone is responsible for the quality of the design. This often leads to lengthy and passionate discussions weighing alternative designs. Even when everyone involved behaves in a professional manner, these debates can be fractious and time-consuming. There are specific strategies that can help the team resolve these issues more effectively.

Possible Process Innovations

Set Based Decision Making

When one design strategy is not clearly better than another is, it may be best to defer the choice between them. Instead of choosing one solution arbitrarily, the team can either implement the aspects the solutions have in common or implement both solutions in parallel. Often, the learning that happens during this process results in a design that is better than either of the original choices.

Impact Estimation Table

This is a technique to quantitatively compare the impact of various design decisions and their effects on meeting the customer's requirements. It is most useful in situations where the requirements are numerical (speed, performance, cost, etc.).

7.1.3. Unused Documentation

Symptoms

If your team spends time creating documentation that subsequently becomes unused, it is time to think about whether the effort used to create it was valuable.

I once worked for a telecommunications company that used a waterfall-type process. In the midst of the coding phase, the developers recognized that we needed a significant change to the high-level design of the system (functionality that was designed to be on one board in the system needed to be moved to another). When we discussed this with management, they told us to make the change to the code and not worry about the documentation. They said, "Don't worry about the documentationwe'll fix it up after we ship." This clearly demonstrated that correct documentation was not valuable (at least to management!). They believed that we could successfully code the change without first specifying its details, and they didn't care if the documentation didn't match the resulting code. However, it raises a number of questions: if we don't need the documentation, why did we spend months building it, and why would we bother to fix it up after we ship?

The creation of the document does have value if that process helps us refine our understanding of the system and gives us a direction. There is only an argument for allowing the first version of the document to go out of date if some other technique replaces its role as the code deviates from the original plan.

Possible Process Innovations

The general strategy in these innovations is to replace traditional documentation with something that is used throughout the development cycle.

Generation of Design from Code

Coding standards can go a long way toward helping generate documentation from code if they require that comments follow a format that allows a tool to extract the documentation from the comments. Although this is built into Java with javadoc comments, there are similar tools for almost every other language. Because the comments are usually in close proximity to the code, they are much easier for engineers to keep up-to-date than traditional documentation.

However, the documentation that is generated from commented code is often still at too low a level to provide an understanding of the high-level architecture. For example, javadocs will give a list of all of the classes in a package and let you see all of their external interfaces but do not provide a picture of how the engineers expected those classes to interact with each other. In other words, this technique gives us structural documentation as opposed to behavioral documentationunless the engineers include behavioral descriptions in their comments.

Automated Unit Tests

When an engineer develops automated unit tests for a class, those tests can provide an interesting addition to the class-level documentation. Essentially, the engineer is encoding the way he expected the class to be used, so this is behavioral documentation as opposed to structural documentation. When a new engineer needs to use the class, she can look at the unit tests to find examples of how the class can be used. If the team sets a goal of using the tests in this way, the resulting tests are generally both concise and precise! In addition, if we run the tests regularly, we know they must match the code, so they are documentation that never gets out of date.

Automated Acceptance Tests

Not all documentation that can be out of date is design documentation. Requirements documents also age as the system matures. At the post-mortem of one six-month (relatively short!) project, I asked the team if their system matched their requirements document. They replied with, "No, we've experienced feature creep and feature sleep!" They had features that the customer had not requested and were missing features that the customer had specifically requested.

One way to ensure that customer requirements match the system is to encode them as automated acceptance tests. Regularly running these tests ensures that they continue to match the system's behavior. This will prevent "feature sleep" because every feature will be encoded in one or more tests. Unfortunately, this does not prevent feature creep!

Whiteboard Design

If your team needs to perform some early design but does not need that documentation to last (because it is replaced by one of the preceding techniques), then it is often more efficient for a group of engineers to hash out the initial design as a diagram on a whiteboard. After they agree on this initial direction, it can be recorded as simply as taking a photograph. The goal is to make the process of developing the design as efficient as possible, and particularly if it is an initial design, encoding the diagrams in a CASE tool can be more cumbersome than necessary.

7.1.4. Extraneous Features

Symptoms

One aspect of agility that challenges some engineers is the idea that there are features that do not add value to the product. Because engineers enjoy the technology, they often think of additional functionality that does not seem to take much effort to build, and this results in feature creep. However, if we spend time developing a feature that the customer has not requested, that time is essentially inventory that we will never convert into throughput. In other words, it never helps our throughput and lowers our efficiency. Often engineers see the possibility of a feature that won't require significant development time and implement it even if it has not been requested. Even if the customer likes the feature, if it hasn't been requested, it isn't going to generate throughput. In order to have high efficiency (i.e., high agility), it is important that only the features that are requested get developed.

Possible Process Innovations

Planning Game or Product Backlog

Sometimes the root cause of extraneous features is a lack of understanding of exactly what the customer has requested. Using the planning game or having one person be responsible for maintaining the product backlog can help the team keep track of exactly what features have been requested.

Open Workspace and Pair Programming

Increasing communication among the team can help people notice when extra features creep into the system before the effort of completely implementing them has been spent.