Systems grow incrementally. Iteration is inherent in all software development. Recognizing this and, by making it explicit, iteration can be used to continuously improve the system being developed. When rework is not explicitly recognised in a development life-cycle, the return to previously "completed" work is surrounded by controlling procedures that slow development down. Since rework is built into the XM process, the development can proceed more quickly during iteration.
A product-based approach is more flexible than an activity-based one. The work of the team is concentrated on products that can be delivered in an agreed period of time. This enables the team to select the best approach to achieving the products required in the time available. By keeping each period of time short, the team can easily decide which activities are necessary and sufficient to achieve the right products. Products include interim development products, not just delivered systems.
Teams must be empowered to make decisions. Teams consist of both developers and users. They must be able to make decisions as requirements are refined and possibly changed. They must be able to agree that certain levels of functionality, usability, etc. are acceptable without frequent recourse to higher level management. The focus is on frequent delivery of products.
Fitness for business purpose is the essential criterion for acceptance of deliverables. The focus of XM is on delivering the necessary functionality at the required time. The computer system can be more rigorously engineered later if such an approach is acceptable. Moreover partial solutions can be delivered to satisfy immediate business needs. Traditionally the focus has been on satisfying the contents of a requirements document and conforming to previous deliverables, even though the requirements are often inaccurate, the previous deliverables may be flawed and the business needs may have changed since the start of the project. Iterative and incremental development is necessary to converge on an accurate business solution.
Requirements are baselined at a high level. Baselining high-level requirements means "freezing" and agreeing the purpose and scope of the system at a level which allows for detailed investigation of what the requirements imply. Further, more detailed baselines can be established later in the development, although the scope should not change significantly.
All changes during development are reversible. To control the evolution of all products (documents,software, test products, etc.), everything must be in a known state at all times. This means that configuration management must be all-pervasive. Backtracking is a feature of XM. However in some circumstances it may be easier to reconstruct than to backtrack. This depends on the nature of the change and the environment in which it was made. The ability to reverse changes is limited to within the development of an increment.
Testing is integrated throughout the life-cycle. Testing must not be treated as a separate activity. As the system is developed incrementally, it is also tested and reviewed by both developers and users incrementally to ensure that the development is moving forward not only in the right business direction but is technically sound. Early in the project, testing focus is on validation against the business needs and priorities. Towards the end of a project, the focus is on verifying that the whole system operates effectively.
Active user involvement is imperative. XM is a user-centred approach as well. If users are not closely involved throughout the development life-cycle, delays will occur as decisions are made and users may feel that the final solution is imposed by the developers and/or their own management. Users are not outside the development team acting as suppliers of information and reviewers of results but are active participants in the development process. Therefore the developers can make full use of feedback from the users.
A collaborative and co-operative approach between all stakeholders is essential. The nature of XM projects means that low-level requirements are not necessarily fixed when the developers are originally approached to carry out the work. Hence the short term direction that a project takes must be quickly decided without recourse to restrictive change control procedures.
The stakeholders include not only the business and development staff within the project, but also other staff such as Service Delivery or resource managers. When development is procured from an external supplier, both the vendor and the purchaser organisations should aim for as efficient a process as possible while allowing for flexibility during both the pre-contract phase and when the contracted work is carried out.
© 2015, ProjectCoaching