The planning trap
This article is a follow-up of our exploration into The fallacy of sacrificing quality to build stakeholder trust.
In the previous article, we highlighted some retroactive loops that intensify pressure when sacrificing quality. Here, we delve into systems thinking and its application to our product team under high pressure.
We will model the stakeholder system to understand why organization can sometimes have a Pavlovian reaction of creating more planning.
Understanding system boundaries in systems thinking models
Before digging into the sources of pressure, it is crucial to investigate the concept of system boundaries. Donella Meadow explains the boundaries as follows in Thinking in Systems, a primer.
Boundaries are of our own making, and they can and should be reconsidered for each new discussion.
Donella Meadow, Thinking in Systems
When employing systems thinking to discuss a problem, like here about the pressure on product team, we must establish boundaries within the system. Trying to model all those interactions would result in a gigantic and overly complex model.
If you are familiar with Domain Driven Design (DDD), you can think of bounded contexts, it is very similar. The goal of bounded contexts is to set boundaries for the model you are designing. This will protect you from designing a too wide and complex model. The same applies for systems thinking.
Finding the appropriate boundary for your model requires experimentation and iteration. Do not be afraid to practice and redraw many models. Moreover, it is important to recognize that any systems thinking model is highly subjective, reflecting the modeler or the group of modelers way of seeing the problem. Forming a diverse group or seeking feedback outside helps mitigate biases and identifies potential blind spots.
Exploring the stakeholder system
Now, let’s return to our examination of the stakeholder system. Why do they exert pressure on teams?
In good faith, stakeholders aim to satisfy customers and improve the organization’s efficiency. This could be anything like improving EBITDA, raising funds, practicing golf… Let’s start building our model from this.
We can directly correlate business efficiency with stakeholder trust in the teams. As the organization produces more value, the trust in the teams increases.
To make the diagram easier to read, the team system described in the previous article is shown as a cloud.
However, when issues arise, there is a surge in customer complaints. CxOs phones start ringing. Stakeholders find themselves managing those concerns. This consumes time that could instead be dedicated to run the business more efficiently.
The support team will be impacted as well. The number of newly created support tickets is rising too. The support is overwhelmed by the workload. They start involving their management to be sure things are under control within the organization. As for the direct calls, the stakeholders’ time will be used to address those concerns.
Let’s reintroduce our previous model of the team system. As now effects will propagate to it.
Consequently, the support staff and management will handle the issue directly with the product teams to ensure the right actions are prioritized. This results in product team spending time synchronizing with the support team impacting the capacity.
Trust in the team diminishes quickly as the direct calls, support teams and middle management has to involve the stakeholders. Now they can look at the product teams low quality delivery to get some explanations why customers are complaining so much.
Model simplification
Having model this dynamic, let’s simplify our model focusing on the link between Stakeholder trust and user satisfaction. All the effects involved can be summarized to this:
The more your stakeholders trust the team, the more users will be satisfied and vice et versa.
This illustrates another important aspect of systems thinking models. You can have different levels of zoom into a model. As for the boundaries, you need to find the right zooming level to help the discussion.
Do you think you could convince with this simple model any CxOs? Telling them to fully trust their teams in difficult moments because it will make their users happy. I guess not. That is why it is important to explain and share your model to illustrate the effects in detail before jumping to this kind of conclusion.
Unfortunately, sometimes this virtuous path is not the one stakeholder are following and they can ask a simple question that can worsen the situation.
When the bug will be fixed? Can the team commit to a specific date by estimating the time to fix the issues?
The more planning reaction
Why are they asking about specific date or a bug fix or a specific feature?
One of the goals could be to introduce delay into their feedback system. By telling customers that the bug will be fixed next Monday, stakeholders are buying time to handle the issue within the organization. But you might expect a rippling effect. If the situation is not fixed by the announced time, customer non satisfaction will reach even higher levels.
With this strategy, the stakeholders can redirect their attention to the product teams by questioning why the team failed to improve the situation with the latest deployments.
The misunderstanding originates from the fact that the team was delivering new features quickly. And it’s now failing to make a single change without making the situation worse for everyone. The users are not satisfied, the team is under high pressure and the management is trying to elaborate plans to make things better for everyone.
As Mary Poppendieck explains in her presentation “Tyranny of the ‘The Plan’”, they are trying to control the future.
One the reasons why we schedule is to control the future, to make things happen at a certain point in time. But the problem is we know that detailed schedules are deterministic, we’ve rolled them up from a work breakdown structure and they don’t allow for variation.
Mary Poppendieck, The tyranny of ‘The Plan’
Trying to control the future through planning is the usual response in this case. The stakeholders will ask for more commitments from the product team, aka strict deadlines. The middle management will be asked to track the team’s plans for the next weeks. Building a detailed schedule to be able to announce a ‘realistic’ resolution time to customers.
Predicting when things are going to happen, is the second reason Mary Poppendieck’s highlights:
Why we schedule is to predict when things are going to happen. It would be nice to know. It’s kind of important sometimes. Then again, we know that when you base schedules on experience […] then they’re reliable.
Mary Poppendieck, The tyranny of ‘The Plan’
She admits that it is important to make a plan. But the main point is that you have to base a plan from experience to make it kind of reliable. In this context the team is unfortunately in a place where it can’t rely on its experience. The bugs are still not fixed, or the features are not covering the entire needs required by the customer. So, designing a rigid plan in this case is simply trying to elaborate a plan to please the management. It will most likely not be achieved and will impact stakeholder’s trust in the team even more .
The other important impact for the team is to spend more time working on this unrealistic plan which will reduce its capacity and increase context switches.
Continuing to deliver high quality software will become even harder for the team. The capacity is drained by planning activities (add some daily synchronization meetings here, building a powerpoint to communicate effectively the plan…) and the pressure ultimately increases.
How to overcome this challenge?
Now the reinforcing feedback loops are blocking the team making progress. The group is demotivated and will not be able to deliver anything quickly. At this time, the team might completely give up. The management might want to bring external consultants in or have to replace team members. The time to market is not even a question anymore. If the business survives here, hopefully, the time for being able to ship something is a question of months not weeks.
Which leverage point can we see in the model to mitigate the problem?
Capacity.
What is impacting the capacity in this model? Planning and prioritization activities as well as dealing with bugs. As the bugs are quite out of control now, we cannot really do anything about it. The principal candidate is to reduce the planning and prioritization activities.
So, giving some slack to the team so it can focus on what is the most critical to do right now. It is to bring the product back on track to delivering changes. Reducing the work in progress, tackling one issue at a time. You might not want to completely remove all the prioritization work because if you don’t fix the right issues then it’s a bad usage of already scarce development time. As always, it’s a tradeoff to find the right balance here.
In the end it really is about trusting the team to do its job.
But this will work if the team is able to produce high quality software. Maybe at the same time, the team is trying to tackle other challenging sociotechnical matters like:
- High coupling in the product.
- Onboarding a new teammate.
- Broken testing strategy.
- Learning new technology.
and more…
With these insights, hopefully, the team now has the capacity to focus on the most impactful fixes or features improvement. We are ready to dig into the internal challenges of the product team which can affect the quality.
Do you want to practice systems thinking?
There are plenty of other loops we can think of in the stakeholder system.
You can try to include the sales or a partnership team? How are they affected? How will they impact the described system above? Or integrating the communication aspects with social media for instance.
Feel free to share in comment or on mastodon your results.
