Chapter 17: Tailoring the DSDM Approach
Previous chapter: 16 Project Planning and Control
17. Tailoring the DSDM approach
17.1 Introduction
This chapter is drawn from the experiences of practising DSDM consultants. It describes some typical ways that DSDM has been adapted or tailored to meet circumstances that they have encountered. Hence each of the suggested actions is tried and tested but not necessarily to the same extent or with the same rigour as the rest of DSDM as described in this handbook.
17.2 The Project Approach Questionnaire (PAQ)
The Project Approach Questionnaire is used to identify areas where a project or its environment is not ideally suited to the DSDM approach. It can be used to negotiate changes to reduce risk and to improve the probability of success. Where changes cannot readily or quickly be made, or if too much change would be required to be accommodated at once, the PAQ can be a useful guide to the tailoring of DSDM to suit individual project needs. If, on collaborative completion of the PAQ, everybody either Strongly Agrees or Agrees with every statement, then the risk associated with using DSDM to manage the project is low. Tailoring is probably not required and DSDM as described in the first section of this handbook should work effectively.
If, however, there is disagreement with any of the statements, then there is probably some risk in trying to use DSDM straight out of the book.
In some cases, simple corrective action is all that is required to deal with the risk.
|
For example: statement 3 “The business vision is clearly stated and understood by all members of the project team”. If the consensus is that the business vision is not clear and/or not understood, then arranging a session for the Business Visionary to share his/her vision and answer any questions mitigates the risk of evolving a solution not aligned with the business vision. |
In other cases the risk raised may not be as easy to resolve.
|
For example: statement 5 “The requirements can be prioritised and there is confidence that date and cost commitments can be met by flexing the scope of what is delivered.” If the consensus is that a very high proportion (or all) of the requirements are genuinely “Must Have” – according to the MoSCoW rules – the DSDM approach will need significant adaptation to cop e with something that contradicts a fundamental underpinning of the way it was designed to work. |
In the following section, each of the statements in the PAQ and their importance to the success of the approach are explained. Where appropriate, hints and tips towards resolving the issue of disagreement with that statement are provided.
There have been many examples of special configurations of DSDM, often created for blue-chip companies. Some of these are published as case studies. Ways of dealing with new challenges will be made available as part of the growing number of case studies available at www.agilebusiness.org
It should be noted that tailoring options may be interim solutions, to avoid imposing too much change for the team at one time. Thus, tailored elements may be subject to better alignment with DSDM at a later time.
One final point to note is that some risks or issues raised through the use of the DSDM PAQ may actually have a root cause that has nothing to do with the approach.
|
For example: statement 13 “The Solution Development Team members have the appropriate collective knowledge and skills to collaboratively evolve an optimal business solution”. If the team doesn’t have the skills required to build the solution, then regardless of what approach is chosen, the solution is highly unlikely to be built successfully. |
17.2.1 The Project Approach Questionnaire Statements
Statement 1
“All members of the project understand and accept the DSDM approach (Philosophy, Principles and Practices)”
If the consensus response disagrees with this statement it is probably because some stakeholders have not been trained (if they are participants) or briefed (if they are less actively involved). It is important that the project team (Project-Level and Solution Development Team roles) fully understand the implications of this statement. Occasionally stakeholders who are fully informed about the DSDM approach still disagree with it, but this is extremely rare.
Suggested action
Organise training and briefings as required. Consider using DSDM Accredited Training Organisations or experienced DSDM practitioners certified to Advanced Practitioner level, or above, to assist where necessary.
Statement 2
“The Business Sponsor and the Business Visionary demonstrate clear and proactive ownership of the project”
Senior business ownership of any project is essential. Without this, a project is likely to be starved of essential business resources (day-to-day jobs being deemed more important by default). This results in major issues, that can’t be dealt with by the project team, remaining unresolved. Such unresolved issues either cause a project to stall or leave it exposed to high-risk assumptions or work-arounds. A committed Business Sponsor who really cares about the project is almost always willing and able to push for significant issues to be resolved where senior management action is needed.
The Business Visionary is responsible for making sure that all par ts of the business impacted by the business vision understand and are bought in to the vision and remain aligned behind it. Managing business stakeholder expectation on a proactive and ongoing basis is key to the success of projects with a wide business impact.
Suggested action
There really is no work-around for a weakness in business ownership and vision. If all negotiation and coaching efforts to actively engage at least the Business Visionary fail (i.e if these critical roles simply refuse to engage in their project), the only technique to be applied here is necessarily harsh, and that is to refuse to start work on that project until the issue is addressed and, instead, to work on a project that does attract the right business ownership and commitment to success. Commercial and political considerations are likely to dictate whether this is even a sensible stand to make. However, for projects where the organisation responsible for building the solution and the sponsoring organisation belong to the same company, the argument of “the greater good of the company as a whole” may carry some weight.
With regard to managing business stakeholder expectation, a strategy for communication that the Business Visionary believes will meet the need, and is happy to play an active par t in, should be considered as part of the Management Approach agreed during Foundations and enacted as the project proceeds. Stakeholders should also be invited to attend demonstrations of the Solution Increments at the end of each Timebox where this helps manage their expectations. (see Statement 16)
Statement 3
“The business vision driving the project is clearly stated and understood by all members of the project team”
All day-to-day project decisions at all levels in the project should be checked against the business vision. Even if the decision seems small or insignificant simply considering “Does this help move us closer to achieving the business vision?” often avoids wasting precious time and effort. If the answer is “Yes, it helps” then the decision is valid, if it is “no” or “not sure” then a follow up question of “So why are we doing this here and now?” should be asked. For anything likely to take up more than a couple of hours it is always advisable to quickly consult an appropriate business or technical authority. Without a clear statement and common under standing of the business vision the thought/questioning process cannot happen and there is serious risk that time and effort will be wasted working on things with limited or peripheral value.
Suggested action
Speak to the Business Visionary, or arrange a session for him/her to share their vision and answer any questions. This should be all that is needed to set the scene for the thought and decision-making described above. It is an explicit responsibility of the Business Visionary to “communicate and promote the business vision to all interested and/or impacted parties” and to ensure that the project remains aligned to it by “monitoring progress of the project in line with the business vision”. Consider creating a simple poster to place above the Team Board to help keep the vision visible to all.
Statement 4
“All project participants understand and accept that on-time delivery of an acceptable solution is the primary measure of success for the project”
There are two key considerations associated with this statement.
The first consideration relates to the business driver behind the project and the importance from a business perspective of on-time delivery. Most businesses under most circumstances want to understand at the outset what a project is going to cost and how long it is going to take. These are very reasonable demands as the cost and the date that benefits will star t to be realised have a direct impact on the Business Case for the project. Over-running budget and, particularly, time, to any significant degree could seriously damage the Business Case or even the business as a whole if a critical deadline is missed.
The second consideration relates to the control of the project. Even if the first consideration (immediately above) is not important, working to a genuinely fixed end date for a project, or at least for a Project Increment, provides an anchor for the combined practices of MoSCoW prioritisation and timeboxing which forms the primary mechanism of control over timely delivery of the solution. It also keeps the Iterative Development practice properly focussed on the business need by discouraging a quest for perfection through iterations with progressively diminishing business value.
Suggested action
Even if there is no hard business deadline for delivery of the solution, it is usually better to plan and resource a project on the assumption that there is. Without a delivery target that everybody buys into, the project risks losing focus and running out of control.
Statement 5
“The requirements can be prioritised and there is confidence that cost and time commitments can be met by flexing the scope of what is delivered”
This statement is closely related to Statement 4, as it is the ability to flex the scope of what is delivered that allows a DSDM project to guarantee an on-time delivery.
Every effort should be made to follow the MoSCoW rules for prioritisation of requirements but it is worth remembering that even if the top-level requirements (that make up the Prioritised Requirements List baselined in the Foundations phase of the project) suggest the rules are being broken, it is possible that flexibility exists in the detail of those requirements.
|
For example: a Must Have requirement to “manage an appointment diary” is likely to break down into sub-requirements to “make”, “change” and “cancel” appointments. At this lower level it likely that the ability to make and cancel appointments would be Must Have whereas the abilityto change an appointment would have a lower priority as there is an obvious work-around (cancelling the original appointment and making a new one). |
Suggested action
If efforts to find sufficient contingency in the scope of the requirement s fail, consider adding more “traditional”- style contingency based around time and cost. In practical terms, this would involve:
- Creating one or more ‘contingency Timeboxes’ that are added to the end of the project
- The committed timescale for the project includes the contingency but the Delivery Plan should clearly reflect an earlier target delivery date that does not include the contingency
- Managing the project in the normal way once development starts. However, instead of de-scoping the least important requirement to protect the target delivery date if that becomes necessary, instead the requirement is pushed out to the first available contingency Timebox
If using this tailoring suggestion, everybody’s focus must remain on the target end date and this target end date must be treated as if it were the real delivery date. Without this focus, the attitude of “It doesn’t matter too much because we can always put it in the contingency Timebox” risks the contingency being used up too quickly and carelessly.
Statement 6
“All members of the project team accept that requirements should only be defined at a high level in the early phases of the project and that detail will be emerge as development progresses”
Defining detail too early in a project causes more problems than it is intended to solve. All Agile approaches exploit the concept of emerging detail to allow the best solution to evolve. Discussion of detail of a high-level requirement may help cement an understanding of that requirement and help estimate the effort to fulfil it.
However, it will also provide a false sense of security as the majority of change to requirements in a project happens in the detail. The reality is that detail defined too far in advance risks being inaccurate when the work on the detail is due to start. This inaccuracy may be as a result of a subtle shift in business need. It may be due to a deepening understanding of what is, or is not possible, based on what has happened up to this point. It may be due to earlier assumptions proving to be untrue. For this reason, DSDM advocates deferring detailed investigation and detailed decisions to the last responsible moment.
Suggested action
Hold early discussions at whatever level of detail is needed to help drive out a shared understanding but do not capture that detail. Have the discussion again closer to the time. Subsequent discussions will probably be shorter as people refresh their memories of what was discussed previously. But these also offer an opportunity to change that detail without being constrained by what was previously assumed or wasting time having to formally change what was previously formally, and pointlessly, defined and agreed.
Statement 7
“All members of the project team accept that change in requirements is inevitable and that it is only by embracing change that the right solution will be delivered”
The DSDM philosophy that best business value emerges when projects are aligned to clear business goals, deliver frequently and involve the collaboration of motivated and empowered people underpins the validity and importance of this statement. It is important to ensure that the project remains focussed on the fundamental need and business vision that justified the investment in it. However beyond that, the Project Team needs to embrace any change needed to deliver optimum business value within constraints of fixed timescales and cost. “What we thought we were going to do” is irrelevant when considered in the light of “what we need to do, now, to build a valuable solution”.
Suggested action
If commercial arrangements dictate that a ‘fixed price for a fixed specification’ model should be applied to the project rather than a more collaborative approach, it is important to recognise that at the working level this will not be a DSDM project. Under such circumstances all that can be done is to segment the project into small deliverable chunks and to ensure the supplier is focussed on and is paid to deliver only what is specified in each chunk. The specification of detail for any given chunk should be left to the last responsible moment and should be informed by what has already been delivered together with the very latest thinking on what is needed. The later chunks in the project should reflect the least valuable features of the product being built by the supplier. Arrangements with the supplier(s) should allow for any changes that may be needed to the product they have built ‘to specification’ in an early chunk to be traded off against later work. This will, at least, force a change-tolerant incremental approach that will help mitigate the risk of losing control of timescales and/or costs.
Statement 8
“The Business Sponsor and Business Visionary understand that active business involvement is essential and have the willingness and authority to commit appropriate business resources to the project”
In a DSDM project there is no detailed specification upfront (compared with a traditional project approach where a detailed specification is created by contributions from many business representatives). Without detailed guidance during development, those developing the solution can only guess at the detail of what is needed which would result in a significant risk of delivering a solution that does not meet the business need. In DSDM, active business involvement means that business roles (Business Ambassadors and Business Advisors) must be involved throughout the project, often on a day-to-day basis, sufficient to:
- Provide detailed guidance on the meaning of requirements
- Understand team plans for the Evolving Solution
- Provide feedback on each step towards delivering a fit-for-purpose solution, acknowledging what is right and explaining what is not
Involvement of Business Ambassadors and Advisors at the time detail is needed cannot be negotiated away, but there is room to negotiate on how much involvement might be needed, and the frequency and form that might take is discussed under the next statement. (Statement 9)
Suggested action
The first and best course of action is to try to secure the necessary Business Ambassador and Advisor time. It is helpful to agree up front the amount of time and the level of commitment expected, at least for the Business Ambassador. This helps inform the business what level of commitment is expected and tests commitment.
|
One example: During Evolutionary Development, Business Ambassador to:
|
It is important to stress that projects cost money and the single biggest cost is usually paying for the time of the people engaged in building the solution. Business resources are critical to the success of the project and should be budgeted for in exactly the same way as the other members of the Solution Development Team. This means that the Business Sponsor may need to pay for somebody to carry out some of the day-to-day responsibilities of a Business Ambassador in order to give them the time they need to spend on this project. It is normally the case that the best person to take on the Business Ambassador role – the main day-to-day business decision-maker on the project - is also often someone who is very valuable to the business area concerned. This means that negotiating commitment of their time needs careful planning and advanced preparation. The answer often lies in other members of the business area picking up key responsibilities whilst handing off responsibilities most easily delegated to somebody more junior. Some businesses choose to delegate simple but time-consuming tasks to a temporary staff member, hired only for the duration of the project but treated as part of the project cost.
If it is genuinely not possible to allocate business resources to work collaboratively with the rest of the Solution Development Team on an on-going basis, then it may be worth considering the approach described in the “Specification-led DSDM projects” tailoring white paper available at www.agilebusiness.org
Statement 9
“It is possible for business and solution development members of the Solution Development Team to work collaboratively throughout the project”
Statement 8 dealt with business roles being allocated and available to the project as needed to guide the detailed development of the solution. This statement addresses the issue of those roles, and the rest of the Solution Development Team, being able to work in a collaborative way.
With regards to business engagement in the Iterative Development process, it would be ideal if the business roles were ready, willing and able to engage in face-to-face conversation with the Solution Development roles immediately and whenever their guidance is needed. This ‘instant access’ would optimise the efficiency and effectiveness of the Iterative Development practice, by minimising the risk of evolving the solution in the wrong way and having to re-work it to make it right. However, such access is rarely achieved and in reality may not represent effective use of business resource time, as it implies they must be co-located with the rest of the team and do little more than sit and wait to be engaged in development or testing activity. There is also a risk that by being removed from their business colleagues, the Ambassador may lose touch with day-to-day happenings in their business area. Although some exceptional projects do require a full-time Business Ambassador commitment, the majority of projects require active involvement of no more than half of an average day as a maximum. The amount of Business Ambassador time should, therefore, be agreed on a project-by-project basis.
What is actually needed is reasonable access throughout the day. This may be perhaps face-to-face (or by telephone or on video conference) at the Daily Stand-up and for a short period afterwards with availability on the telephone for the rest of the day. On occasional days in a month, more intense collaborative activity may be needed, for example in workshops to discuss the detail of requirements towards the beginning of a Timebox or to carry out end-to-end business acceptance testing (allowing for iterative issue resolution) towards the end of a Timebox.
With regard to collaborative working, more generally, it is important that all roles are able to work collaboratively on the Evolving Solution. It is important to ensure that the working environment can support this – ideally by allowing team members to be co-located in the workplace and in less ideal circumstances by providing technology to simulate this.
Suggested action
If access to business resources presents a challenge in terms of time, e.g. where a Business Ambassador is available for a limited number of hours a week, try to formalise the structure of the Timebox so that intense engagement during the Investigation and perhaps Consolidation steps can be planned. Also agree a short period in each day, ideally around the Daily Stand-up, when Solution Developers and Testers can interact with the Business Ambassador.
If access to business resources presents a challenge in terms of geography, e.g. where business resources are in a different building, town, country or even continent, then technology to assist in collaboration will be needed. Video and teleconference facilities are an obvious place to start but other tools are available to help with collaborative working, such as collaborative modelling tools or a virtual Team Board that all can see and interact with.
In extreme, but not uncommon, circumstances – for example when working across time-zones more than 4 hours apart, special tailoring of roles and responsibilities to deal with communication may be required. The case study on “DSDM projects with off-shore development” is available as a tailoring white paper from www.agilebusiness.org.
Statement 10
“Empowerment of all members of the Solution Development Team is appropriate and sufficient to support the day-to-day decision-making needed to rapidly evolve the solution in short, focussed Timeboxes”
A framework of empowerment underpins the DSDM way of working. It is important that members of the Solution Development Team have the knowledge and experience necessary to make day-to-day decisions about how the Solution should evolve and that they are empowered to do so. If members of the team have to keep referring out to ‘higher authorities’ to make or ratify such decisions, the efficiency of the Iterative Development practice, the effectiveness of timeboxing will be seriously compromised and the promise to Deliver on Time will be put at risk.
Suggested action
There is no effective work-around for disagreement on this statement. A way must be found to establish a framework of empowerment even if this takes some time to achieve. The ‘higher authorities’ will need to engage more actively in the project in the first instance with the intention of gradually handing decision-making power to the team as they gain competence and confidence to assume that responsibility.
Statement 11
“The DSDM roles and responsibilities are appropriately allocated and all role holders understand and accept the responsibilities associated with their role”
DSDM has carefully defined roles and responsibilities. One person may hold more than one role and one role may be shared between more than one person. It is useful to use DSDM role names and descriptions, particularly with business roles, as the title re-enforces their main responsibility. When allocating roles it is important to review the responsibilities associated with that role when determining who the role holder should be, in order to get the best fit.
Suggested action
Formal training in DSDM is recommended for all roles. Those people actively working on the project on a day-to-day basis, typically the Project Manager and all members of the Solution Development Team, should attend a DSDM Practitioner course. Roles less actively engaged should attend a DSDM Foundations course. Both training courses explain to each individual the responsibilities of their role in the context of the other roles and the DSDM approach to the project. It is also important to ensure the person in the role understands and is comfortable with what is expected of them on a project-by-project basis.
In some cases, it may be sensible to transfer one or more responsibilities from one role to another to help achieve a good fit of responsibilities to a given individual.
|
For example: If the best person to fulfil the majority of the Business Visionary responsibilities is more junior in the organisation than would normally be expected, it may be appropriate to transfer responsibilities such as “owning the wider implications of any business change from an organisational and business process perspective” and “ensuring business resources are available to the project as needed” to the Business Sponsor. |
Under certain circumstances it may be appropriate for one person to hold more than one role. For example, in a smaller project it might be appropriate for the Business Visionary and Business Ambassador roles to be held by the same person. Sometimes, the person holding the Technical Coordinator role will play a more ‘hands on’ role in developing the solution – in which case the individual concerned may also be a Solution Developer.
A DSDM coach – somebody with real practical experience of using DSDM in a variety of circumstances – can help with roles assignment and tailoring and can also help individuals understand and properly fulfil their roles
Statement 12
“The Solution Development Team has the appropriate collective knowledge and skills (soft skills and technical skills) to collaboratively evolve an optimal business solution”
DSDM works best in circumstances where all team members are experienced and empowered to shape the solution and where they have the necessary soft skills to communicate and negotiate effectively with their teammates. Ideally, solution roles will be technically multi-skilled – willing and able to work across all solution development disciplines (analysis, design, build and test). A key characteristic of an effective collaborative team stems from the ability and willingness of team members to support each other.
Suggested action
With regard to technical skills, at the project level there are no general work-around options to suggest, except to “make the best of what you have”. Where work can only be done by a single individual, try to ensure it is broken down to a level where something tangible can comfortably be delivered in a Timebox. For example, avoid putting a single 10 man-day task into a 10 working day Timebox.
At the organisation level, if DSDM (or any other Agile approach) is being adopted as the default way of working on projects, effort should be made to invest in people; and through training and time for personal growth, encourage project workers to become more multi-skilled over time. The value of training and coaching soft skills where these are weak also represents an excellent investment in people because, as well as being essential in an Agile project team context, these skills can be valuably applied much more widely.
Statement 13
“Solution Development Team members are allocated to the project at an appropriate and consistent level sufficient to fully support the DSDM timeboxing practice”
By default, DSDM assumes that the Solution Developers and Testers are allocated full time to a project at least for the duration of a Project Increment. Where individuals are not full time on a project it is assumed that the work of the project is always their top priority. Where the Solution Development Team is made up of par t-time individuals for whom other work takes priority, it is very difficult to make the timeboxing practice work.
Suggested action
Where resources are only available par t-time, first try to secure formal agreements as to how many hours per day, per week or per Timebox they will spend on the project. Ideally agree specific times, e.g. 9am to 12:30pm Monday through to Thursday. Where multiple team members are par t-time, try to synchronise agreements in order to allow team members to work collaboratively.
Agree objectives and schedule the work in Timeboxes to match availability of resources: be careful not to over-commit, especially in circumstances when availability may be unpredictable. In cases where resource availability is very unpredictable, do not commit to a delivery date, just agree to try and meet a target. If this is unacceptable to the Business Sponsor, make it their problem to negotiate a more appropriate resource profile; perhaps by using contract resources.
Try to make the work as granular as possible – the smaller each piece of work, the more likely it will get finished within the boundaries of the Timebox. Avoid the temptation to make the Timeboxes longer as this dilutes what little focus on delivery there is.
Statement 14
“Tools and collaborative working practices within the Solution Development Team are sufficient to allow effective Iterative Development of the solution”
Collaboration and empowerment underpin DSDM’s Iterative Development and timeboxing practices.
Suggested action
Whenever appropriate, face-to-face communication should be encouraged at all levels. The supporting practices of Facilitated Workshops and Modelling play a significant part in making this effective.
Where teams are not co-located the suggestion offered for Statement 9 applies, i.e. using technology to assist in collaboration, and considering additional roles to focus on communication.
Statement 15
“All necessary review and testing activity is fully integrated within the Iterative Development practice”
Chapter 11 (Iterative Development) and Chapter 16 (Planning and Control) comprehensively cover the rationale for this statement. The essence of the guidance provided is to start thinking about how the solution will be tested as early in the lifecycle as possible and defining and executing a strategy for testing that gets as close as possible to delivering fully tested Solution Increments at the end of every Timebox.
Suggested action
Where fully integrated testing cannot be achieved – perhaps due to challenges of integrating the outputs of two or more Solution Development Teams, or where testing is carried out by a separate off-shore team – it may be sensible to set up a parallel stream, ideally made up of dedicated resources, focussed on testing and fixing any defects that may emerge as a result of that testing. Timeboxes in the testing stream would be offset from those in the main development stream so that the output of the development Timeboxes that have just finished would be the input for a testing Timebox that is just about to start. As much testing as possible should still be carried out by the original development teams and the Technical Coordinator will need to be actively engaged in ensuring that solution and test design across teams is compatible. This should lower the risk of significant rework emerging from defects discovered by the integration/testing team.
Statement 16
“Project progress is measured primarily through the incremental, demonstrable delivery of business value”
The primary output of each Timebox should be a demonstrable increment of the Evolving Solution. Every effort should be made to ensure that this is the case. If it is, then measurement of progress is easy and fully transparent with all interested stakeholders able to see tangible progress as a result of the work of the Timebox.
The demonstration of the Solution Increment at the end of a Timebox is an excellent way of keeping all stakeholders informed of progress and provides them with a real opportunity to understand in detail how they will be impacted by the solution once it has been deployed.
Suggested action
In most cases, if Solution Increments cannot be demonstrated, it is as a result of a poor strategy for Iterative Development or poor application of the timeboxing practice. In the rare circumstances where it is genuinely not possible to deliver a demonstrable Solution Increment, think about what can be demonstrated. It is vitally important that all stakeholders have confidence that the project is moving towards a successful conclusion and is on track to deliver a valuable solution in the timeframe and for the budget agreed. Do whatever is necessary (within reason) to allow this to be achieved.
|
For example: an early Timebox was proving the ability to communicate with a new customer located several hundred miles away, so that financial transactions could be transmitted in a subsequent Timebox. The early Timebox transmitted a simple “Hello” message which was then printed at the remote site, as proof that the communication channel was now in existence. |
Consider making the demonstrations at the end of each Timebox open to anybody who is interested in what is happening in the project and, where appropriate, use it as a way of helping keep stakeholders on board.
Statement 17
“There are no mandatory standards or other constraints in force that prevent the application of the DSDM Philosophy and Practices on this project”
Many organisations assume that the “fixed price for a fixed specification” model is the best foundation for a commercial agreement as it appears to transfer the risks associated with the project to the supplier organisation.
For many projects this transfer of risk is an illusion as all of the risks and issues associated with the traditional Waterfall way of working – which the DSDM approach was designed to address – are actually exaggerated by this commercial framework. Whilst it is true that there may be somebody to pursue for compensation when a project goes wrong, such litigation is extremely rare as ‘blame’ for failure can rarely be put exclusively on one party to the agreement. And the end result is still that the business “loses”, since it has lost time and still does not have a viable business solution to the problem.
Suggested action
Consider the DSDM Principles, Practices, Roles and Responsibilities. If any of these are seriously undermined by commercial agreements, then the DSDM approach may not be the best approach to use for the project. Whilst the ‘fixed price for a fixed specification’ model for project is flawed, it is well understood, and trying to force DSDM to work under the restrictions imposed by it are likely to make the project even more risky than it would otherwise be. For many organisations, the procurement team are only set up to deal with a traditional style contract, and simply do not have the mindset or the willingness to take on the risk associated with a different style of contractual relationship, even where it should directly benefit the organisation.
At time of first printing of this handbook in mid-2014, work has been going on for some time to evolve an effective Agile contract framework but this is a work in progress. Check www.agilebusiness.org for resources and links to other sources for contractual models available that suit your project.
17.3 Summary
DSDM is a flexible framework for building and delivering business solutions. The advice above describes ways of tailoring DSDM to overcome issues where the project or the environment in which it exists are not ideally suited to the Agile (empowered, collaborative, iterative, incremental) way of working. In the majority of cases where issues are identified, what is really needed is a change of mind-set of those involved rather than a customisation of the project approach. The full value that can be gained from using DSDM will not be achieved if too many compromises are made, so every effort to get buy-in to the approach, and all that that entails in terms of working practice, should be exhausted before starting to adapt it.