DSDM Agile principles for process redesign projects
Agile projects, especially process redesign projects should be conducted based on a set of rules. This ensures that each project is run in the same way and follows the same principles. A good guideline for this is the DSDM Agile principles, which set out simple and easy to follow rules which, if followed, will give a strong trajectory for the project.
DSDM agile sets out 8 key principles:
- Focus on the business need
- Deliver on time
- Collaborate
- Never compromise quality
- Build incrementally from firm foundations
- Develop iteratively
- Communicate continuously and clearly
- Demonstrate control
The full DSDM principles can be found at agilebusiness.org
Focus on the business need
“Every decision taken during a project should be viewed in the light of the overriding project goal – to deliver what the business needs to be delivered, when it needs to be delivered.”
In process redesign there are always key decisions being made. Therefore, these decisions need to be kept in line with the business need and the improvement of the service for both staff and customers. An example of this could be organisations move to a digital platform, processes should be designed to meet the new digital way instead of falling back to the old technology. If decisions are unclear the business visionary could be consulted to ensure the correct path is taken to focus on the business needs.
Deliver on time
“Delivering a solution on time is a very desirable outcome for a project and is quite often the single most important success factor. Late delivery can often undermine the very rationale for a project, especially where market opportunities or legal deadlines are involved.
Even for projects without a need for a fixed end date, on time delivery of intermediate or contributing products is still the best way to demonstrate control over evolution of the solution.”
In a process redesign project it is important to set deadlines for when individual processes or groups of processes are going to be complete. This not only gives that set deadline to deliver on time to, but also gives the later stages a timescale to build off. Furthermore, having a set time limit helps to stop process mapping becoming overly complicated and detailed past the need of the service or development team.
A good way to achieve this is to use MoSCoW prioritisation to give an order to the list of processes set to complete. This is covered in a previous blog, “MoSCoW prioritisation for Timeboxes in Agile projects”
Collaborate
“Teams that work in a spirit of active cooperation and commitment will always outperform groups of individuals working only in loose association.
Collaboration encourages increased understanding, greater speed and shared ownership, which enable teams to perform at a level that exceeds the sum of their parts.”
As discussed in a previous blog, “Why an Agile Team is necessary for a process improvement project”, the construction of an agile team is vital to a successful project and process mapping team.
Never compromise quality
“In DSDM, the level of quality to be delivered should be agreed at the start. All work should be aimed at achieving that level of quality – no more and no less.
A solution has to be ‘good enough’. If the business agrees that the features in the Minimum Usable SubseT meet the agreed acceptance criteria, then the solution should be ‘good enough’ to use effectively.”
Image reference Projects have to balance the Time, Cost, Quality and Features delivered, somewhere there has to be a variable. In a traditional project, the cost and time is the variable. Therefore, the project will likely be over time and over budget as all features have to be developed, leading to inconsistent quality. In contrast, an Agile project keeps the time, cost and quality fixed while having the features variable. This leads to high-quality features delivered in time and to budget, but not all features will be developed. To achieve this, the requirements for the project are prioritised into the categories of; Must have, Should have, Could have, Won’t this time. As a general rule, the Must have requirements shouldn’t take over 60% of the available time and effort in a project or timebox.
Built incrementally from firm foundations
“One of the key differentiators for DSDM within the Agile space is the concept of establishing firm foundations for the project before committing to significant development. DSDM advocates first understanding the scope of the business problem to be solved and the proposed solution, but not in such detail that the project becomes paralysed by overly detailed analysis of requirements.”
Develop iteratively
“DSDM uses a combination of Iterative Development, frequent demonstrations and comprehensive review to encourage timely feedback. Embracing change as part of this evolutionary process allows the team to converge on an accurate business solution.
The concept of iteration is at the heart of everything developed as part of the DSDM approach. It is very rare that anything is created perfectly first time and it is important to recognise that projects operate within a changing world.”
A key part of process redesign workshops is to gain feedback from the wider team, working interatively allows for that wider team to be kept informed and gives opportunity for improvement.
Communicate continuously and clearly
“Poor communication is often cited as the biggest single cause of project failure.
DSDM practices are specifically designed to improve communication effectiveness for both teams and individuals.”
Demonstrate control
“It is essential to be in control of a project at all times and to be able to demonstrate that this is the case. This can only be achieved by reference to a plan for the work being done, which is clearly aligned with agreed business objectives.
It is also vital to ensure transparency of all work being performed by the team.”
As a business analyst in charge of a redesign team it is important to insure that the project is running smoothly and following the guidelines and framework set out by the Project Team.