Skip to content

Our Inspiration

The Three Pillars of Empiricism

When we were first introduced to Scrum in 2007, the “lightbulb” went on.  Scrum is how we are supposed to implement projects.  For years, while implementing software, web-based, and infrastructure projects, we have gone through the frustrations and constraints of the typical waterfall development methodology – long product development cycles, mismatches between what the client expected to see and what was actually delivered, demoralized team members, and countless hours and dollars wasted as a result of waiting six months or more for the project to complete, only to realize that the organization has chosen to go in a different direction!

The three pillars of empiricism which define Scrum theory are transparency, inspection and adaptation. These are the backbone of our

beliefs. Frequently we have found that multiple people involved on a project, including stakeholders, developers, business analysts, and product owners, have differing views of the development process and the vision of the product. In other words, why are we spending time and money to build this in the first place?  Developers are often trapped in an isolated “black box”, either of their own choosing or placed there by management, limiting their perspective of their individual role and the purpose of the project to a “tree” level instead of a “forest” level. Using the Scrum framework on development projects has eliminated this perspective compartmentalization.  Scrum advocates and promotes transparency, in that the client knows exactly what is expected to be delivered in each sprint, because they were responsible for defining and prioritizing the Product Backlog.  The Scrum team is on the same page with the Product Owner in understanding the vision of the product to be released, and that vision is reiterated, clarified, and shared in every sprint throughout the course of the project.  Common language and standards define and refer to the development process which is shared and understood by all team members, as well as stakeholders and outside observers, thus promoting an open work culture.  The Scrum teams producing the work and those accepting the work, all have the same understanding of what is defined as “Done.”  Most importantly, open, honest and constant communication and collaboration among the entire team, including Product Owner and ScrumMaster, is encouraged and promoted by the very nature of a Scrum framework in place.

The second pillar of the Scrum framework, inspection, allows for the use of a common Scrumboard and other information radiators.  Scrum users are required to frequently inspect Scrum artifacts and review their progress towards a Sprint Goal and any unexpected or unfavorable variances are identified and analyzed immediately.  Under the waterfall methodology, as the project manager, they are solely responsible for inspecting all artifacts and reviewing our progress, analyzing unfavorable variances, and then following up with the development team to understand why development was taking longer than expected.  The Scrum framework puts the onus of responsibility on the entire team, not just the ScrumMaster, to review Scrum artifacts, track their progress, and ensure the successful delivery of sprints.  This further cements a collaborative, team-based environment.

The third pillar of the Scrum framework ties very closely to the inspection pillar.  Once unexpected or unfavorable variances are identified and analyzed, the process or artifact is adjusted as soon as possible to minimize further impact to the sprint and the overall project.  This demonstrates one of the clearest benefits of the Scrum framework in making quick adjustments to “course correct” a sprint.  With the waterfall methodology, it is akin to being in a car traveling to a destination, being solely dependent on your car’s GPS, and realizing only too late that your GPS only shows you your current progress and location once an hour when it politely informs you that you should have gotten off of the interstate 30 miles ago.  Earlier and more frequent feedback from that waterfall GPS, “Hey, you just missed a turn.  If you adjust your route by taking the next left, we’ll be right back on track,” would have been very helpful and would have resulted in a lot less time and fuel getting to the destination.

The three pillars are built upon a foundation of trust – trust in yourself, trust in your team, and trust in your organization and their support. When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.  The three pillars are built upon a foundation of trust – trust in yourself, trust in your team, trust in your organization and their support.

Why are we so passionate about Agile and particularly Scrum?  For our stakeholders.  They are the ones holding the purse strings on project budgets and they do not necessarily care about how the work gets done.  They care about making money or saving money.  And many of these stakeholders may not even realize how much money they are wasting on product and project delivery.  Helping stakeholders connect the dots and understand just how using Scrum will save them money and seeing the lightbulb go off in their eyes makes it all worthwhile.  Identifying defects sooner results in higher quality and less money spent AND less tech debt and maintenance costs, which can really add up when you consider that the average lifespan of a project is 15 years.

Happier team members, better communication and collaboration, higher quality, and lower costs… why WOULDN’T you want to be Agile?

When we were first introduced to Scrum in 2007, the “lightbulb” went on.  Scrum is how we are supposed to implement projects.  For years, while implementing software, web-based, and infrastructure projects, we have gone through the frustrations and constraints of the typical waterfall development methodology – long product development cycles, mismatches between what the client expected to see and what was actually delivered, demoralized team members, and countless hours and dollars wasted as a result of waiting six months or more for the project to complete, only to realize that the organization has chosen to go in a different direction!

The three pillars of empiricism which define Scrum theory are transparency, inspection and adaptation. These are the backbone of our beliefs. Frequently we have found that multiple people involved on a project, including stakeholders, developers, business analysts, and product owners, have differing views of the development process and the vision of the product.  In other words, why are we spending time and money to build this in the first place?  Developers are often trapped in an isolated “black box”, either of their own choosing or placed there by management, limiting their perspective of their individual role and the purpose of the project to a “tree” level instead of a “forest” level. Using the Scrum framework on development projects has eliminated this perspective compartmentalization.  Scrum advocates and promotes transparency, in that the client knows exactly what is expected to be delivered in each sprint, because they were responsible for defining and prioritizing the Product Backlog.  The Scrum team is on the same page with the Product Owner in understanding the vision of the product to be released, and that vision is reiterated, clarified, and shared in every sprint throughout the course of the project.  Common language and standards define and refer to the development process which is shared and understood by all team members, as well as stakeholders and outside observers, thus promoting an open work culture.  The Scrum teams producing the work and those accepting the work, all have the same understanding of what is defined as “Done.”  Most importantly, open, honest and constant communication and collaboration among the entire team, including Product Owner and ScrumMaster, is encouraged and promoted by the very nature of a Scrum framework in place.

The second pillar of the Scrum framework, inspection, allows for the use of a common Scrumboard and other information radiators.  Scrum users are required to frequently inspect Scrum artifacts and review their progress towards a Sprint Goal and any unexpected or unfavorable variances are identified and analyzed immediately.  Under the waterfall methodology, as a the project manager, they are solely responsible for inspecting all artifacts and reviewing our progress, analyzing unfavorable variances, and then following up with the development team to understand why development was taking longer than expected.  The Scrum framework puts the onus of responsibility on the entire team, not just the ScrumMaster, to review Scrum artifacts, track their progress, and ensure the successful delivery of sprints.  This further cements a collaborative, team-based environment.

The third pillar of the Scrum framework ties very closely to the inspection pillar.  Once unexpected or unfavorable variances are identified and analyzed, the process or artifact is adjusted as soon as possible to minimize further impact to the sprint and the overall project.  This demonstrates one of the clearest benefits of the Scrum framework in making quick adjustments to “course correct” a sprint.  With the waterfall methodology, it is akin to being in a car traveling to a destination, being solely dependent on your car’s GPS, and realizing only too late that your GPS only shows you your current progress and location once an hour when it politely informs you that you should have gotten off of the interstate 30 miles ago.  Earlier and more frequent feedback from that waterfall GPS, “Hey, you just missed a turn.  If you adjust your route by taking the next left, we’ll be right back on track,” would have been very helpful and would have resulted in a lot less time and fuel getting to the destination.

The three pillars are built upon a foundation of trust – trust in yourself, trust in your team, and trust in your organization and their support. When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.  The three pillars are built upon a foundation of trust – trust in yourself, trust in your team, trust in your organization and their support.

Why are we so passionate about Agile and particularly Scrum?  For our stakeholders.  They are the ones holding the purse strings on project budgets and they do not necessarily care about how the work gets done.  They care about making money or saving money.  And many of these stakeholders may not even realize how much money they are wasting on software development projects.  Helping stakeholders connect the dots and understand just how using Scrum will save them money and seeing the lightbulb go off in their eyes makes it all worthwhile.  Identifying defects sooner results in higher quality and less money spent AND less tech debt and maintenance costs, which can really add up when you consider that the average lifespan of a project is 15 years.

Happier team members, better communication and collaboration, higher quality, lower costs… why WOULDN’T you want to be Agile and use Scrum?

footerlogo

About Us

We are a global premier training and consulting company passionate about Agile and effective product and project delivery. We offer individual and corporate training, certifications, Agile transformation readiness and maturity assessments, coaching, and staff augmentation.

Who We Are

What Makes Us Different

Meet Our Team