Some background for those who don't already know of Phil's work and his recurring column in CACM: One of the main premises of the book is that software is not a "product" in the usual production-oriented sense of the word, but that software is really a medium for capturing executable knowledge. He then uses this to derive that software is therefore not a product-producing activity but rather a knowledge creating and knowledge acquiring activity.
He then talks a little bit about the "Five orders of ignorance" and how, if software development is a knowledge acquiring activity, then it is also ultimately an "ignorance reduction" activity whereby we progressively reduce our ignorance of what the system is, what it needs to do, how it needs to do it, and how we need to do it and manage it.
Anyway - there is a lot more other GREAT stuff in the book (including the actual laws of software process as promised by the title of the book), but that should be enough background for the sections I'm about to summarize below...
Pages 97-159 are devoted to Agility and Agile methods. Chapter 6 is entitled "The Advent of Agile" and Chapter 7 discusses "Agile and the Orders of Ignorance" in detail. The sections and subsections for Chapter 6 are:
> It Has Always Been Agile
> -- Test Phases with Embedded Lifecycles and Test Phases
> -- The "Construct" Phases also have Feedback
> -- The Feedback Activities Generate Feedback Activities
> The Problems of "Big" Process
> Agile Methods
> -- Change is Expected
> -- Feedback is Managed
> -- Stepwise Development
> -- Human Factors
> -- Customer-Centric
> -- Agile is Event-Driven
> Extreme Programming (XP)
> Code Science
> Crystal Methods
> Scrum
> Dynamic Systems Development Method (DSDM)
> Feature-Driven Development (FDD)
> Lean Development
> Adaptive Software Development (ASD)
> Why Agile? Why Now?
The section "Agile is Event-Driven" looked interesting to me because I am accustomed to hearing agile described as feature-driven. So I took a further look and it was indeed interesting to read:
> "The primary characteristic of Agile lifecycle models is that they tend to be more event-driven than the product-production or manufacturing-influenced models. More correctly, they are driven more by what is actually learned than by what is expected to be learned. Agile projects are more responsive to what is really happening than by what was expected to happen....
> "On Agile projects, the work being done at any point in time is a function of what has been learned through the project up until that point in time. This does include the starting points of the expected plan, early contracted deliverables, and probable design approach. But it also includes the reaction to changes in the expected plan, marketplace or customer-driven modifications to the requirements, the evolution of different design alternatives, and the ever-unfolding and continuous acquisition of knowledge that comes from building a system....
> "The fact that older lifecycle management models are not sufficiently agile is one of the biggest causes of grief and failed expectations in software development. When we use models and mindsets that are rigid and deterministic to manage an activity that is fluid and variable, it is not surprising that people get disappointed."
The rephrasing of the principles (not values, but principles) of the agile manifesto as Phil describes them is also very interesting to me:
> INTRINSIC VARIABILITY:
> -- Things will change, deal with it.
> LIMITS OF PRECOGNITION:
> -- We cannot know everything in advance.
> CONSTRUCTIVE FEEDFORWARD:
> -- The act of trying to build something has the potential for changing key characteristics of what we are trying to build.
> CONTEXTUAL POSITIONING:
> -- Sometimes we need to acquire some knowledge to know what other knowledge we need to acquire.
> CONSTRUCTIVE POSITIONING:
> -- Sometimes we need to build things in order to find out how to build things.
> PERSPECTIVE BLINDNESS:
> -- One person looking at a problem cannot see what he or she cannot see.
> EXECUTABLE VALIDITY:
> -- Until we have made knowledge execute, we cannot assert that we have developed executable knowledge.
> KNOWLEDGE DISCOVERY IS ANTHROPOMORPHIC:
> -- The discovery of knowledge is a human activity that is primarily a function of the collective human thought processes and human understanding
> KNOWLEDGE DISCOVERY IS A FUNCTION OF OUR STATE OF MIND:
> -- It is compromised by people being tired, dispirited, and demotivated.
> KNOWLEDGE IS UNDIVIDABLE:
> -- Large collections of related knowledge /cannot/ be fully understood by breaking them into pieces and parceling them out to different people.
> KNOWLEDGE IRRUPTION:
> -- We can only expose knowledge in an environment that that contains the knowledge
> KNOWLEDGE COMPARISONS:
> -- The only way to assert validity of knowledge is to compare against another source of knowledge
> CUSTOMER ARBITRATION:
> -- The only and final arbiter of whether the executable knowledge is useful and valuable in allowing the customer to more effectively operate in the customer's environment is the customer executing that knowledge in the customer's environment.
> KNOWLEDGE STRUCTURE INTEGRITY:
> -- It is necessary to maintain the structural integrity of the knowledge representation as new knowledge is discovered.
> OCCAM'S DESIGN RAZOR:
> -- The simplest design that suffices to provide value to the customer is the best design to use.
What can I say? I like this guy! :-)
