Alistair Cockburn spearheaded the derivation of this declaration along with a number of signatories (including Lowell Lindstrom, who both of us know; there's my name-dropping for the day). At one point these were principles for project managers only, and targeted at agile teams. But the declaration authors realized that the final set of principles had much broader applicability--hence the use of the term "modern management."
Similar to the agile manifesto, the declaration of interdependence for modern management sounds to me like motherhood and apple pie. Of course we want to increase ROI, be creative, and deliver reliable results! Let's see if we can figure out what each principle is really saying.
Increase return on investment by making continuous flow of value our focus - This directly corresponds to lean production: we look to produce small, complete features with high quality before moving on to the next. Phased approaches such as waterfall certainly go against this principle, as do purely iterative approaches that do not insist on useful incremental deliveries.
Deliver reliable results by engaging customers in frequent interactions and shared ownership - On far too many projects, the customer coughs up some needs, and then the development team disappears, reappearing much later with some completed or partially completed product. The customer has no ownership of the process or even of the priorities for feature development. There is no definition of "frequent" for this principle, but if you are following along with the first principle--continuous flow of small bits of value--frequent would seem to be almost as often as each new feature was introduced to the development team. Specifically: at least once per iteration, and hopefully more often.
Expect uncertainty and manage for it through iterations, anticipation and adaptation - There is a balance between planning (anticipating) and reacting (adapting). This principle absolutely suggests that we would never want to plan an entire project at the outset of a project, and then set that plan in stone. But it also suggests that we should look to continually anticipate upcoming events. With this principle, the declaration authors felt it was important to tell the agile community to heed information about anticipated events, i.e. not to always wait and react.
Unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference - Many in upper management already think they do this, but ask any developer to honestly assess the way they feel about how they are treated. How many of you developers on agile teams have had management tell you that you weren't allowed to write tests, or refactor the code, because those were just things that were keeping us from shipping the software?
How many times have you heard someone in management say: "And finally, we'll make sure we have fun on this project!" Period. Their idea of creating a fun environment is to declare that people "vill haff fun!"
Boost performance through group accountability for results and shared responsibility for team effectiveness - Even for many teams trying to be agile, the typical implementation is silo-mode development. BAs hand off requirements to developers, who hand off product to QA. Each one of these can think they did a good job, and be rewarded by managers for such, yet we still end up failing miserably. I've blogged numerous times about how it all leads back to principle #1: delivering a quality story at a time as a team before moving on to the next.
Improve effectiveness and reliability through situationally specific strategies, processes and practices - Pragmatism and adaptability. Sticking with pairing, for example, when the culture or physical environment has already proven to not support it.
I've read a good number of books on management and have attended training such as Covey's Seven Habits. What always strikes me is that the material presented always seems so obvious to me--almost a waste of time. There is the Catch-22: Those who are interested enough to grow themselves in management already know the principles behind the training or books. Those who don't know it aren't the kind who will want to be bothered with attending classes or reading a book.