Is Scrum empirical? Sort of, but mostly your usage of it is not!

Key Takeaways otherwise known as TL:DR

1. There are no pillars of empiricism.
2. Scrum invented/created their own empirical model.
3. Scrum is empirical, but most usage of it is not.
4. True empiricism is inductive reasoning.
5. Creating products requires Deductive, Inductive and Abductive reasoning.
6. Most Scrum and Agile is Determinate Cumulative Iteration and not Inductive.

Let me start by saying that Scrum has an empirical design model at its heart, but the use of Scrum is mostly not empirical. To understand this, we have to go back in time a little.

1.?????Inductive Reasoning?

The year is 1620 and Sir Francis Bacon is publishing his completed work known as Novum Organum. Bacon’s work was the birth of Inductive Reasoning, or Empiricism.

“Called the father of empiricism, Sir Francis Bacon is credited with establishing and popularizing the “scientific method” of inquiry into natural phenomena. In stark contrast to deductive reasoning, which had dominated science since the days of Aristotle, Bacon introduced inductive methodology—testing and refining hypotheses by observing, measuring, and experimenting.?

An Aristotelian might logically deduce that water is necessary for life by arguing that its lack causes death. Aren’t deserts arid and lifeless? But that is really an educated guess, limited to the subjective experience of the observer and not based on any objective facts gathered about the observed.?

A Baconian would want to test the hypothesis by experimenting with water deprivation under different conditions, using various forms of life. The results of those experiments would lead to more exacting, and illuminating, conclusions about life’s dependency on water”. Source: Princeton University.

Now this line is crucial to the debate this article will doubtless cause.?“testing and refining?hypotheses?by observing, measuring, and experimenting”.

Does your application of Scrum do this? Or does it more or less iteratively do work? There is a difference.

Hypotheses – noun, a supposition or proposed explanation made on the basis of limited evidence as a starting point for further investigation. In philosophy, a proposition made as a basis for reasoning, without any assumption of its truth. Similar words are theory, supposition and so on.

We could write an entire paper, and some have, on the definition of hypothesis and hypotheses and their meanings. I will stop at this point as we sort of get the idea.

2.?????Empirical Process Control and The Pillars of Empiricism?

A little bit more history is needed as we explore this topic. The above items are all a creation of Scrum. They are in the words of Ken Schwaber “our own invention”.

Before you all go outright hater on me, I spoke to Ken about this issue over email and he was tremendously magnanimous in his responses. I think Ken is a great intellect and I hold him in high regard, so this article is not a ‘Get Scrum’ or ‘Get Jeff and Ken’ article, it is about understanding the facts, as well as the application of the tool. Yes, it’s a tool.

Scrum is actually a great tool and has great utility if used in an appropriate context, and used as designed. It is not the Holy Grail and it isn’t a panacea either!

So, where did all this come from then?

Process Dynamics, Modeling, and Control, a 1994 textbook from Oxford University Press is a scholarly and theoretical modeling book.?The author Babatunde A. (“Tunde”) Ogunnaike worked at Dupont and was a chemical and mathematical theoretical modeling expert.?

As Ken says in his reply to me “Tunde is now dean of the engineering school at University of Delaware. He has published new version of the Process Dynamics book which identify the rapidly increasing complexity of our world. He asserts that statistics is a way of thinking that must be second nature because predictive thinking often gets in the way of correctly apprehending a situation”.

Tunde created Empirical Process Modeling as part of his theories on process control which is a statistical model. Trust me, the maths in the book are mind warping.

This image is from the original book on page 416 and is the model Tunde proposed at that time. I have not seen the later book Ken refers to and I was unable to find it online.

Ken does say “The book is a graduate school text book (sic) for process control. One chapter at a time”. At almost 1300 pages I would agree!

It is chapter 13 that goes into this empirical approach, and the whole book is steeped in chemical and statistical formula way beyond the brain of this commentator.

I postulated to Ken that “it seems clear that you developed your own model based on inputs and knowledge from DuPont and the work of Tunde Ogunnaike et al, and over the years the ‘Agile Press’ has assumed it to be the basis for all empiricism”.?

Ken “The Scrum model is a clean implementation of empiricism and is well described in Tunde's books. Not by name, but by framework. We have given its teams, events, and artifacts definitions within Scrum so as to make the empiricism work”.?

I told Ken that "I have no issues at all with Scrum having an interpretation or its own model, I just want to be clear that this is not the historical and established scientific texts, it is a model that is used in Scrum, created by Scrum, and useful in Scrum, and perhaps other contexts".?I am a PST after all so want to teach the facts.

Ken “Yes, correct. It is a derivation of a steam pressure chamber or any other chaotic chemical or biological process. The roots are the same: transparency, inspection, adaptation ... then again.

The use of empiricism for software development was an epiphany. Tunde described it to me and reviewed what I was doing. However, Scrum is our own invention.”?

I bet you didn’t know anything about steam pressure chambers until you read that! I know I didn’t!

On those pillars of empiricism??

Ken?"yes, I formulated/invented it based on Empirical?Process control. Scrum is consonant with empirical process control."??Consonant: Noun, in agreement or harmony with.

Dave West (Ken's CEO of Scrum dot Org), someone I like to call a mate (he is a Brit after all) added this to the email between the three of us, but directed at Ken.?“If you did invent this model this is amazing and a foundation to ALL agile thinking and process :-) Or as they say in Boston you are 'wicked smart'”.

Ken is indeed very smart! Dave and I both learned something as Ken explained the history to us.

So, to wrap up the history, Empirical Process Control comes from, as best I can discern, the work of Tunde et al, and was adopted or so named by Ken when he and Jeff where creating Scrum.?

The pillars were a Scrum invention, originally known as Visibility Inspection Adaptation [2004 Beedle and Schwaber] and later changed to Transparency Inspection Adaptation. The foundation of Trust in the picture above is something Scrum Org like to add as we do need a strong foundation of trust to use an empirical model/approach.

So, let me be very very clear. I am not accusing Ken of propaganda (the illusion of truth)!?He never set out to deceive anyone,?--> we did that ourselves <--. Just Google 'Pillars of Empiricism' and see for yourself. All Ken did was seek to create a process he believed in and hoped would help in complex product development. For many of us he succeeded.

Is Scrum based on empiricism? Yes.

Is it an empirical model? Well that depends on how you apply it, so read on…

3.?????Induction, Deduction, Abduction, Iteration, Accumulation and Exaptation.

Is how we are using Scrum really inductive, or is it simply iterative and cumulative with some deductive behaviors?

Remember, Induction is “testing and refining hypotheses by observing, measuring, and experimenting”.

User stories and their like are not hypotheses they are determinative. As a customer I want some specific thing so that I can get some perceived value. I know this is done when (insert list of acceptance criteria). We have already determined the outcome desired.

The whole feedback thing at Sprint Review is more confirmation of this and at best some emergent learning. That is, we discovered something by chance, or the customer suddenly thought of a new idea or realized they didn’t need X or Y after all.

The latter rarely happens anyway as Sprint Reviews are rarely with the actual customer, with many being a ‘ceremonial presentation’ to the Product Owner or person in a similar representative role. If you have a real customer every sprint you are doing awesomely.

User Stories and most PBI’s are NOT experiments or hypotheses. They are a clearly articulated requirement. The way we achieve them may be experimental or exploratory but calling that empirical is a bit of a stretch. That is, the developer if we’re talking software, is figuring out how to code some feature or function, and they may do some rapid prototyping or small experiments, but that means some, not all, of the development process may have elements of empiricism.?

As a homeowner I want my grass cut so that it looks nice. The contractor knows my determined outcome (and I could write some silly A/C) but he/she has a pretty good idea how to achieve it. They may run into a snake, or a rock, or the mower may break down, but solving all that is emergent not empirical. The grass being cut is known and not a hypothesis to be proven through experimentation. If you asked for topiary on a bush then that might be empirical ??

The only true experiments are perhaps technical spikes (research items) or true R&D where we do not know what we’ll find until we find it. We have an idea (hypothesis) and we create/design an experiment to test our hypothesis, and we reach a conclusion that is currently indeterminate. In simple language, we don’t what we know, until we know it. Or is it we don’t know what we don’t know until we know it. Anyway I digress.

Deduction, as opposed to induction, is used in 5 why analysis in the ordered world. We ask questions and respond with because. Why did x happen, because y. Each answer is a fact-based answer. For much more on deduction read Sir Arthur Conan Doyle’s books.

We deduce the root cause asking sufficient questions and gaining factual answers. We may use an experiment to determine a fact so we could be inductive to elucidate something unknown, but this to be honest, is not that common. Most things are known, maybe just not to the inquirer at the time. Just because you lack knowledge does not make its discovery empirical, and in fact it might make it wasteful finding out, so better to use other’s research and find out if someone else has already solved the problem.

A tip from my Toyota days.?To test your 5 why analysis is valid use ‘therefore’ as a qualifier. Go backwards in your 5 why and after each statement say ‘therefore’ x or y. See this slide I made years ago. Asking why uses ‘because’ and confirming why uses ‘therefore’. The following slide should help.

Experiments may take place in an idea’s session, or perhaps trigger experiments as ideas are thought of. For instance, what products can we now sell to survive Covid. Let’s do some testing to find out. Run some experiments where we cannot determine the outcome in advance, but where we want to discover something or test a theory. Then we quickly shift into determinate outcome based iterative delivery mode.

Just because something is discovered as we work does not make it empirical. Emergence and Empiricism are different. Emergent means coming into being. If we learn something by doing something else that’s emergent. If we define a hypothesis and then run an experiment to test it, that’s induction (empirical). Accidentally discovered outcomes are emergent. Exaptation is then possible if we discovered something by accident.?

Exaptation?is a term used in evolutionary biology to describe a trait that has been co-opted for a use other than the one for which natural selection has built it. In our modern world we think of it as repurposing for something it was never originally intended for, (microwave cooking from radar, or Post It Note glue from a failed adhesive).

For completeness let’s describe?Abductive Reasoning, which basically involves forming a conclusion from the information that?[is]?known.

Example of abduction from Google:?You conclude, as a juror on your first day as a member of the jury, that he is guilty, but you are not certain. Here, you have made a decision based on your observations, but you are not certain it is the right decision. Daily decision-making is also an?example?of?abductive reasoning.

Another example below - When it rains, the grass gets wet. The grass is wet. It must have rained.

Abductive reasoning is useful for forming hypotheses to be tested.?Also known as the logic of the maybe.?

So, you abduct, induct, and deduct. As a result, you may have emergence and exaptation.

I will add that if you are writing software this is a combination of knowing what to do (comprehension), how to do it (skills), testing ideas (induction), and problem solving (deduction).

If you know what you want but are not sure how to do it and try stuff to get there, then that’s an empirical approach. Finding a cure/vaccine for CV19 is definitely using an empirical approach, but also deduction and abduction and exaptation.?We need all of these. You do too.

4.?????Determinate Cumulative Iteration

Empiricism is not responding to customer feedback based on determinate backlog items, that’s iteration. Empiricism is experimenting with theories and unknown outcomes to see what happens and decide what to do next. Most outcomes in projects are both planned, predictable and expected. Problems and unforeseen things happen, and that’s called emergence, or if you prefer emergent learning.

The majority of work I have seen where Scrum is being used fits the above description of determinate cumulative iteration. That is, you deliver a list of understood requirements in an iterative manner which is cumulative. As work is completed we create an accumulation of work, hopefully valuable work.

• You know what you have to do based on what someone wants.
• You have decided what tools and methods you are going to use to deliver that.?
• You break the work up into small chunks and deliver pieces in short durations.?
• You get feedback and tweak those pieces based on that feedback.?
• You are iterating reasonably clear requirements.?

In fact, most changes in Scrum are caused by poorly articulated requirements, or the fact we built something that didn’t work properly. The latter is often due to poor testing, or a lack of understanding of the requirements. Yes, poor skills too, but that’s a different problem.

Where there is no idea how to ‘do’ something you run some experiments to figure it out. Those experiments are empirical. Rarely are user requirements empirical.

As a customer I have a vague idea about something, which is completely untested or unproven, so please go do some experiments and I’ll hone in on what I actually want based on the results. Honestly?

The search for a Covid vaccine is clearly stated, but no one has any idea when it will be found, how they will create it, if it can be created, and if it will work. The only acceptance criteria we have is, it works, and does so safely. We therefore have a clear hypothesis and a desired outcome, but no clear way to get there. That’s why empiricism is at the heart of the Modern Scientific Method.

5.?????So all we are doing is Scrumafall or H20 Scrum or WAgile?

No, not really as the key difference is in Scrum we seek to deliver completed pieces of work each Sprint. In fact, the Scrum Guide says,?“The increment must be in useable condition regardless of whether the Product Owner decides to release it”.

Traditional waterfall projects work in completed phases, not completed features, functions or capabilities. Nothing is releasable until the end. That’s Scrum’s, or rather Agile’s key differentiator. Nothing really to do with being empirical.

Final Thoughts

While it is based on empirical theories and inductive reasoning thereby enabling truly empirical work to be accomplished, Scrum for the most part, has become iterative and cumulative. That is not Scrum’s fault. It does fully support empirical working, however it is our fault for not wanting to use it, or being able to use it in that way.

The problem is most organizations cannot or will not use it empirically, and is has become an iterative and cumulative approach, at worst like mini 2 week long waterfall projects, or in some circles 3 month long projects! Most work is user requirements chunked into short deliveries. They are not experiments with undefined or indeterminate outcomes.

This gets worse if teams are separated by skill, so work is ‘handed off’ from team to team, a characteristic of a waterfall approach.

Scrum works, but most companies are not actually using Scrum, they just say they are. You could also replace the word Scrum in that statement with the word Agile. This is an organizational design problem coupled with human factors, or more bluntly, leadership behaviors!