AGILE IN ACTION

"Technical debt built up in the rush to get software out the door always comes back to bite you. There must be continuous investment to reduce unnecessary rework so that more of the available capacity can deliver value. Diligent attention to the health of the code keeps it habitable. In a way, the code is a place where developers ‘live’. Think of developers as users of the code. Like any other user, for example someone using their mobile phone, they want a good experience each and every time they use it. In that sense, habitable code is a well-kept home that makes it easy for developers to maintain design relevance and prevent obsolescence while increasing reuse and reducing risks along with medium to long-term costs. Long-term business agility begins with healthy software that is constantly deployable. But adapting quickly and cost-effectively in response to changing customer and business needs requires more than flexible software. Greater flexibility is needed in business thinking with reasoning that is open to challenge and new ideas. Business culture needs to embrace a willingness to explore and experiment without fear of failure."

At the Agile Evangelists Meetup last night, I said something like “we run with no known defects”. Thank you to Rick Vugteveen for asking me to clarify this. When we discover a defect we take steps to fix it as quickly as possible. It's a take on the Lean manufacturing concept of stop the line. We do this in two ways.

I've pulled together some data for the first year of a product stream we created and plotted it as charts for throughput, rework and effectiveness.

Without really thinking about it until now, I've been seeing two types of technical debt. The first is the quick solution implemented with dirty code. I consider this to be irresponsible. That's not to say I won't do it, just that if I decide I should do it I make sure the necessary people understand the consequences and that it's an irresponsible action to take.

In the Lean manufacturing world there's a measurement called First-Time-Through (FTT), which monitors whether a cell is making products right the first time. It's a measurement of the effectiveness of the cell's standardized work and shows the percentage of product made without any need for rework or scrap.

Circumstances often place developers in a situation where they face the decision: Do I write a cheap and nasty solution in order to move forward now? Or do I take more time to solve the problem properly and risk delivering less business value by the end of the sprint? In this situation, an agile developer should do the right thing.