This article discusses why we need to use the scientific method to explore our approaches. The intended audience is practitioners who are trying to decide the best approach as well as consultants who are trying to improve their offerings. It is not intended as an attack on any particular framework or method. I suggest that most approaches are based on unexplored assumptions, however, and that these could be improved with an investigation into their foundations. By using the scientific method we can get a better understanding of how we can improve our methods.
The Intention of this Article
This article will discuss how Scrum and SAFe are based on many unexamined assumptions, the intention of this article is not to dismiss or diminish either. Rather it is to provide options that Scrum and SAFe practitioners can use to either improve their adoption or decide to attempt other methods. Many of the challenges people encounter are due to a mismatch between Scrum and SAFe’s unexamined assumptions and the reality of the team or organization adopting them.
We also examine the basis of FLEX to illustrate how presumptions are not necessary to be effective.
A note to any proponents of Scrum or SAFe. Please advise me of any misrepresentation of either Scrum or SAFe.
Let’s start with a few terms.
Assumption – a thing that is accepted as true without proof.
Postulate – a thing suggested or assumed as true as the basis for reasoning, discussion, or belief.
Presumption – an idea that is taken to be true, and often used as the basis for other ideas, although it is not known for certain.
Presupposition – a thing tacitly assumed beforehand at the beginning of a line of argument or course of action
Although these four terms are synonyms, most Agile frameworks and methods are defined on what could best be called presumptions. I will, therefore, use that word in the rest of this article. A presumption is quite different from a hypothesis. A hypothesis is a supposition or proposed explanation presented as a starting point for further investigation. A hypothesis is explicitly stated as something which is not known to be true but being presumed for the moment to be true with an implied request to validate it.
The challenge in the Agile community now is that neither Scrum nor SAFe are based on hypotheses, but rather on presumptions. While these are often true in certain situations, they are presented as absolute truths. By never being examined (since they are taken as truth) people run the risk of using these frameworks in a place they are not designed for.
The scientific method, paraphrased from Wikipedia, involves:
- careful observation
- applying rigorous skepticism about what is observed, given that cognitive assumptions can distort how one interprets the observation
- formulating hypotheses, via induction and deduction, based on such observations The hypotheses are then validated or invalidated by experiments or additional observations. This is distinct from using science which doesn’t involve trying to create new hypotheses, merely use existing ones.
Presumptions and Hypotheses of Scrum, SAFe and FLEX
You should notice that all of the foundational beliefs of Scrum and SAFe are presumptions while all of the foundational beliefs of FLEX are hypotheses. The implications of this are great. While this does not invalidate Scrum or SAFe, nor does it mean that they can’t be improved, it does suggest that both run the risk of not being applicable in certain situations that they’ve merely presumed (without investigation) that they are. FLEX, on the other hand, holds everything open to question and encourages double-loop learning
Empirical process control is required in complex systems
From the Scrum Guide:
Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that
knowledge comes from experience and making decisions based on what is known. Scrum
employs an iterative, incremental approach to optimize predictability and control risk.
While the Scrum guide does not explain why this is a good thing, Ken Schwaber’s book
Taking a framework designed for product development can be readily transported to IT
Providing the endpoint and saying “do it” is an effective way to improve for all situations
Creating a framework around levels is an effective way to provide a relatively simple starting point with a way to expand its capability.
You should start at the team level and move up the levels provided