How Heisenberg’s Uncertainty Principle Relates to Building Software
What is Heisenberg’s Uncertainty Principle?
Formulated by the famed German physicist Werner Heisenberg in 1927, the uncertainty principle states that it is impossible to simultaneously know the exact position AND exact momentum of a particle. The more accurately someone knows the position of a particle, the less accurately they know the momentum of that particle, and vice-versa.
When expressing the formula, the following values are used:
- Δx is the uncertainty in position.
- Δp is the uncertainty in momentum.
- ℏ is the reduced Planck constant (ℏ=h/2π).
- h is the Planck constant (a fundamental quantum of energy).
This inequality implies that the product of the uncertainties in position and momentum must be greater than or equal to ℏ/2. In simpler terms, the more precisely you know the position of a particle, the less precisely you can know its momentum, and the more precisely you know the momentum of that same particle, the less precisely you know its position.
How to Relate it to Building Software
Now let us see how this principle can be applied to software engineering teams that are operating in an Agile model. (Check out my last article for a high level intro to Agile if a refresher is needed!) First, we need to relate each of the key variables in Heisenberg’s formula to relevant variables from an Agile team’s metrics:
- Position will be the value of what a product team is building.
- Momentum will be an average sprint velocity (often in terms of story points).
- A Particle will be the product in question that is being build.
Position
This is the harder of the two inputs to quantify, however I am going to define this as a product’s progression towards achieving its long term goals, whatever they may be. In other words, answering the question of ‘are we building the RIGHT things?’ is what the position aspect of this analogy will represent. An example would be, if I am building a marketplace to sell used computers, building a matching algorithm would probably be in the right direction of building the right things; designing a web scraper to pull cute pictures of cats trending on Twitter would most likely NOT be the right thing to spend resources building.
The ability to quantify if a team is working on the right things is an extremely valued skill in Product Managers (PM) in today’s world. Metrics can be framed in different ways depending on the situation. For example, let’s take the metric Average Session Duration (ASD), which looks to measure the average time per session that a user spends on an application. For some applications such as Instagram, a high ASD might indicate that users are enjoying the app and spending lots of time scrolling for long periods of time; conversely, for an application such as Venmo, a high ASD might indicate that users are having trouble making payments, and having to stumble through the application to accomplish their goals. These are simple examples, with the takeaway being that blindly looking at metrics and acting on them without a true understanding of an application is akin to not even integrating metrics.
An important part of the PM role is being able to cut through noise and decisively steer a team based on its current situation. Asking what the long and short term goals for a product are, then combining that with the feedback (metrics + user given) in order to determine what work is the highest priority to complete. This process happens iteratively and frequently, with great teams being able to pivot off of impactful feedback and information instantaneously. This method is how we will determine ‘position’ for the purposes of this article.
Momentum
On the majority of application teams which use the Agile framework, the velocity of a team is measured in Story Points completed per sprint (unit of time, often 2 weeks). This can be broken up into Story Points completed in a single sprint, which can be broken up into Story Points completed by a single engineer in a single sprint. For this article, we are defining momentum as the velocity in terms of Story Points.
Story Points are determined by the engineering team, as they are the ones who are actually developing the code for a single story. This process is normally done in some form of a product backlog refinement (PBR) session, where user stories are estimated. The team member who raised a user story will provide context, details, and prioritization of the story, before the entire engineering team will vote on an estimated point value for this user story. A few of the main factors going into the estimation are:
- Complexity of a task.
- Experience of a team with similar tickets.
- Dependencies for the story.
- Requirements clarity and likelihood to change.
Hopefully it is becoming clear that the estimation of tickets is going to be radically different across teams, organizations, companies, and sometimes even across the same team at different points in time. There is no exact template for estimating stories, and as such, there is often no ‘right answer’ to how many Story Points something should be estimated at. The extrapolation here is that all metrics tied back to Story Points (ie sprint velocity) are challenging to measure and normalize.
Example:
In the above example, we have data from 2 sprints from a team of 2 engineers: Emily & James. We also have some basic metrics around the velocity of the overall team, and velocity of the individuals on the team. In this simple example, a fairly clear picture is able to be shown. However, in the real world, sprints have many more variables:
- Fluctuating Team Numbers- PTO, new joiners, sick leave, etc
- Team Experience- members getting more experienced and able to take on more work
- Work interruptions- during times of high volume, critical bugs and issues may take priority and impact sprints
- Changing Definition of Done (DoD) or other team process changes
These factors can make it extremely difficult to project and a team’s future velocity for a single or multiple sprints. There is oftentimes too much interference to have a consistent sprint velocity, even with full team capacity. Notably, quantum interference is a fundamental aspect of quantum mechanics, playing a crucial role in various quantum models.
I would be remiss if I didn’t mention that the names used in my above example are myself and my sister’s names (James, Emily)…in reality she would probably complete 25 of the total Story Points across the two sprints while I would struggle through the 1-pointer.
Where Does Uncertainty Appear in Agile?
Hopefully in each of the above sides of the equation, it is clear why it is difficult to calculate either the ‘position’ or ‘momentum’ of a software product team. However, with varying levels of effort, teams can get closer to projecting each value; in other words, becoming less uncertain about either value.
For example, a team can choose to allocate 5 hours per sprint towards things to monitor and improve their pace of completion of stories such as:
- Building Jira dashboard views of unfinished and finished work.
- Setting up Slack alerts when stories are ready for review, done, etc.
- Spending time after a sprint to analyze stories that didn’t close to try to self correct.
Alternatively, teams are able to take certain steps and efforts to try to make sure that what they are working on is the best possible thing to work on. Some of these actions include:
- Conducting regular prioritization sessions.
- Setting up frequent meetings with stakeholders to check requirements and prototypes.
- Spending time analyzing metrics such as Daily Active Users (DAU), Session Duration, Churn rate, etc.
- Evaluating competitors’ progress on comparable products.
While all of the above actions are all along the right path of actions that a product-driven team can take in order to improve their process and product, it is worth noting that there comes a time where the decreased uncertainty has diminishing returns.
If a team is optimized for ‘momentum’, this will lead to practices such as: no pivoting over long periods of time, engineers only spending time on production-ready work (rather than prototyping), and a strict sprint management structure (no tickets in, no tickets out). These can lead to a team’s velocity becoming higher and more predictable. The interpretation of this is that the team will be doing more work at a consistent rate, which is a great thing for a team to be able to predict delivery dates. However, this mentality gives the team very little ability to focus on doing the right things, which means that there is going to be a high uncertainty in the ‘position’ side of the equation as a result. For smaller companies, time and effort spent working on tasks that don’t help to grow their product reach is arguably wasted time.
Conversely, a team that is focusing entirely on ‘position’ will have behaviors like: rapid prototyping, intense analysis on product metrics, and seemingly constant feedback sessions. This is going to be giving the team a continuously changing picture of what work is best for the product and will grow it the most. However, because this work is changing so frequently, the engineering team will struggle to gain momentum on any feature. They will find themselves constantly needing to context shift, which tends to take time away from productive work. These impacts lead to a high uncertainty in ‘momentum’ on a project. As a result, teams will have difficulty rolling out consistent updates, communicating dates to customers, and often can experience a drop in morale due to the missed deadlines and changing priorities.
How to Manage Uncertainty in Agile?
Clearly, no project wants to have high uncertainty in ‘position’ or ‘momentum’ when it comes to growing and scaling a product. Both are important, and the balance of focus on these two facets are what make or break teams. Having a team that delivers a high number of useless features versus a team that takes too long to deliver 1 high quality leads to the same result….failure of a product.
Note that both of these things are definitely items to pay attention to and track with the goal being to improve a team’s product. However, what I am highlighting is that overly focusing on ‘position’ or ‘momentum’ will lead to problems and have negative effects. Figuring out this level of scrutiny is something that bad teams never figure out, good teams identify after some time, and great teams quickly determine the ratio, and then make micro-adjustments as the team evolves.
Another point to highlight is that you may have noticed that the priorities of a PM aligned more towards the ‘position’, while the priorities of a Tech Lead (TL) skewed towards the ‘momentum’ side. This is an excellent demonstration of why the TL and PM should be in lockstep, with them each advocating their views for a product, while not wanting to create high uncertainty in either the velocity of a team or impact that the current work has. When the two are working in sync and being logical and empathetic with each other, it creates a harmony that is infectious on teams!
By having open conversations with each other, TL and PM teams can work to figure out a balance that works best for their specific teams. Automating metric reports can be a powerful tool towards giving teams enough data, which can then be scrutinized closer if there are problems. Having a dedicated Product Operations team member as well can help to lubricate processes and minimize uncertainty; however, many companies are hesitant to hire this newly created position, despite the massive benefits.
I hope you found this information useful and perhaps it can be a helpful resource when engaging with team members when processes are being reviewed. In my view, a certain degree of uncertainty will always be present in building software, but if your team is consistently reassessing both ‘position’ and ‘momentum’, then that is a super position to be in.
(I promise I didn’t write this whole article just for that superposition quantum joke.)
