Doctrine

doc·trine noun \ˈdäk-trən\
2
b : a principle or position or the body of principles in a branch of knowledge or system of belief

Merriam-Webster

There is a set of principles and ideas that constitute the foundation of my understandning and view of system development. I hold these ideas for truths as I think there are good reasons for that position.

I think the most central idea in Agile is that we should trust humans - no system or process, no matter how well designed, beats the power of humans that cooperate.

I fully agree with Domain Driven Design that a strict and common understanding of the problem at hand is critical to success in the vast majority of development initiatives. The shared understanding should be used in the form of a Ubiquitous Language.

I believe that internal drive is more powerful that external motivators. I think Daniel Pink's "autonomy, mastery, and purpose" makes an excellent model for reasoning about this.

I consider the way Lean focus on "finishing, not starting, gives value" extremely valuable. Limiting work in progress and reducing waste become natural conclusions from this.

I embrace System Thinking and how it stresses each part's role in the larger scale as more important and interesting than the part itself.

I am deeply fond of the Scientific Method how it insists on observable facts as the basis for knowledge.

There are many things that form my thinking and my principles for reasoning. Those mentioned above are among the most central. If you want to understand how I think, this is where I start. To a large extent, these ideas form my personal doctrine for system development.