| | February 20168CIOReviewMake the Pain VisibleBy Janelle Klein, CTO, New IronWhat if we could measure the indirect costs of problems building up on a software project? What if we could measure collaboration pain, troubleshooting pain, and the chaos from things going wrong?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 itWhen 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 FrameworkIdea Flow Mapping is a technique for visualizing the flow of ideas between the developer and the software. Similar to how an EKG In MyOpinion
<
Page 7 |
Page 9 >