Important choices are made when determining the architecture for the improvement project: what are objectives, what to look for? The improvement architecture is the foundation for the improvement project and comprises the following components: business objectives, improvement objectives, scope, context en constraints.
Improvement requires investments, which means that an organization expects benefits from it, like increased quality, shorter time to market, lower cost of software development. The trigger for improvements can be positive (the organization wants to innovate), negative (there is a problem to be solved) or a combination of both. All people involved in an improvement project need to be aware of the business objectives.
An improvement project has objectives too. These relate to business objectives, but apply to a particular scope, such as ‘test cost needs to be reduced’ or ‘less incidents in production’. The assumption is that meeting the improvement objectives contributes to meeting the business objectives. Assumptions like this are based on heuristics, which means that initiated improvements may or may not contribute to the business objectives. The improvement architect (a role explained below) in particular needs to stay aware of this.
Scope of improvement
This is the area of concern for the improvement project. A large scope (such as ‘all testing’) often comes with generic improvement objectives (like ‘reduce test cost’). Smaller scope (e.g. ‘unit testing’) have more specific improvement objectives (‘more test automation’).
The context must be well known in order to decide on the proper approach of further steps such as an assessment. Examples of context aspects are:
- Assumed maturity of the organization
- Domain (bank, mobile, embedded, …)
- Level of formality in the organization, domain, project, process, …
- Size of the organization (large enterprise, internet start up, …)
What constraints apply to the improvement project? Think of available budget for the improvement project, the timeline in which the assessment phase must be completed and the priority that the assessment and other improvement activities have relative to business as usual.
A professional that is expert in improvement projects and that has adequate feeling with the context.
Improvement architecture heuristics
Question behind the question. When discussing the objectives, always be aware that there may be a different question behind the first or formal question. (Replace ‘question’ with ‘objective’ or ‘problem’ when needed). If this happens and is not detected before the next phase of the improvement project, this will waste effort and time and potentially can work out counter productive. Example: Objective seems: implement test automation, while the real problem is the software is too buggy.
Completeness. Are there any other goals/ interests in the organization that are relevant?
Who asks the question? Empathise with the client: What are his interests, prejudices, sentiments towards testing, this assignment? What is his importance? (how to judge his judgements?).
Representativeness. Is there anyone left out, to be incorporated, to talk before the start of an improvement project?
Representativeness – top of the class. Organizations that want to score tend to put ‘top of the class’ part of the organization in scope and weak parts not. This influences representativeness and puts integrity at risk.
Representativeness – coverage. The sample size (the coverage) applied in the assessment must be big enough to build up a representative basis for improvement suggestions.
Scope too narrow. Organizations that want to solve problems may limit the scope to the problem area only. This may limit the possibility to observe useful practices elsewhere in the organization that can be an example for improvement. It also may limit the possibility to dig into problems when the root cause seems outside the primary scope.
Scope mismatch. This can happen when a problem after the problem exist but is not found (yet). Example: outsourced team is not included in the scope, but the root cause seems to reside within the outsourced team.
Continuity of the improvement architect. It is most preferable that the professional that put together the approach also is involved in the assessment (or the other way around…).
Change readiness. Organizations that are eager to change can be approached with opportunism, that is: during assessment dialogues potential changes are explored. This results into a more vigourous improvement approach. Organizations that are reluctant to change have more benefit from an assessment approach that focusses on building buy in for future changes. This results into a more careful improvement approach.