My thoughts about the book ... If you don't have the book, get it. If you have the book and haven't read it, do so now.
"Why doesn't my manager listen when I explain the details?" "Why doesn't the developer just give me what I ask for?" These questions popped out during the Tutorial at this year's AYE Conference. Realizing the energy, Steve and I held an impromptu discussion on the topic.
Re-reading my blog titles occasionally leads to interesting thoughts. Many titles mention change, and most entries have something to do with change. But after all these entries no one has asked me, "Don, what do you mean 'change'?". Until recently, I haven't asked me either.
Engineers make the darndest assumptions. I made one such assumption in "Change and Stable Systems". The unstated assumption involved starting with a stable system. But what do you do if your system (as in team, project, company) is unstable?
Today I had the opportunity to remember that "context is everything".…
In Changing Quicker we looked at reducing or removing system delays to reduce the time delay between realizing a change needs to be made, and when the change's effects occur. Another way to change quicker involves learning to change. Learning is a process that depends on experience and leads to long term changes in behavior potential.
Will reorganizing every two weeks lead to stable software processes? What conditions would enable this to happen? When should we schedule the next change?
Several years ago I found out that I was not really in charge of everything, or in control of very much. This lead me to Don's Dismal Dilemma: How will I achieve my goals, when I'm not in charge or control?
"Change quotients" prompted one particular thought - since I'm usually the person recommending a change, I tend to be more sensitive to lower quotients than mine. Yet, I do recall one organization which had an intrinsic change quotient which apparently exceeded mine - they reorganized every two weeks, more or less. :)