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."

Something common I’ve seen in effective agile teams is that testing has found a new home at the heart of development. I’m not referring to developers doing test-driven development to create code that is simpler in design and has testability engineered into it. I’m referring to testers working among developers doing continuous exploratory testing on vertical slices of stories still in progress.

I suspect lots of decisions are made because they bring short-term benefits despite there being long-term risks. I've seen agile teams pushed for feature after feature with the business owner citing business value prioritization. Certainly there is commercial pressure for features but how many of these features have been validated with users? Is the demand real?

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.

All our work items, both user-focused and technical, are stories framed in the context of a user interacting with the product. Each story represents a distinct, visible and testable piece of work that can be delivered independently to realize some value. Stories exist at many levels of specificity and never convey solutions. For example, at a point in time it's sufficient to use an ambiguous story to describe an interaction as simply an activity a user engages in using the product. At some time later, typically when detail starts to matter, smaller stories are written to describe that activity in terms of more specific tasks the user performs with the product.

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.