For me, considering everything as a an API is one of the major forces which powers my agile development. Every class I create is designed to satisfy a particular need, driven by unit tests for its API and operation, with other code in the system acting as clients of its API.
This is agile in the sense that the code base consists of a collection of minimal, expressive, reliable pieces, each with clear responsibilities, which can be assembled and/or refactored in any way appropriate to the evolving needs of the business.
In the great majority of cases, the API provided by individual classes is not propagated to the exterior of an application, but it is there nonetheless. These internal APIs are continually policed by a growing body of developer tests and unit tests to make sure that they are always ready (and trustable) for reuse.
To me this approach also seems "lean" in the sense that no code is written unless it is justified by a failing test (which may be a recently added test for a missing feature), and in the way that duplication is mercilessly refactored away to eliminate waste of code and developer effort.
Did Bloch approach this from a different direction?
To strengthen Franks point, it is also my experience that test driven development helps focusing on the interface of a class.
I found the interview you are probably referring to at http://www.artima.com/intv/bloch.html (praise to google!). He mentions XP an the first and second page (didn't read the other pages, actually).
I don't think that doing Agile right leads to the "massive refactorings" he is speaking of. But in fact he says in the interview that he actually doesn't think that there is a big conflict between his API based approach and XP.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
leaving out the bells, whistles, and features you don't need and add them later, if a real need is demonstrated. And that's incredibly important,
In our book we suggest that the biggest waste of software development is adding features that are not needed now.
Bloch also says:
you'll have less work to do if you design the intermodular boundaries carefully to begin with.
We recommend that a high level systems design (or architecture) is the starting point for a brilliant product design. There is a delicate balance between too much detail and the right initial systems vision. Experts in any domain will know the difference. I don't think there is any process that can substitute for such expertise.
Author of Lean Software Development, Implementing Lean Software Development, and Leading Lean Software Development