Dynamic languages are theoretically at a disadvantage, all else being equal, because they specify less about how the code works (what the constraints are), and therefore less of the refactoring can be done automatically, and problems that arise cannot be detected automatically as well.

But all else is not equal. The most popular dynamic languages allow for highly compact yet comprehensible code, which generally makes development in them faster, and makes the logic (which may change in refactoring) easier to spot visually. So though you might lose some of the relative advantage of working in a dynamic language, you might still come out ahead, especially if you were planning on doing your refactoring by hand anyway.

On the other hand, there exist statically typed languages with essentially the same advantages as dynamic languages (i.e. compact and comprehensible–with types mostly inferred, but very much there): Haskell is perhaps the leading example, but OCaML/F#, Scala, and others are in this category also. Unfortunately, since they are less heavily used than the most popular statically typed languages, they don’t have as extensive of toolsets for them (e.g. for refactoring).

So, as a bottom line, I think you’ll do adequately with agile methodologies in most languages; I wouldn’t say there’s a clear winner right now as practice has not yet caught up with theory.

Automated refactoring was invented in Smalltalk, a dynamically typed language. So no, its not impossible to have automated refactoring in a dynamically typed language. How hard it is depends far more on other factors besides the typing discipline. C++ and Java are both statically typed, but refactoring tools only really exist for Java. Smalltalk with its introspection and simple syntax was a really good candidate for refactoring tools.

In some ways, dynamic typing actually makes refactoring easier. If you have a good testing suite, you can be sure your refactorings haven’t broken anythings. A dynamically typed code base is typically smaller. Additionally, refactorings tend to affect less code. Altogether the effort involved in manually refactoring a dynamic code base is less then that of a static code base.

Refactoring was invented in dynamic languages. Automated Refactoring Tools were invented in dynamic languages. IDEs were invented in dynamic languages. Several Agile Methodologies were invented in dynamic languages.

I really don’t see any problem.

Lest we forget, the “Agile” way of working which became known as Extreme Programming (XP) was created on a Smalltalk project (and Smalltalk certainly counts as a “dynamic” language).

Here’s a case study of industrial use of a refactoring tool provided with a dynamically typed language:

A very large Smalltalk application was developed at Cargill to support
the operation of grain elevators and the associated commodity trading
activities. The Smalltalk client application has 385 windows and over
5,000 classes. About 2,000 classes in this application interacted with
an early (circa 1993) data access framework. The framework dynamically
performed a mapping of object attributes to data table columns.

Analysis showed that although dynamic look up consumed 40% of the
client execution time, it was unnecessary.

A new data layer interface
was developed that required the business class to provide the object
attribute to column mapping in an explicitly coded method. Testing
showed that this interface was orders of magnitude faster. The issue
was how to change the 2,100 business class users of the data layer.

A
large application under development cannot freeze code while a
transformation of an interface is constructed and tested. We had to
construct and test the transformations in a parallel branch of the
code repository from the main development stream. When the
transformation was fully tested, then it was applied to the main code
stream in a single operation.

Less than 35 bugs were found in the
17,100 changes. All of the bugs were quickly resolved in a three-week
period.

If the changes were done manually we estimate that it would
have taken 8,500 hours, compared with 235 hours to develop the
transformation rules.

The task was completed in 3% of the expected
time by using Rewrite Rules. This is an improvement by a factor of 36.

from “Transformation of an application data layer” Will Loew-Blosser OOPSLA 2002

Also — “Tools for making impossible changes – experiences with a tool for transforming large Smalltalk programs”

Your principles thought sounds to me correct.

The strongly-typed languages like C# are good candidates for a code base that constantly needs re-factoring. Basically most re-factoring tools (like Resharper, JustCode, etc..) in the market are very effective in statically typed programming languages.

What does real world projects tell about usage of dynamically typed languages for agile methodology?

For development team that practices Agile/Scrum methodology it is very helpful (even critical) to have good set of re-factoring tools under armor. Otherwise, all sudden changes in upcoming sprint may be a nightmare to be modify or re-design.

Thus, agile methodology does not provide advantages to statically typed languages or dynamic once. What it provide is an iterative approach to build a solid application.