What is Empiricism in the agile scrum context ? One thing it is not is about building empires in your product roadmap 🙂
According to the official Scrum guide , “Empiricism asserts that knowledge comes from experience and making decisions based on what is observed”.
In other words, empiricism is about fact-based, experience and evidence oriented approach typically done in iterations (or experiments). From these iterations, we can gather observations, market findings and feedback from others.
Towards this end, this is where the 3 pillars of empiricism comes in.
1. Transparency
One of the most common elements necessary in a scrum team is an agreed Communication channel and language, roles and responsibilities. Most commonly practiced via the scrum ceremonies such as daily scrums (otherwise known as stand ups), sprint planning, sprint retrospective and sprint review.
In daily scrums, there are no right or wrong questions and the team try to keep away from any negative info from business users, introduce Scrum roles.
The most important is trust between team members. The key transparency point is that everyone in the team should be able to collaborate with each other and share concerns, impediments, challenges and ultimately any solutions.
Another important element is the Definition of Done (which I will explain more in my next article so stay tuned).
2. Inspection – this pillar is not about auditing but rather more on seeking feedback on aspects of the product encompassing system, processes, people, practices, continuous enhancements, culture and collaboration. One such example is the demonstration of features built to users during the sprint demo and review session.
3. Adaptation – this pillar about continuous improvements on aspects described above. Without further actions and improvements on those identified aspects, the product may not be able to grow beyond the current scope and enhancing its value over time.
At the end of the day (or sprint), what this 3 pillars aim to promote is the team spirit of togetherness and ability to work and ensure that product improves over time with more iterations and experiments.
Disclaimer: What I am sharing is purely from my point of view and experience working with various teams as a scrum master. It does not reflect anyone else’s opinion or endorses a framework.
What I present in my posts doesn’t necessarily mean that it is applicable to your work, organization and culture but I am glad if it aids you in your agile journey.
Sincerely and with many thanks for reading my articles, Jason.
