Empirical isn’t a word that is in general use. It is derived from the Greek word for experience and means “based on experience,” or “based on observation.” In Agile what we try to do is modify what we do and how we do it based on experience. Some discussions of empiricism talk about it having three pillars, transparency, inspection and adaptation. We look at the world (inspection that requires transparency), and we change (adapt) what we do and how we do it based on experience.
This might seen obvious, but it runs counter to one of the main streams of thought in project management: the idea that successful project management is about delivering on a detailed plan. Often the most heated and emotional disputes in Agile software development arise from the application of Empirical process. Because at certain points in the process the gap between the “theoretical” status of a project and the actual, “empirically observable” status of the project can be huge.
Those plans, and the overarching ideas and visions that they claim to deliver are in a lot of situations much more compelling and attractive than messy, expensive, difficult to understand reality. But in a very important way, those plans are just marks on paper and ideas in people’s minds. They are dreams. They do not actually exist.
Agile approaches to software development use empirical process to focus on what does exist and what can and can’t be done. They do this by eliciting feedback, early and often and by focusing on delivering working software. Working software actually exists. It can be observed. But what’s more, only working software can deliver value. Even so, often the most heated and emotional disputes in Agile software development arise from the application of Empirical process.