Tuesday, October 30, 2012

I Do Not Think It Means What You Think It Means

Here’s another example of why language matters, and how the words we choose matter so much.

I tried to join the European Lean-Kanban tour, not in person, but on twitter. (By the way, seems like an awesome tour, I’m thinking about going there next time around). And then the following tweet comes up:

"@cyetain: Talking to @DReinertsen at #lkfr12 he prefers "Deferred Work" to Tech Debt Metaphor. I think it is a bit clearer too..."

Before I give my interpretation, I give thanks to Jabe Bloom, who tweeted like crazy and made me feel at home (online) and for reporting this tweet (and giving birth to this blog post by proxy:)). And Don Reinertsen, I’m gaining more respect for everyday.

Now that the niceties are out of the way…

Technical Debt or Deferred Work?

When developers talk about technical debt, the words say: There’s some technical stuff we left out, which will come back to bite us. The refactoring we didn’t do will cost us when we’ll enhance that feature. Those tests we skipped writing, are going to cost us in regression bugs.

Note the economic jargon: The debt is an economic one, NOT technical. That’s no coincidence. Economics is a better way to persuade managers to listen to developers.

There’s also an emotional nuance in the term. When we’re taking on technical debt, we, developers, are carrying the cross for the company. Not only that, we take the blame, and know we’ll pay the price later. Or we can translate it to: We’re warning you, managers, this “joint” decision is on your head.

From the manager’s side, things look much clearer: We’re always prioritizing stuff. We can’t do everything we want, and things get dropped. So in the upcoming release, we’re going to drop these pesky technical things we don’t really understand. We do understand there are associated costs and risks (as the developers tried to explain), and we’re ready to decide.

We’re really deferring work. This is a business decision.

Not Just Words

Agile started as a solution to a problem: building a bridge between developers and the business people. The bridge is built on trust. Trust is built on communication. When we use charged words on one side, or disregard this emotional charge from the other side, we’re adding cracks to the bridge.

A few cracks will not break the bridge.

What do you think happens when there are many of them?

No comments:

Related Posts Plugin for WordPress, Blogger...
Twitter Delicious Facebook Digg Stumbleupon More