One of the most powerful tools in helping people understand the value of changing the way they build and deploy systems is to quantify the benefit of making the change.  While the math of quantification can be intimidating to many, we use calculators as a matter of course for many of the economics-based decisions in our lives: buying a car or house, or sending a child to college, for example. Why not create calculators for estimating the economic benefit of working in new ways? Why don’t we quantify the effect of “a bad system” in which people work?

The Cost of Uncontrolled Multitasking

The burden of too much work juggling manifests as the thrashing of uncontrolled context-switching and ineffective meeting attendance. In the Agile parlance, this is called work in progress (WIP). The impact on the effectiveness and morale of our workforce should be considered with concern that includes the human-focused culture rather than the “just the way it is” culture. The impact also extends well beyond the individuals and into the economics of value delivery for the organization. My experience in enterprises from large engineering, military defense contractors, and medical device providers — even to pressure-cooker startups — indicate a pervasive tolerance and reinforce this economic burden on value delivery.

We know that uncontrolled multitasking takes a heavy toll. Expressing the impact in the language of dollars is the most effective means for motivating a change.

My simplest Value Calculator quantifies the cost of context-switching based on research and a few key parameters. Here is a screenshot, showing the use of the following parameters: 

  • Uninterrupted Flow Time = 2 hours
  • Context-switching ramp-up time = 25 minutes
  • Planned Productive Days in a Week =5
  • Planned Productive Weeks in a Year = 48
  • Number of People on a Project = 200

This is my most widely used and referenced calculator because of its simplicity and decisive impact.

Use of this calculator is anonymous and free:

For more details, including abatement techniques, see this article:

The Value of Early Identification of Dependencies

All of my career as a software developer, I have seen some version of the following chart, illustrating the increasing magnitude of effort to fix a defect found later in a life cycle:

The behavior that resulted from presentation of this data, when using a waterfall process, is that more time was invested in detailing, reviewing and approving artifacts in all of the phases prior to system delivery. The cascading effect was early commitment to solutions without the benefit of fast-feedback learning cycles. Therefore the defect cost (creating the thing wrong) was replaced with the cost of creating the wrong thing.

An Agile approach, with smaller chunks of Plan-Do-Check-Adjust (PDCA), helps reduce defects, but only within the context of the scope for which a team is responsible.  Late testing of dependencies across Agile teams often results in what I call “late-integration defects”, with the same exponential increase in cost to the system delivery as we discovered in a waterfall process.

The Early Identification of Dependencies calculator correlates identification of dependencies across teams to defect identification and remediation, thus quantifying the value of discovering dependencies early and treating them as first-class citizens of the process.  That is, we test the dependencies with every Plan-Do-Check-Adjust cycle at a team-of-teams level.

The advantage of using the calculator is not only that you can choose the parameter values most representative of your context, but also that you can try out different combinations of values to see the relative impact of alternative scenarios.

Try out this calculator:

The Advisor-calculator for Allocation of Specialized Competencies

As we seek to organize around value to streamline delivery of a product to customers, we struggle with a key question: How should you organize teams to make best use of a particular competency?  A competency is made up of skills, knowledge and abilities. Should we create a team of people with this competency and leverage them as a shared service to other teams?  Should we allocate one or more team members with this competency to each team? Should we have the people with this competency create a service to be used by other teams?

I have created a calculator that will leverage the parameters of your organization to provide insights and advice on the team structure that could work best for you. My experience in advising organizations is brought to bear in creation of the calculator with a related description and examples.

Team Structure Options

Following are the three options that the calculator will examine based on your parameters:

  1. Designated Team Members: A person with the competency is assigned as a team member on each cross-functional Agile team that needs the competency within the defined organizational scope.
  2. Complicated-subsystem Team: The people with the competency are all part of a single team.  This team provides support to any team, program or Agile Release Train that needs this competency to implement and deliver their solution or element of a solution. This includes the pattern of a Shared Services team. 
  3. Competency-as-a-service: The most-often needed skills and how to apply them are provided in a well-defined interface with effective usage guidance. The calculator allows entry of parameters to support an Enabling Team that may be needed to educate and assist users of this Competency-as-a-service.
Calculator Flow

This article will not describe all of the details of the calculator, as it is five pages. The flow of working through the calculator is as follows:

  • Page 1 collects information on the supply of the competency.  
  • Page 2 collects information on the demand for the competency.
  • Page 3 assesses the fit for the Designated Team Member model and provides recommendations.
  • Page 4 assesses the fit for the Complicated-subsystem model and provides recommendations.
  • Page 5 assesses the fit for the Competency-as-a-service model and provides recommendations.

Much of this work is influenced by “Team Topologies: Organizing Business and Technology Teams for Fast Flow” by Matthew Skelton and Manual Pais.  Application of the Team Topologies to teams-of-teams is also explained in this article:

The online calculator is free to use at This page also provides a link to view the detailed description with examples.

The Value of Value Calculators

In contrast to speaking hypothetically and abstractly about the value of the way we build systems, value calculators, as represented here, provide the following value to an organization:

  1. Support detailed understanding of the economic drivers in the way the organization builds systems
  2. Provide a quantifiable way to use the parameters specific to your organization or context
  3. Result in data that compels improvement in the system that builds systems