I'm taking a breather from tribalism and this may be my last post for a couple of weeks. I'll be taking in the hanami season in Tokyo in the meantime. I won't be going online. I won't be taking my personal laptop with my blog content management system with me and I won't have a broadband connection to temp me to the dark side. I will return mid-April having restored my spirit after celebrating the beauty and fragility of life and how quickly it passes.

But before then...

There has been a lot of discussion in my Yahoo! group about paradigms. I've been pushing the idea that Agile Management is about applying a new paradigm of thought to managing software engineering projects. One reader and fan of my book actually sent me a summary of what he called the "Anderson way" against the established wisdom. It had 21 lines on it. That's a lot of paradigms to go breaking in a single blog post, so I thought I'd summarize what for me are the top five. These actually dropped off the top of my head in a meeting the other day when I was put on the spot to explain what it is I'm doing differently. So it's like second nature for me now. All of these are fully compatible with the Declaration of Interdependence and represent why the DoI is bringing project management guidance up-to-date with more recent management science thinking.

• Flow through value chain, focus on throughput and effectiveness - as opposed to, cost and effort estimating and tracking, cost accounting, efficiency and earned value analysis
• Theory of variation (common and special cause) and buffering - as opposed to, deterministic scheduling and Gantt charts and deviation from plan
• Synthesis and systems thinking - as opposed to, Cartesian decomposition, (bottom up rather than top down)
• Process control and continuous improvement - as opposed to, conformance to plan and specification
• Empowerment and service - as opposed to, command and control

I see this as the embodiment of modern late 20th Century management thinking applied to software engineering. These five paradigms represent the work of many but mostly Drucker, Porter, Goldratt, Deming and Weinberg whilst traditional established software engineering management and process guidance seems to be rooted in the ideas and concepts of Fayol, Taylor, Gantt, Sloan and Brown, and Crosby.

When you see this list, it underscores the magnitude of what we're all trying to achieve here. If you are out there trying to be an agile manager, it takes courage and bravery but stick with it. Attitudes will change given enough time. Unlearning is painful. It's a chemical process in the brain. Giving up a paradigm (or "mindset" - think about that "mind" and "set" - wiring in the brain) is painful. It's like the grief process. First there is denial. We're seeing some of that with the DoI. Next there is anger. We're seeing more of that with the DoI too. Then there is bargaining. We're seeing that too. In fact, the whole project management world is seeing it, as techniques get more and more complicated to try and compensate for their inadequacies. Bargaining is about trying to keep a grip of the incumbent paradigm whilst modifying it to accommodate new demands. [Viz - the risk management section of the new PMBOK]. Then there is depression - the "Gee, I'm not with it" feeling. And the "Oh no, I need to learn something new and I will be a novice at it" feeling. Finally, there is acceptance. The brain has been rewired. The chemical pain is gone. "Yes, this paradigm is better than the one I left behind." And the realization that a new paradigm is an opportunity - an opportunity to realize your potential - to get more out of life. On any given day, you may meet people in any one of these five states of mind, with respect to agile software development and management. That's why it is tough to walk the agile path and to go the whole way - not just development practices - but to rewire the whole organization, how it's managed, how it's organized, how people communicate and report progress.