Avoiding the Disjointed Features Syndrome

The “disjointed features syndrome” is a phenomenon that occurs when features are built with the resulting product being a collection of features that may not integrate correctly, have inconsistent user interfaces, and/or user experiences.

For example, the below table has the following features:

• It has four legs; and
• Is able to be placed on a flat surface.

Although the table above satisfies all the requirements, it’s still an unusable product. Another example is a disjointed document where paragraphs aren’t orthographically consistent; such as the usage of different tense or points of view (among other things).

Below is an outline of a few delivery behaviours to avoid, in order to reduce the occurrence of the “disjointed features syndrome”

Feature-Only Review Ceremonies

All too often review ceremony meetings become only about the last iteration. When this happens, the only changes that are examined are the features completed in the last iteration itself, instead of the entire product end-to-end.

This creates a situation where the focus is on new features, not how they interact with the entire product. More often than not, it isn’t new features that make a product valuable, rather, it’s the removal of unnecessary features that enable this visibility of value in a focussed fashion.

To avoid this behaviour, beware of only reviewing the previous iteration’s changes during the review. Whilst recent changes should be the emphasis, a review on the entire product, or at least, a vertical slice of the product each and every review will hedge against the “disjointed features syndrome”.

In addition to an assessment of the immediate iteration, an honest and blameless assessment against a product vision should occur during reviews. This product vision should be an easily adaptable artefact that can change based on delivery team velocity and/or market changes. Product vision arefacts are often expressed in terms of road maps, goals, or impact maps (my favourite).

Procrastinating Deployment To End Users

Being agile isn’t about perfectionism, it is about testing what needs to be perfect, and discarding things that shouldn’t be pursued to perfection. Part of this mentality is exposing end users to the product being built early on in the development process. Finding friendly early adopters or testers will enable a systems-level perspective on the product in a way that the delivery team may not be able to.

The immediate delivery team of a product is constantly exposed to the product, they understand it intimately, and are accustomed to its flaws and features. Often, it is a new and different perspective that highlights obvious flaws in a product. This is where useability and experience testing with early adopters pays off.

Pursuing the “Extensive Detail” Dichotomy

When the “disjointed features syndrome” occurs, user stories will often get blamed for not having enough detail. Solutions that are often recommended during post-mortems or retrospectives is to make user stories more detailed. Unfortunately, this creates a situation of localised thinking within a user story, and more often than not, creates situations where the “disjointed feature syndrome” is amplified rather than reduced.

Localised thinking is the antithesis of systems thinking, and systems thinking is an important aspect in hedging against the “disjointed features syndrome”.

Conclusion

In conclusion, avoiding the above behaviours will help in reducing the chance that the “disjointed features syndrome” will occur in your product, however, a constant and continuous awareness and product level thinking is the ideal behaviour that a team should have. Avoiding the above behaviours are an initial starting point to help encourage product thinking inside an immediate delivery team.