Businesses activities, processes and services are supported by business solutions and platforms. They are enabled by information technology that is planned, built, operated and continuously developed. The majority of an organisation’s development initiatives are based on existing solutions and services. In order to transform and expand a business, innovative solutions and services are a necessary addition.
Development initiatives are organised into value streams, which guide the understanding, organising, and value delivery for a business. Value streams can be organised by technology or business domain or as a hybrid (see Chapter 2.1 Strategic Planning for more information on value streams).
The development initiatives that feed in to the value streams are created from four sources of demand as illustrated in the diagram below:
- Capability Planning – Plan a major business capability development
- Ideas & Concepts – Generate ideas and challenge the status quo
- Increments & Improvements – Uplift to existing business solutions or capability
- Service Changes – Continual service improvement.
These sources of demand transform into development requests and then evolve via different development paths.
Figure 5.0.1 End-to-end development
The development discipline is focused on one outcome, the business value. However, achieving the right balance between short- and long-term value can be difficult: whether to react to the immediate needs of the business by improving the existing solutions and services or invest in transforming the architecture and implementing innovative solutions. The development function provides an efficient approach and best practice for managing development requests from all sources without compromising the value.
The following principles apply when maximising both short and long-term business value:
- Assign dedicated resources to focus on specific development requests to ensure efficiency and an improved throughput
- Take control of development activities by planning and putting in place an appropriate governance structure. This will enable identifying the dependencies with other projects and make corrective actions without delay
- Stay close to business to ensure greater business value. Executive decision-making alone is not enough to drive informed business decisions. Shorter feedback loops between the business, development teams and end users will provide faster and smarter decisions.
Selecting the right development methodology
The Business Technology Standard proposes two types of development methodologies, each with the following characteristics:
- Sequential development consists of a specified number of phases, where the previous phase must be reviewed and verified before moving on to the next one. Quality is assured by defining acceptance criteria and test cases in order to evaluate whether the solution fully or partially satisfies the outlined requirements. The test team will then execute these test cases and validate the developed product
- Incremental development uses an iterative process where the teams and the customer of the solution/product provide feedback throughout the entire process of development. A large amount of work is divided into smaller chunks called ‘sprints’. The solution is incrementally implemented and tested in a sprint. This means that implementation and testing are closely integrated within a sprint which then ties two sprints together. The testing then provides feedback for the next implementation step or sprint. When implemented fully, this approach enables incremental releases into the live environment with each sprint which enables early realisations of benefits.
Assigning resources for the delivery phase
There are two ways to deliver development requests: dedicated teams and shared resources teams. Both teams have the objective to maximise the business value produced.
- Dedicated resources teams achieve faster time-to-market as they have full-time resources allocated to their development requests and decision making is less complex. The continuous use of agile development practices creates a rhythmic routine that allows teams to communicate and work together efficiently. The team headcount remains the same and is therefore a fixed cost. However, the team must continuously justify the value of the deliverables they are generating. This approach is typically associated with incremental development
Figure 5.0.2 Dedicated resources team
- Shared resources teams allocate a portion of dedicated capacity across business units/functions and can scale up a larger number of resources on demand for major development requests. As there are typically more development requests than can be handled by shared teams, prioritisation of resources is handled centrally. This can slow down time-to-market, yet it ensures that the necessary resources will be allocated towards the prioritised development topics. This approach is typically associated with sequential development.
Figure 5.0.3 Shared resources team
For large and non-standard development requests, it is still good practice to initiate a project as it promotes good governance and stakeholder practices.
Large enterprises often utilise a mix of dedicated and shared development capacity. Dedicated teams can be used either for core business platforms due to continual high development volumes or, for new product and service development to ensure fast development cycles. Shared development teams are useful when there is a need for scalability or flexibility arising from variable demand.
What are the core components of the development discipline?
Figure 5.0.4 Six governance elements of the development discipline
The development discipline structure can be adapted to the culture of the organisation. Nevertheless, it is important that the following aspects are considered:
- Feasibility and prioritisation ensure that important development requests are completed first, the outcome delivers the maximum business value and the right skills are allocated to focus on the task.
- Commitment to fulfil a request authorises allocating people and other resources for the development. Commitment is based on the prioritisation phase and considers factors such as availability of resources, dependencies, stakeholder readiness and risks
- Steering and risk mitigation support decision making during the development process and help to mitigate any identified risks. Fast and iterative development cycles allow risk identification and mitigation early in the development to avoid speed bumps further down the line. Gate reviews and steering groups help to mitigate risks for larger development programmes that will have a greater business impact
- Development methodology consists of designing, validating and deploying the solutions into the business environment based on a well-defined and understood procedure that is in use. In addition to the technical development, the focus should be on change management in order to enhance the success of the deliverables, such as communication with the stakeholders, running training sessions and collecting feedback
- Transition to service ensures that the business processes remain intact when a new or modified solution is introduced into operation. This will provide the capability and capacity to respond rapidly with a greater certainty of success
- Benefits realisation occurs when the deliverable has reached the business value initially promised in the business case. The findings can then be fed back into the prioritisation process to support future decisions. The business benefits often materialise soon after the service has been deployed. However, it is good practice to monitor that the benefits are delivering the value in the long-term as well.
The table below illustrates how the development methodologies are used within the core components.
| |
Sequential |
Incremental |
| Feasibility and prioritisation |
The business case is prepared by the project steering group and reviewed and prioritised by the portfolio steering group. |
The product owner prioritises requests in a backlog based on the demands of the value stream stakeholders. |
| Commitment to fulfil a request |
The project steering group and the development portfolio approve the project plan, schedule the necessary resources and manage the dependencies. |
The development team determines what requests in the backlog they can complete during the upcoming sprint. |
| Steering and risk mitigation |
A plan is created beforehand, and anticipated risks are managed. Milestones and checkpoints throughout the project lifecycle provide steering and risk mitigation. |
Development is broken down into smaller deliverables and discussed more frequently (daily stand-up, sprint planning, etc.). |
| Development methodology |
Each stage represents a distinct phase of development that must be completed in sequence. |
Development is done in incremental sprints. A backlog tracks the desired features and requirements. |
| Transition to service |
Final deliverable is tested and released into production at the end of development. |
Continuous testing and feedback of the incremental deliverables result in minimal impact to the service. |
| Benefits realisation |
Most at once when the final deliverable is deployed. |
Gradually with each incremental release. |
Applying Minimal Viable Governance
Minimum viable governance is an effective method for maintaining consistency and efficiency of a deliverable without compromising the agility and speed.
Governance is important as it establishes responsibility, authority and communication to support the overall goals and strategy of the businesses. It also defines metrics, policies, standards and control mechanisms to enable the employees to carry out their roles and responsibilities effectively. However, it is important to find the right balance between governance and agility.
Organisations can also define effective processes and practices, such as self-evaluation mechanisms, and follow-up the completion criteria. The development teams can assess whether they fulfil the requirements by asking questions such as:
Does this project meet the fast track criteria? Have approved partners been used? Have the right stakeholders been involved? Does the solution align with the existing architectural standards? Is the solution compliant with the security policy?
The governance of projects throughout the development lifecycle will vary based on the methodology employed.
Embedding industry development practices
The Business Technology Standard provides a pragmatic and business focused reference model that enables the adoption of development practices. The standard is flexible to evolve with organisations of all maturity levels and can integrate practices such as Scaled Agile Framework and DevOps. Some examples of development practices are:
- Scaled Agile Framework (SAFe) organises dedicated development workstreams with a specific business focus. It provides an incremental development pipeline from idea-to-service with built-in prioritisation and steering procedures
- DevOps (Develop and Operate) can be implemented on a smaller scale as it contains less built-in steering and governance procedures. DevOps is good practice for dedicated incremental development
- Project and Portfolio Management (PPM) manages the alignment of projects with the business’s strategic objectives. It is a structured approach to controlling complex projects and programmes that have a major business impact. The function selects and prioritises projects, allocates suitable resources, monitors their progress and provides consolidated information to stakeholders.
