This is the first in a series of posts in which I will try to collect my view of problems in introducing Agile techniques in an organisation, forces that work against Agile and traps that are just waiting to catch the unwary agile practitioner.
Slogan
Generalization makes useless
Applies to
With the obvious risk of falling into the Agile Anti-Pattern: Over-Generalization this Anti-Pattern can apply to many different types of items:
- Goals
- Definitions of terms
- Requirements
- Plans
- Stories
- Definition of Done
- Tasks
- Implementation
Examples
Programmers often feel a need to write robust source code. If the exact circumstances in which the code will be executed is not explicitly stated, it is tempting to generalise, second-guessing any future and currently unknown situations.
Exactly the same thing might happen for requirements. A stakeholder might be very broad in his description of the need. But it must be broken down into more and more concrete examples. We know that “The system must react fast to any user input …” is not a requirement usable for development. It might be usable for validation in system test though, because it is a value articulated by the users, and as such can be subjectively validated. But it does not give the concrete information to know when it is actually done.
Over-Generalization in definitions of terms is also common. I have seen it often in planning of business change programs. Particularly in large organizations, where there are many different types of products, situations and projects, definitions of practices easily becomes to generalised to be useful.
For example, in a transition to Agile, the practice “Continuous Integration” might be taken to mean
- all tests and integrations are automated
- there are no manual tests
- system tests are done automatically
… and more. It is not that these goals are bad, in fact they are excellent. But at the core “Continuous Integration” probably means something like “giving programmers concrete feed-back of every change as soon as possible by running builds of as large part of the whole product as possible and as large set of tests as possible as soon as possible after every change to any part of the source code”. As for any change that is to be implemented we need to know exactly what we are trying to implement.
Often people want to include their particular situation, need or interpretation into a definition. The mostly generates bloat. This might also be one of the causes of “requirements creep”.
If a definition is taken to encompass everything related, the definition becomes useless.
Remedy
The best way to handle Generalisation is of course to break down to concrete or less general items. For source code this is already addressed in Agile software development techniques. As the saying goes, don’t implement anything that the current set of tests doesn’t require. This makes us do the simplest thing that could possibly work. This is good advice in any circumstance, and at the core of Agile.
However, sometimes this is not accepted by some of the people involved or affected. A common pattern to this resistance to simply is that it could be perceived as making one persons particular definition or need out of scope. One technique here is to separate that particular part of the definition out into a separate item. It is important not let this come across as removing it, particularly to infer less value in it. This way it is usually possible to get a concensus on a set of tighter, more concrete, items.
Once a set of more concrete items has been agreed upon, a prioritisation process can commence. So it is important to have this prioritization step when handling all types of items. This separates the assignment of importance from the concretisation.