Rapid & Flexible
Agile is a RAPID and FLEXIBLE methodology that consists of robust planning, evolutionary development, prior delivery, and ongoing improvement. Agile breaks product development work called SPRINTS into small increments that reduce the amount of up-front planning and design. Agile sees an impact on Risk as a faster approach requires diligence in the Scrums and daily Stand-Ups to ensure quality. Microsoft are now positioning this as the appropriate methodology for Dynamics 365. We use this methodology because it gives our clients greater control over the final solution because they can easily change the direction of the solution development and implementation from one sprint cycle to the next. The delivery phases stage from diagnostic, analysis, design, development, deployment and operation.
Establishing if the project is viable – typically completed by the client before QUANTIQ engagement.
The Feasibility phase is intended primarily to establish whether the proposed project is likely to be feasible from a technical perspective and whether it appears cost-effective from a business perspective. The effort associated with Feasibility should be just enough to decide whether further investigation is justified, or whether the project should be stopped now, as it is unlikely to be viable.
The Foundations phase takes the preliminary investigation from Feasibility to the next level. It is intended to establish a fundamental (but not detailed) understanding of the business rationale for the project, the potential solution that will be created by the project, and how development and delivery of the solution will be managed. By intentionally avoiding low levels of detail, the Foundations phase should last no longer than a few weeks – even for large and complex projects. The detail associated with requirements, and how they should be met as part of the solution, is intentionally left until the Evolutionary Development phase of the project.
For smaller, simpler projects, the Feasibility and Foundations phases can often be merged into a single phase.
Building on the firm foundations that have been established for the project, the purpose of the Evolutionary Development phase is to evolve the solution, the Evolutionary Development phase requires the Solution Development Team(s) to apply practices such as Iterative Development, time-boxing, and MoSCoW prioritisation, together with Modelling and Facilitated Workshops, to converge over time on an accurate solution that meets the business need and is also built in the right way from a technical viewpoint.
Working within Timeboxes, the Solution Development Team create Solution Increments, iteratively exploring the low-level detail of the requirements and testing continuously as they move forward.
The objective of the Deployment phase is to bring a baseline of the Evolving Solution into operational use. The release that is deployed may be the final solution, or a subset of the final solution.
Some examples of what can be deployed are:
Once approval has been given, Deploy is the physical act of putting what has been assembled (the release) into operational use. It includes any technical work, such as transfer of the solution into the live (production) environment, but also the enactment of any plans for business change.
After the final Deployment, the project is formally closed. At this point, the whole team hold a retrospective to review the overall project performance, both from the technical and/or process perspective and from the business perspective.
After the final Deployment for a project, the Post-Project phase checks how well the expected business benefits have been met. Although it may be possible to highlight immediate benefits, most benefits will accrue over a pre-defined period of live use of the solution.
The Post-Project phase produces one or more Benefits Assessments for these realised benefits in relation to the business case. Benefits may be assessed for individual releases (in which case the assessment of benefit should start before the Post-Project phase is reached), for the whole project or may be omitted completely, depending on the needs of the organisation.