Empiricism in Scrum Guide 2020 vs Scrum Guide 2017
Empiricism asserts that knowledge comes from experience and making decisions based on what is known. [SG2017]
Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. [SG2020]
Any idea what the difference in the message being conveyed is, based on the change in the last word from the two versions of the Scrum Guide?
It seems to be more consistent with the dictionary definition of "empiricism". The definition in Merriam-Webster specifically mentions reliance on observation. Wikipedia mentions "knowledge that comes only or primarily from sensory experience". One could believe to know something based on second-hand or third-hand reporting, so this change refocuses on making decisions based on first-hand interactions and observations.
Think of it as a gift from the year 2020...a lesson learned. People can claim to "know" all sorts of things, but unless that knowledge is based on observable evidence, there is no shared reality. The result is discord about what is being observed, and bitterly conflicting views about how to inspect and adapt.
Taking my own example, how many times have I said something like 'I'm 100% sure I left my keys in the kitchen', but when I actually find them in the lounge, I can't argue with that evidence. I didn't 'know' after all. 'Knowing' vs. 'observing'.
As Ian says, sharing a reality based on evidence is the most important thing.
so does what I have observed imply the importance of the 3 scrum pillars?
it looks to me that if I have to make some decisions for the future (i.e. make a valuable increment) I have to observe what I have that must be transparent (i.e. product backlog items refined) so that I can decide (what of them pick to fit the Sprint goal) and then inspect what I am doing / what I have done and adapt if I have found some variances.
I may have described the use of 3 pillars at very low level, but basically, is the empirism based on the only 3 pillars?
For me, empiricism really does come down to those three pillars.
However, transparency, inspection and adaptation can't just be applied in one area. Any complex system will have many observable aspects, that would need to be transparent, inspected, and/or adapted.
So as well as the Product Backlog being transparent, there should also be transparency about many other things, such as the roles, the Product Goal and current progress towards it, the previous increments, the stakeholders, how value is being accounted for, the Scrum events, the definition of "Done", feedback from the market, customers, users and stakeholders, etc.
There's no use having transparency over something unless it is inspected at least at some point, and there is no use inspecting anything if it doesn't have the potential to influence a decision to adapt (or not adapt) something.
Then once something is adapted (or a choice is made not to adapt it), the impact of that decision should also be transparent, so that it can be inspected later, and potentially lead to more adaptation.
It's also useful to consider how the Scrum Values support empiricism. For instance, providing transparency over some areas might require a lot of courage.
Empiricism in Scrum goes beyond the framework. I always explain empiricism as "do something, inspect what you did, adjust if necessary". This could be selecting an item from the Product Backlog and then determining it isn't a good fit for the Sprint. It could be writing a function in your code then realizing it isn't doing what you actually need it to do. It could determining that one of the columns on your board is never used so you remove it.
Any action can benefit from applying empiricism. But the main goal of using empiricism is to help individuals, teams, divisions, companies do something, inspect what was done, and adjust if necessary. Which in turns allows the individual, teams, divisions, companies to have the agility to survive in today's world.
yes, I agree.
the three pillars must be enabled in the whole system and in all areas. we need transparency in the 5 scrum events to enable inspection and adaptation, but also among artifacts otherwise we wouldn't have any sense. same among people in the scrum team as well as outside, if we aren't transparent to each others, we can't inspect and adapt to product real value