“In general we look for a new law by the following process. First we guess it. Then we compute the consequences of the guess to see what would be implied if this law that we guessed is right. Then we compare the result of the computation to nature, with experiment or experience, compare it directly with observation, to see if it works. If it disagrees with experiment it is wrong. In that simple statement is the key to science. It does not make any difference how beautiful your guess is. It does not make any difference how smart you are, who made the guess, or what his name is—if it disagrees with experiment it is wrong. That is all there is to it.” -- Richard P. Feynman, Nobel Prize-winning physicist, in “The Character of Physical Law”

Software development has always been the red-headed stepchild of engineering and the sciences. Software engineers are not like other engineers. When civil engineers sit for their exams, they bring well-vetted reference works with them to solve problems. These references exist because the properties of materials, and the ways that materials are combined, are well-understood. A straight design-build-test development path can work well for building a bridge.

On the other hand, software developers build solutions through the organization and use of data and domain-knowledge. While they may use established technologies and techniques such as design patterns, software developers are dealing with information – a material that is not well-understood.

Instead of engineering, software developers and stakeholders can look to science for the answer.

Very simplified, the steps of the scientific method are as Feynman outlines them in the quote above:

  1. Find a problem.
  2. Guess an answer.
  3. Check the guess by performing an experiment and collecting data.
  4. Analyze the data to prove the guess right or wrong.
  5. Repeat.

Don’t be fooled by the simplicity. The scientific method is one of the most powerful tools we have to solve problems.

When we design and build a software product using science, we can either build it in one big expensive experiment or in a series of small inexpensive experiments.

The waterfall method of software development treats a software product as one big expensive experiment. In the waterfall method of software development, first we try to understand all of the stakeholders’ requirements in a single big theory; then we design software to meet those requirements; then we implement the software; then we test it; and then we release it in a single big experiment. But, as Thomas Huxley said, “Science is organized common sense where many a beautiful theory was killed by an ugly fact.” We want the costs of those ugly facts to be minimal.

Scrum is a software development process that uses the scientific method in a series of small, inexpensive experiments.

The basic unit of a Scrum project is a sprint which lasts between a week and a month.

A sprint has the following steps:

  1. Add to a list of requirements for a product. This is called the “product backlog.” (Find a problem.)
  2. Decide what work items can be done in the sprint. This is called the “sprint backlog.” (Guess an answer.)
  3. Implement the work items in the backlog and present the completed work to the product owners. (Check the guess by experiment.)
  4. Review the work that was completed and not completed. (Analyze the data.)
  5. Repeat.

A sprint is a scientific experiment that is in a cycle of continuous data collection and evaluation. There is nothing hidden from the product owners (stakeholders) and nothing taken on faith. In Dr. Feyman’s words, “If it disagrees with experiment it is wrong.”

At the end of a sprint, there is actual concrete work done that the product owners can evaluate and give concrete feedback to the developers. The product requirements may change. Previous work items may be deemed to be incomplete or incorrect so new requirements are added to the product backlog. And then a new sprint begins.

Each work item within a sprint also parallels the scientific method:

  1. Create a requirement. This is often in the form of a fill-in-the-blank story: “As a {user} I want {do something} so that {I get a desired result}.” (Find a problem.)
  2. Design the work item. (Guess an answer.)
  3. Implement the work item. (Check the guess by experiment.)
  4. Review the work item against the “Definition of Done.” (Analyze the data.)
  5. Repeat.

Scrum is a simple yet very effective way of using structured thinking to build solutions through the scientific organization and use of data and domain-knowledge. Scrum acknowledges the simple fact that at the beginning of projects, software developers and product owners usually do not completely understand the problem that they are solving. However, through continuous experimentation and analysis, the problem is not only understood, but also solved at the same time. Many small bets add up to one big success.

Leave a Reply