PosgreSQL `hstore` problem in django django.db.utils.ProgrammingError: type “hstore” does not exist

Migration problem while using Django‘s models Hstore fileld (posgres specific)

Django version: 1.8.3

Exception: django.db.utils.ProgrammingError: type "hstore" does not exist

Solution

  1. Create a empty migration
    1. ./manage.py makemigrations –name <migration name> <app_label> –empty
    2. example migration file.
    3. Run ./manage.py migrate
    4. No create real migration

assign local role in plone through zmi

Assign local role in plone through zmi

While developing application, some times situation may come to need resource specific permission/authorization. For example, you are member of a development team, so you have a office room with 5 desks for you and your colleague, all of you have equal access to enter into the room but in case of your own desk you are the owner! and you have not same permission for other desks to do anything.

For this situation plone provides very easy solution, you can assign local role for each Archetypes content.  So let’s start your application

  1. Go http://{your portal url}/@@usergroup-userprefs and add new user normally. Oh! please remember the usename.
  2. Go http://{your portal url}/{content url}/manage_listLocalRoles . i.e http://localhost:8080/room/mydesk/manage_listLocalRoles
    1. From left `User` type that username and from right `Role` select your desired role. Don’t worry! you can assign any role even owner, manager; it is local role and will only impact on this content.
    2. North Line Hospital
  3. Go http://{your portal url}/portal_workflow/manage_selectWorkflows
    1. Click `update security settings` button bellow.

Now enjoy the benefits!

Skype problem in Ubuntu

I have faced problems several time while trying start Skype. It doesn’t open, even trying from  terminal! instead of printing this errors
skype: symbol lookup error: /usr/lib/i386-linux-gnu/libQtOpenGL.so.4: undefined symbol: _ZNK14QWidgetPrivate17hasHeightForWidthEv

Solution

  1. Open terminal type ~$ sudo nano /etc/ld.so.conf.d/skype.conf
  2. Add this line ` /usr/lib/i386-linux-gnu/mesa/` and press Ctl+X
  3. Finally ~$ sudo ldconfig -v

* My Ubuntu version 14.04 LTS, it should work since 12.04 LTS

** Common FAQ

  • Question: I have already done above & working perfectly but when applying new updates; same problem happen.
  • Answer: Don’t panic please just follow 3 no step. ~$ sudo ldconfig -v

Credit AskUbuntu

=———————————————————–=

Another problem may facing Ubuntu user for Skype, that is Skype open just for a while and stop or could be continuous restarting. [Recently 20th Dec, 2015 I faced this problem, although my OS version is Ubuntu Server 14.04 LTS ]

Solution:

  • Make sure you have sqlite3 installed in your PC. Other than you can install it easily by following this instruction
  • Go to your terminal (CTRL + ATL +  T)
  • Precaution: The following attempts will remove all of your previous files transfer history
  • $ sqlite3 ~/.Skype/[YOURUSER}/main.db
  • > sqlite> DELETE FROM Messages WHERE type=68;
  • > .quit
  • Congratulation you are done! Try to start skype.  

 

Date Time format in Python

With my long experiences in programming, we have to do lots of deal with DateTime. Here basically I will demonstrate Python’s `string to datetime` object and `datetime to string format`

from datetime import datetime

# First we will make string date to datetime object
# Example string format is: month/day/year 24hours:minute:seconds
dt = datetime.strptime("09/24/2014 23:09:44", "%m/%d/%Y %H:%M:%S")
print type(dt)
# should be <type ‘datetime.datetime’>

# Now we will produce string representation of python’s datetime object
# Format will be week day name, day, full month name, year 12hour:minute:second AM/PM
print dt.strftime("%A, %d %B, %Y%t%l:%M:%S %p")
# should be Wednesday, 24 September, 2014 11:09:44 PM

List of format directives

  • %a – abbreviated weekday name
  • %A – full weekday name
  • %b – abbreviated month name
  • %B – full month name
  • %c – preferred date and time representation
  • %C – century number (the year divided by 100, range 00 to 99)
  • %d – day of the month (01 to 31)
  • %D – same as %m/%d/%y
  • %e – day of the month (1 to 31)
  • %g – like %G, but without the century
  • %G – 4-digit year corresponding to the ISO week number (see %V).
  • %h – same as %b
  • %H – hour, using a 24-hour clock (00 to 23)
  • %I – hour, using a 12-hour clock (01 to 12)
  • %j – day of the year (001 to 366)
  • %m – month (01 to 12)
  • %M – minute
  • %n – newline character
  • %p – either am or pm according to the given time value
  • %r – time in a.m. and p.m. notation
  • %R – time in 24 hour notation
  • %S – second
  • %t – tab character
  • %T – current time, equal to %H:%M:%S
  • %u – weekday as a number (1 to 7), Monday=1. Warning: In Sun Solaris Sunday=1
  • %U – week number of the current year, starting with the first Sunday as the first day of the first week
  • %V – The ISO 8601 week number of the current year (01 to 53), where week 1 is the first week that has at least 4 days in the current year, and with Monday as the first day of the week
  • %W – week number of the current year, starting with the first Monday as the first day of the first week
  • %w – day of the week as a decimal, Sunday=0
  • %x – preferred date representation without the time
  • %X – preferred time representation without the date
  • %y – year without a century (range 00 to 99)
  • %Y – year including the century
  • %Z or %z – time zone or name or abbreviation
  • %% – a literal % character

Courtesy: Tutorial Point

Rapid Application Development: Project Risk Management

When planning a project you hope for the best, but there is always a chance of something unexpected preventing this. Project risk management is about having the confidence of knowing what to do if the worse occurs, and what this will cost.

Project risk management consists of two key aspects: determining the risk, and designing counter measures.

Determining Risk

When determining risk there are three key aspects to consider:

  • The event causing the risk.
  • The likelihood of the event happening.
  • The impact on the plan if the event occurs.
Risk Events

When planning, it is impossible to determine every risk causing event that may occur. Many things can occur on a project, and you could spend forever trying to anticipate them all. However, as will become clear, it is not important to consider them all, you need to consider a representative selection of events that could effect a project.

Risk Likelihood

Even when we have a set of risk events, we do not generally have accurate statistics about their occurrence. It is unlikely therefore that we can determine their exact likelihood. This is a reason that a subjective scale of high, medium, or low is often used to determine likelihood. It focuses attention on those events you feel will be most likely to occur.

Risk Impact

The next step is to determine what impact a risk event may have on a project. This means determining what effect it will have on the scope, time, resource, or quality aspects of the project plan. These can vary from an annoyance through to a total catastrophe. Various scale scan be used but a similar three point scale of high, medium, or low is also often used.

Why Do It?

The process described so far appears very subjective, liable to error, and will definitely not be complete. So why do it? This is a valid question for many project plans, which just determine risk and go no further. However what we are really interested in is delivering a project plan in a way that satisfies the customer. This is the importance of the counter measures part. It states what you will do if a risk event occurs to mitigate the damage.

Designing Counter Measures

Project Risk Mitigation

When designing counter measures it will be noticed that the same counter measure can be employed to cover several different types of risk. What is more those same counter measures will most likely prove useful against risks you have not anticipated. This is the power of risk planning; by planning how to deal with the worst that you can think of, you are also providing insurance for events you have not considered. Therefore you have raised the possibility that the project will be delivered successfully.

Generic Risk Counter Measures

Risk counter measures will reduce the likelihood, the impact, or both of a risk happening. There are various generic risk counter measures that can be used to reduce risk. As an example supposing you wanted to cross a busy road in order to buy some fish and chips. Your options could be:

  • Eliminate the risk: Buy fish and frozen chips from a supermarket and cook them at home.
  • Cease the activity: Decide not to have fish and chips.
  • Reduce the likelihood: Carefully check the road and only cross when there is no traffic.
  • Reduce the impact: Wear body armour so that if you are hit then it will have less effect.
  • Early warning: Check the road to see if there is any traffic before crossing.
  • Avoid: Decide to have a pizza instead from a shop on your side of the road.
  • Share or transfer: Ring for a taxi to go and collect your fish and chips.
  • Accept risk: Just cross the road anyway.
Selecting Counter Measures

To select appropriate counter measures you check your list of risk events and consider for each of them what you could do to mitigate the effect of it happening. You start with the high likelihood and high impact events, and work down to the low likelihood and low impact events. For each consider the generic counter measures list and see if any can apply to the risk event you are considering. As an example for a test plan if there is a risk of the software being delivered to testing that does not even run, you may cease the testing activity. By documenting this in advance in the test plan all stakeholders are aware of the possibility of this extreme action. Another event may be the loss of one of the testing team. This could be covered by:

  • Reducing the likelihood, by ensuring the team are well paid, and have had a successful health check,
  • Reducing the impact, by having spare team members, or a call off arrangement with a contract agency,
  • Early warning, by having a strong system of staff appraisal, and other measures to see if staff are likely to become unavailable,
  • Accept the risk, by notifying the customer that if the event occurs then the scope, time scale, or quality standards will have to be adjusted and meeting convened to discuss.

There are other possibilities, but there are costs associated with all of them.

A Balanced Risk Management Plan

A balance must be struck between no planning, and planning to the point of project paralysis. The key is to balance the cost of the planning process, along with likely costs of counter measures, against the benefits to be delivered by the project. This can only be done in conjunction with the various stakeholders. If it is done at the start of a project it might even lead to the conclusion that the project is not worth pursuing. If it is pursued then the risk plan enables a more accurate judgment to be made about the likely overall costs. A risk management plan makes you think about what it is you want to achieve, and what you are willing to pay for it. As a result you stand a far higher chance of achieving success.

Source

Rapid Application Development: MoSCoW Prioritisation

To be successful projects need to be properly prioritized for both the requirements and the main project objectives. One mechanism is to use a number system, but this is flawed as it results in all elements being number one. A more useful method is to use a set of words that have meaning such as the MoSCoW method. However to be effective prioritization requires hard choices to be made.

MoSCoW Prioritasation

MoSCoW Prioritasation

Prioritisation of Requirements

An important factor for the success of any project is ensuring that the requirements, are prioritised. In many cases this is not done leading to sure project failure. Sometimes it is the customers’ fault who want the entire system to be delivered now. Other times it is the project manager’s fault because they do not discuss the project with the customer. In either case prayers for miracles are often required if the project is to have any chance of being successful. In my experience miracles rarely happen on projects.

However prioritising is not an easy process, and even less so when done using a number system. The trouble with number systems is that it appears logically to give the features a priority of 1, 2, 3 etc. However who wants a requirement to be a “2” or even a “3”? As a result all requirements become a “1”, which is useless. This can lead to having to resort to additional systems such as giving “1*” and “1**” ratings to try to sort out what is really important. Even this is subject to prioritisation drift – upwards.

Even more damaging with number systems is that features that will not be developed this time are left off the list, and are ultimately lost. This means that designers and developers are unaware of these future needs, and therefore cannot select solutions which will make it easier to accommodate them at a later date.

So effective prioritisation is important but how can it be done if number systems are not effective?

MoSCoW

A more successful method is to prioritise requirements by using words that have meaning. Several schemes exist but a method popularised by the DSDM community is the acronym MoSCoW. This stands for:
M – MUST have this.
S – SHOULD have this if at all possible.
C – COULD have this if it does not effect anything else.
W – WON’T have this time but would like in the future.
The two lower case “o” are there just to make the acronym work. The importance of this method is that when prioritising the words mean something and can be used to discuss what is important.

The “Must” requirements are non-negotiable, if they are not delivered then the project is a failure, therefore it is in everybody’s interest to agree what can be delivered and will be useful. Nice to have features are classified in the other categories of “Should” and “Could.

“Must” requirements must form a coherent set. They cannot just be “cherry picked” from all the others. If they are then what happens is that by default all the other requirements automatically become “Must”, and the entire exercise is wasted.

Requirements marked as “Won’t” are potentially as important as the “Must” category. It is not immediately obvious why this is so, but it is one of the characteristics that makes MoSCoW such a powerful technique. Classifying something as “Won’t” acknowledges that it is important, but can be left for a future release. In fact a great deal of time might be spent in trying to produce a good “Won’t” list. This has three important effects:

  • Users do not have to fight to get something onto a requirements list.
  • In thinking about what will be required later, affects what is asked for now.
  • The designers seeing the future trend can produce solutions that can accommodate these requirements in a future release.
Prioritising the Project Objectives

When a set of requirements has been prioritised then it can be compared against the other planning aspects of project: scope, quality, timescale and resources, and a risk statement produced.

There is a general wish among managers to be able to decide when a project will be delivered, how much it will cost and what it will do. They then think they have removed all the degrees of freedom, and as they have made an assertion, reality will follow their thinking.

Reality will not, as they have left out two significant factors. The first is quality; it may be delivered on time but the quality is appalling. It does what the requirements say, but the system is not robust enough to be used by anybody, as one mistake will make it crash. The other factor is risk, which may be so sky high, that project failure has guaranteed before it starts.

One suggestion is to prioritise the four main factors of scope, quality, timescale and resources, and thus prioritise the key project objectives. Which of them “Must” be delivered, which has the maximum flexibility and is defined as “Could”, with the other two factors between these as “Should”. This means that at least one factor can be allowed to slip, and provide flexibility for setting a proper risk plan to ensure the essential factor is met. This is not losing control, it is acknowledging that building a piece of software is a trip into the unknown, and precautions need to be taken.

Implications of Prioritising the Project

Selecting the right prioritisation order of is not easy. Any choice that is made has tradeoffs.

If nearly all the requirements are prioritised as “Must”, then there is not much flexibility in the scope of a project. By definition the scope is the “Must” factor in the project and a decision has to be taken either about which of the others will have flexibility, or which of the requirements will be down graded from a “Must”.

However many studies have shown that it is better if a project is delivered on time, even if it has few features, than if a project is delivered late, but with a full set of features. This can be likened to saying when is the best time to deliver Christmas crackers to shops, before or after Christmas? Therefore timescale competes to be the most important factor.

If quality is sacrificed then faults will occur in the software. One way around this is to train the users in the use of a new system, so that they only use it in proper fashion, and know how to get around any bugs that are discovered. However if it is an Internet system intended to be used by customers, then this cannot be done, and a reputation damage to the organisation may result, due to a faulty system.

Finally all systems must be produced to a budget, and a business does not have unlimited resources to put into a project. Moreover the business case normally assumes a rate of return, which will be considerably reduced if the resources are increased significantly on a project. Therefore resources have a strong case for being the most important factor.

Regardless you cannot “have it all and have it now”, and a balanced and planned prioritisation of the factors must take place if a project is to have a chance of delivering business value. If it is not then the fifth factor of risk goes sky high, and ceases to be risk and become inevitable.

Source

DSDM: Technology Support

The need for technology support

The technology used to visualize what the developers are thinking and to gain feed-back from that visualization is the basis of much of agile development. However, it is not the total answer. The technology support for a controlled process does not lie solely in the easy generation of analysis and design models, screens, and code. If the process is to be controlled, then strong emphasis should also be placed on automated support for the necessary controls. Controls are an overhead on productive work, albeit a necessary one. Saving in effort can be made by automating the control of the status of, and access to, work products and in ensuring that they have been created correctly.

Agile developers would much rather spend their time creating the solution than controlling it. So it is the control activities that are likely to be squeezed out of their schedules when they are under pressure to deliver. Another area that does not enthrall developers is configuration management. However, configuration management is of the elements of an agile support environment where more things are being produced and changed at a faster rate than in traditional method. The need for support in this area is obviously fundamental. It should be easy for the developers to place their works under configuration management as soon as possible and as often as they should, without causing them to slow down in their development activities. Testing also looms large as something which developers see as a necessary evil, but which would be a much more productive activity with tool support. The list goes on.

DSDM Support Environments

DSDM has defined an agile tool ‘nirvana’. It is an environment which will support the whole process from feasibility to implementation (including aspects such as reverse engineering for legacy code) with all the necessary controls as automated as possible. It does not exist and it is unlikely that any one tool vendor will offer the fully integrated set. Indeed it is yet another cry for an IPSE (integrated project support environment), but one which is designed for SDSM projects. Such an environment requires integration at a number of levels:

  • presentation to provide a common ‘look and feel’ across all tools;
  • data so that all tools share the same repository;
  • control so that one tool can notify and/or initiate actions in other tools;
  • platform, in order to port the toolset from one platform to another

May be such an environment will exist in the future, but in the meantime we have to be more realistic and look for tools that will make savings in time and effort without being too costly. If we focus in the money side, several low-cost tools have been found to have a beneficial impact on effort. Low-cost tools for code and schema generation are available, as are tools for prototype generation. Both of these speed up development markedly compared with coding by hand. Another area where inexpensive tools can help is in the perennial headache of documentation. Automated support for creating documentation is readily available. Fortunately, many tools are self-documenting.

Testing Tools

One of the components of the DSDM support environment is testing tools. There are many varieties of testing tool available on the market and DSDM strongly advocates the use of tools in this area. Producing a tested system in a very short time can only be made easier with effective tools.

A very useful class of tools is capture and replay tools. These can lessen the need for documented test scripts. The quickest way to document tests is to record them as they are performed. A great deal of developer time can be saved through this route. Not only does this eliminate the need for producing ‘paper’ scripts before testing takes place, but the tests can be achieved as evidence of what tests have taken place. Capture and replay tools are also extremely beneficial in building up regression test suites which can be left to run overnight while the developers have a well-earned rest.

Static code analyzers can relieve the effort in code inspection and lessen the need for third-party verification that the code is to the required standard.

If the testing toolset is to be really complete, then dynamic analysis tools will perform tests in the background while demonstrations of a part of the software are taking place. Dynamic analysis includes checking array bounds and detecting memory leakage, etc.; things that should be tested, but which may be difficult to fit into the tight schedule of a project.

Configuration Management Tools

DSDM asks a lot of configuration management. Everything that is produced (analysis models, designs, data, software, tests, test result, etc.) should all be kept in step within another, so that is relatively easy to move back to a known ‘build’ state whenever the development has gone down a blind alley. This requirement means that automated support is essential and that the automated support should allow for many versions used, but this rarely the case. Anyway, given the diversity of products that are under development at any one time, it is probably asking too much to expect all the relevant tools being used in projects to be sufficiently integrated to have every product in step. This means that a specialist configuration management tool should definitely be on the shopping list of an organization that is planning to take DSDM seriously. The ability to baseline everything on a daily basis is the ideal. So the tool should not incur too much of an overhead is its use. There are several excellent configuration management tools available which will do the job perfectly satisfactorily if the procedures governing their use are firmly in place.

Effective Tool Usage

Although there are excellent tools in the market, any tool is inly good as its users. They should not be relied upon as the whole answer. The developers should be confident that they know how to use them properly and that the tools are an asset rather than otherwise. The purchase of a tool environment for agile development should think carefully before buying. It is possible in early DSDM projects to live with what you already have. Indeed it is probably preferable not to introduce too many new things at the same time. Once the developers are used to the process, they will soon see where tool support would be particularly beneficial in their working environment. If tool support is to be bought, the purchaser should read the chapter in the online manual that gives very strong guidance on the characteristics of tools for DSDM. Not least of these is usability. For some reason, software tools are often less usable than their counterparts in the business environment – maybe we just like to make thing hard for ourselves.

Source

  • DSDM Consortium edited by Jennifer Staplenton , 2003.DSDM. In Paul Bocij, Jennifer Staplenton. DSDM Business Focused Development. 2nd ed. The DSDM Consortium. .ISBN 0-321-11224-5

Sort Description:Nine (9) Principles of Dynamic Systems Development

Summary of Nine Principles of DSDM
  1. Active User Involvement is Imperative
    • DSDM – a user-centred approach
    • Active participation through lifecycle
  2. DSDM Teams must be Empowered to Make Decisions
    • DSDM team comprises developers and users
    • Decisions made as requirements refined or changed
    • No need for recourse to higher management
    • Rapid and informed decision-making
  3. The Focus is on Frequent Delivery of Products
    • Team produces agreed products throughout lifecycle
    • Team chooses best approach to achieve objectives
    • Ensures focus on delivery, not just activity
  4. Fitness for Business Purpose is the Essential Criterion for Acceptance of Deliverables
    • Build the right product before you build it right
    • Meeting business need is more important than technical perfection
  5. An Iterative and Incremental Approach is Necessary  to Converge on an Accurate Business Solution
    • DSDM allows solutions to emerge incrementally
    • Developers make full use of user feedback
    • Partial solutions can be delivered to meet immediate needs
  6. All Changes During Development are Reversible
    • All products should be in a known state at all times
    • It should be possible to step backwards, where an approach does not work
    • The team should be willing to embrace change and not be defensive
  7. Requirements are Baselined at a High Level
    • Freezing and agreeing purpose and scope of system
    • Baseline at a level which allows detailed investigation of requirements at a later stage
  8. Testing is Integrated Throughout the Lifecycle
    • Not a separate activity at the end
    • System is tested and reviewed incrementally by developers and users
    • Testing evolves as prototypes mature
    • Aim is to find and fix errors as early as possible
  9. A Collaborative and Co-operative Approach between all Stakeholders is Essential
    • Everyone working together as a team
    • Shared goal of achieving the business objectives
    • Give and take on all sides
    • Involves all parties, not just core team

Nine Principles of DSDM -Detail

Source

  • University of Greenwich,  London, UK

Nine (9) Principles of Dynamic Systems Development Method (DSDM)

Principle 1: Active user involvement is imperative.

DSDM’s strong focus on the business purpose of the system being developed requires that the ultimate users of the system be involved throughout the development project. This is because the system attributes that will make it fit for its purpose cannot be understood well enough in the project’s early stages to commit them to a detailed specification. Therefore, the only way to make appropriate detailed decisions and know that the evolving system is converging on the ideal of “fitness” is to fully involve the users throughout the project.

Principle 2: DSDM teams must be empowered to make decisions.

This principle does not give the team free reign to do whatever they wish. Rather, it advocates that the team be delegated the authority to make most of the day-to-day decisions as the project progresses. With active user involvement, such delegation can result in the team being able to move quickly and steadily toward system delivery. However, when a decision that must be made falls outside the team’s authority (e.g., cost overruns), DSDM recognizes the importance of raising such decisions to the appropriate authority.

Principle 3: The focus is on frequent delivery of products.

This principle means that the project’s progress should be measured by the production of tangible products, rather than by mere activity. The phrase “delivery of products” does not refer only to the incremental delivery of a working system to an end user. Products in this sense include any sort of work product that may be produced as the project moves forward (e.g., a specification, a throwaway prototype, a design document); and delivery could be simply within the project team. DSDM requires that as the project moves forward, it must produce artifacts that prove that progress is being made.

Principle 4: Fitness for business purpose is the essential criterion for acceptance of deliverables.

This principle is the practical manifestation of DSDM’s belief that specifying detailed requirements upfront is not helpful. By placing fitness for purpose above satisfaction of requirements, and by involving users consistently, DSDM zeroes in on the end user as the only one who can say whether or not the system as it is evolving is acceptable.

Principle 5: Iterative and incremental development is necessary to converge on an accurate business solution.

In an environment where it is assumed that the project’s end result cannot be foreseen in great detail, incremental development is the best insurance against the project going terribly awry. Incremental development is essentially an exercise in trial and error, where each new increment is presented to the user who validates (or invalidates) the direction the team has taken. “Converge” is the key word in the principle. It is assumed that the most direct path to the end product is not likely to be known, so DSDM engages in constant checking and correcting of the path to bring the project to a satisfactory end as quickly as is reasonably possible.

Principle 6: All changes during development are reversible.

If we agree that the project is practicing trial and error, then we must expect that there will indeed be errors from time to time. This principle gives us permission to discard erroneous work when necessary. Surely, we will try to salvage the good from a mistake, but we must recognize that there will be times when the most efficient path is to discard some work and try again.

Principle 7: Requirements are baselined at a high level.

The first three words of this principle, “Requirements are baselined,” represent a departure of DSDM from some other Agile methods. DSDM recognizes the importance to the project of stability in scope and direction. By baselining (freezing) the requirements at some level, stakeholders are establishing a stable basis for the team’s work. This does not mean that this baseline will not change; rather, it requires that serious deliberation precede any such change so that all stakeholders understand and agree to what would become the new requirements baseline. The last four words, “at a high level,” is the part of this principle that makes it agile. It leaves the details of what the requirements mean to be worked out between the team and user.

Principle 8: Testing is integrated throughout the life cycle.

Testing does not show up as a step in the DSDM life cycle because, like other Agile methods, DSDM promotes a strong quality-consciousness by all team members. Every task should include an appropriate verification or validation step like a review or test by a team member or user. This principle works together with principles 1, 4, and 5 to continually check the project’s progress toward its goal of a system fit for its business purpose.

Principle 9: A collaborative and cooperative approach between all stakeholders is essential.

This last principle is little more than the sum of the first eight. The only way that principles 1–8 can be applied successfully on a project is if all stakeholders accept DSDM and their roles as DSDM defines them. If any stakeholder does not agree (especially an influential stakeholder), then DSDM cannot work in that environment.

Nine Principles of DSDM -Lite Version

Source