Make the Pain Visible
In software development, the indirect costs of troubleshooting, learning, and rework can easily exceed 50 percent of the team's development capacity. After all the original developers leave a team, and nobody knows what to do, the indirect costs can take up to 70-90 percent of the team's development capacity.
How do I know? I've measured it
When the indirect costs increase on a software project, the project spins out of control. Releases start breaking, deadlines start slipping, and productivity slows to a crawl. The team starts begging for time to fix all the problems, but the project's already behind schedule. Eventually, the problems get so bad that rewriting the software is the only option.
We start with the best intentions. We try to write high quality code, that's low in technical debt, with lots of test automation, and short releases.
Fast-forward to several years later, and we're sitting around a conference table discussing what went wrong. How did we accumulate so much technical debt? Should we rewrite the component, scrap the entire system and start over, or just deal with the problems and try to keep going?
Then the rewrite cycle starts again— a new commitment, a new project, but this time we'll do it right.
Why don't we get the results we're looking for?
From the outside, it looks like we're trying to drive a car without a steering wheel. We line up the car's trajectory, based on our ideals, then close our eyes and floor the gas pedal. When we inevitably hit the wall and wreck the car, we have to build a whole new car to keep on driving.
What's missing from our software projects is ‘visibility’
Under constant pressure to deliver features, we neglect the things we can't see. Urgency leads to a habit of high-risk decisions. We make decisions that save 10 hours here, and lose 1000 hours over there, over and over again. Even when the pain consumes over 50percent of the team's bandwidth, the indirect costs are invisible.
Our software is a reflection of our decision-making habits. If we rewrite our software, but don't fundamentally change the way we make decisions, our problems keep coming back. We've been blaming technical debt for causing the pain, but technical debt is really the ‘symptom’ of the problem.
What if we made the pain visible, understood the causes, and then focused on the highest leverage improvement opportunities? That's what Idea Flow Learning Framework is all about.
Idea Flow Learning Framework
Idea Flow Mapping is a technique for visualizing the flow of ideas between the developer and the software. Similar to how an EKG helps doctors diagnose heart problems, Idea Flow Maps help developers diagnose software problems.
Rather than measuring the problems in the code, the Idea Flow Mapping tools integrate with the developer's IDE to measure the number of hours the developer experiences ‘friction’ in Idea Flow. With a data-driven feedback loop, developers can identify the biggest problems impacting the project.
The learning framework is based on the scientific method. The developers focus on their biggest problems, breakdown the causes, then run systematic experiments to learn what works.
Rather than focusing on code improvement (repairing the car), Idea Flow Learning Framework focuses primarily on skill improvement (driving skills). Better decisions about code improvements are a consequence of better skills.
The framework is designed to sit on top of whatever the team is already doing to help them learn and improve. Other than making time for learning, about a couple hours per week, there are no process changes required.
The Idea Flow Factory
Idea Flow data can be aggregated to the team, supply-chain, and organizational level, to create broad visibility of problems across the organization. The effects of poor staffing decisions, team structure, and problems with coordination, are visible in the aggregated data. Long-term trends of growing friction are plainly visible.
In the manufacturing world, statistical process control and supply-chain management led to revolutionary reductions in cost, but these tools have never been successfully applied to software development. The inherent variability of software tasks leads to noisy, meaningless metrics.
By measuring the variability of friction, rather than the variability of execution, suddenly, the quality and risk management tools from the manufacturing world can be applied to software development. The Idea Flow Factory is a software supply-chain model that enables statistical process control and supply-chain management in the software world.
At a business level, the invisible costs in software development cause problems too. For example, software companies have a tendency to chase after ‘bad deals’, where supporting the customers exceeds the revenue gained. If the costs are invisible, how do we know when increasing revenue will decrease profit?
Traditional cost accounting compares operating costs with revenue, and completely ignores the cost dynamics associated with chaos and increased effort. Bad decisions look like good decisions because we only see the things we measure. We save 10 hours here and lose 1000 hours over there, and it looks like a good decision.
It's about time we came up with a new accounting method.
In the book, The Goal, Eliyahu Goldratt describes "Throughput Accounting", a replacement for traditional cost accounting in manufacturing. Throughput Accounting measures the "rate at which the system makes money" by comparing the revenue generated through sales versus the investment cost to support the sales.
By using a combination of the Idea Flow Factory to build a cost model, and Ash Maurya's Customer Factory from the Lean Startup world to build a revenue model, we can implement a Throughput Accounting system for running a software business.
The revolution of cost reduction in the manufacturing industry started with measuring the enormous wastes in the manufacturing process and making the costs visible to leadership. If we start making our software costs visible to the investors of the company, I can assure you, there will be lots of motivation to fix the problems in the software supply chain.
Let's make the pain REALLY visible, and then learn our way to success!