Ken suggests the following as requirements for sustaining change:
- Make a Public Committment - to one or more people other than yourself
- Make sure there is Accountability - the one or more persons you make a committment with, schedule a date/time to check back with you on progress.
I think using these requirements works incredibly well on an individual level, and to a lesser extent on a group level (i.e.- timeboxed iterations, sprints). That said, it's better to have something (committment wise) on a group level rather than nothing!
Also useful to consider here is the concept of fishbowl management -- that is to say: Put all your leaders in a fishbowl and begin measuring them to the same, publicly visible standards. You then reward and punish [demote] based on people's performance relative to those standards.
I also pulled out some names for behaviors I've seen before including the "organizationally addictive hero-matyr pendulum" and the well-named game of "Schedule Chicken".
"Schedule Chicken" is when everyone around the table knows the project will slip or that some piece of functionality can't be done in the necessary amount of time, but nobody is willing to say anything . . . the first one to say something loses the game, but in the end everybody is relieved when it's out in the open (unless there's someone at the table who wasn't playing).
On a side note, I found a podcast interview with Dileep George on some of his work constructing software to emulate the neocortex.
Dileep's homepage of interesting stuff: http://www.stanford.edu/~dil/invariance/
If he and Hawkins can pull this off, it will certainly be the beginnning of a revolution in what types of problems we can solve with software.
Lastly, Valtech TV has posted some interesting presentations. I just watched "The Great metrics Debate with John and Amr - Part 1" (Part 2), and found it to be a well thought out illustration of good and bad points to various metrics we tend to push in Agile and what to watch out for when using those metrics.