Do you have the right data for tackling technical waste?
5 minute read
Our background and experiences inform our instincts … and your instincts tell you that productivity is low because technical waste is in the way. How can teams possibly be effective working through the maze of quality issues they face?
You have instituted process changes to help them reduce WIP. You have established the roles recommended to make communication clearer and faster. You have embraced the recommendations you’ve heard at conferences or from consultants. You and other leaders have made the concern of reducing technical waste a priority.
And those shifts are awesome! Things HAVE improved! Addressing those changes weren’t a waste … but they solved other issues. Your technical waste is still holding steady and even climbing with your developers still deeply frustrated and unable to meet the commitments because of “something else that’s blocking them.”
The reality is that technical waste is not a team problem. It’s an organizational problem where each team engages with a different part of that waste in a different way. Even worse, it is invisible for most stakeholders, because most of the causes are only visible by trying to change the code.
The instinctive way to tackle any organizational level issue is to create an aligned vision for everybody to direct their energies. These visions usually have roadmaps, milestones, and other metaphors that represent a journey that everybody is taking together.
And herein lies the problem.
Talking with the teams, you’re hearing conflicting answers. One team needs automated tests. Another team needs to delete many automated tests. And from where you’re standing, both seem right. How could that be?
One client’s experience
One client performed a survey to find out exactly what the patterns and themes were to address their technical waste. The painful results were that there were no themes. There were no patterns, yet every problem needed alignment among several teams. There was no clear way to define a roadmap to align everybody, but everybody needed some alignment.
The way businesses are designed to operate is to find themes, fund them, and address 80% of the issues by solving the right 20% of the problems. Businesses allow some local variation to handle differences, but within constraints so that teams don’t detract from each other’s efforts.
As such, getting no patterns was an unwelcome result. There was no clear action for leaders or teams to take to eliminate technical waste. There was no right 20% to solve. Local action wouldn’t work because each team’s actions impacted other teams, and the client needed to maintain an overall balance toward company goals. Alignment, roadmaps, and the traditional definition of leadership wouldn’t work because different teams needed to pursue contradictory objectives to resolve contradictory contexts.
Solving technical waste requires an organization that provides two things simultaneously:
each team sees the impacts of its choices on other teams and aligns as needed for global optima; and
different teams can work fully supported in contradictory ways to address problems in different contexts.
The job of leaders is to create this organization. That job starts with leaders internally holding both perspectives simultaneously. Each team needs ownership and resources for them to tackle the technical waste they uniquely see.
The critical first step for this client was simply gathering their data. It identified why past solutions weren’t working, which established a shared need to do something very different for their technical waste.
Get YOUR data
A significant reason for you to get your data is that managers frequently feel that their groups are in close alignment. They will continue to believe this and continue the roadmap approach until they see their own data contradicting that belief.
So, you need to get the data to demonstrate this problem. We have helped other organizations create simple surveys that give the big picture and clear visibility, and as such, we are sharing a tutorial and questions to use for collecting that data.
The data from these developers will provide clear evidence to give each team the ownership they need to solve the technical waste as they see it.
The inevitable need
Once the issues that point to technical waste are clearly visible and the numbers painfully call for action, you can point leadership towards Disciplined Refactoring.
Wait a minute! Did we just propose a universal solution after telling you there is no universal solution??
Well, we proposed a universal attitude, but one that has a multitude of techniques depending on the specific problem. Thus, each team can use a different part of Disciplined Refactoring to address the technical waste according to their unique problem.
While the content varies, the way to coach that content is the same. Deep Roots scales its disciplined refactoring solution across the organization to instill these unique habits with a clear return for both the individual team’s problem and the organization’s strategic goal.
One very universal concept that fundamentally roots all unique habits is our Insight Loop. This shifts how developers read and write code with practices that align with modern brain science. However, once those three habits are learned, each team can select the change series and subsequent habits that fulfills their needs.
Your next step
The keystone to reducing technical debt is not a strategic decision by program management, team structure, or funding. While executive sponsorship is the critical influence, the real change comes from altering the way developers code on a typical story.
Regardless of your decision to use Deep Roots or any other technical coaching solution, it is our foremost hope that you collect this data, allow your managers to see what isn’t working, and start those steps forward for giving teams the ownership they need to solve the technical waste issues they know need to be solved on their team!