Loosely coupled movement
Let me share my thoughts. From the SOLID perspective your example is very simple and does not explicitly break any principles.

The only thing that you should not do in large-scale production code is to couple your application code (MovementManager, etc.) with execution host (Console app project). 

What you should usually do is to put your application code into separate assembly(ies), employ some DI Container and create a Composition Root (also preferable in separate assembly). Application code/assemblies must not have any references to DI Container or Composition Root. On the other side, your execution host (Console App project) must reference Composition Root and Application Code assemblies, and resolve an instance of MovementManagerFactory via DI Container. Then you can use MovementManagerFactory to create your MovementManager with appropriate iMovement object.

You would need MovementManagerFactory because your MovementManager constructor requires iMovement object. To simplify things I'd rather remove that constructor and instead pass iMovement object to the Move() method directly:

public class MovementManager
{
    public void Move(iMovement movement)
    {
        movement.Move();
    }
}


As a side note: everywhere in your application when you use new operator to create an instance of a class, you potentially make your code tightly coupled. It is especially true when that 'new-ed' class belongs to another module or component. 

Dependency Injection in .NET by Mark Seemann is an excellent book about design of loosely coupled application.