There is such a tremendous amount of misunderstanding and misinformation floating around out there about the Agile philosophy and the Scrum framework that I sometimes wonder if anybody is actually using this stuff.
It’s frustrating because these concepts and processes make so much sense to those of us who do understand them. It makes it very difficult to even converse with the masses of people who think they “get it” but don’t. Sometimes I even doubt that the creators of the Agile Manifesto truly understand why it works or why it has caught on so quickly. There really is no great mystery about that either.
Beyond that, I’ve been reading lots of job descriptions recently advertising for an Agile Coach or Scrum Master. I also participate in a number of Agile and Scrum discussion groups. I am shocked by the obvious lack of understanding by the people who create these things or make these comments.
So, let me see if I can bring some clarity to this.
Agile is a hypothesis. Scrum is a theory.
If you are not familiar with the Scientific Method, the basics are:
- You notice something happening and wonder why.
- You come up with an idea about why you think this thing is happening. This is called a hypothesis.
- You then design a test, an empirical, fact-based test to prove or disprove your hypothesis in a controlled environment. As in: if my idea is correct and I perform these specific steps then I should see these specific results.
- You then look at the results and come up with other ideas and tests.
For Agile, seventeen successful software developers noticed that they were successful and wondered why. They decided to get together to see if they could figure out why they were all successful. They wanted to see if there was any commonality.
Together, they came up with the four Values and twelve Principles that compose the Agile Manifesto.
But this is just a hypothesis. They do not provide any empirically testable proof that these conclusions are true. It’s all anecdotal.
For Scrum, Ken Schwaber and Jeff Sutherland were successful software developers who noticed that they were successful and wondered why.
They came up with a hypothesis, based on their experience and observations. They designed ways to test their hypothesis in a controlled environment. They then tested it and proved that it worked. They revised and updated their hypothesis, retested it and re-proved it. They continued this cycle until they could prove that they had a working model.
The problem is that they could not definitively prove that this model would work in other environments so, they called it a Framework.
In this case, framework means, a theory for software development that may or may not work in other situations.
I’m not trying to take anything away from the creators of Agile or Scrum. I know that they are all brilliant and successful developers. I’m just suggesting that they don’t truly or fully understand why they have become successful software developers because, if they did, they could prove it with empirically testable, fact-based steps that others could confirm independently. So far I have not seen any such evidence.
This mirrors my long-held opinion that the worst people to ask about success are successful people. I think this is because they were so busy being successful that they didn’t have time to think about why. So, when you ask a successful person to reflect on their own success, they are giving opinions or impressions, not facts. We all know how memories have a way of morphing away from the truth.
So the final question is; do I have any way to substantiate these comments about Agile and Scrum?
And the answer is Yes, because, I have created the missing formula.
I have taken the output from those who created Agile, Scrum, and the other #framemethods and developed my own hypothesis for why they have been successful. I also included my observations from my own 30 years in software development.
I then created empirically testable, specific processes that will work in any situation. These work every time and in every environment. Unfortunately, like Albert Einstein, I didn’t pay much attention in math class so, I have not quite been able to reduce these to an equation but, the processes themselves are solid and I can prove it.
This is why I am so comfortable in saying that most of the stuff I read about Agile and Scrum is incorrect, sometimes grossly incorrect.
And that is frustrating.