Reblogged with permission from Michael Küsters, the original author of this content. Originally published on his blog Fail Fast, Move On, June 2, 2018.
We throw around a lot of terminology – yet we may not even know what we’re saying. Here are three terms that you may have understood differently from how the original author’s intention:
1. Technical debt
Technical debt has been used by many to denote willfully taken shortcuts on quality.
Many developers use the term to imply that code has been developed with poor craftsmanship – for instance, lack of tests or overly complicated structure.
Ward Cunningham, the inventor of the term, originally saw Technical debt as a means of learning from the Real World – software built upon today’s understanding incorporating everything we know at the moment put into use. He took the stance that it’s better to ship today, learn tomorrow and then return to the code with tomorrow’s knowledge – than to wait until tomorrow before even creating any code!
In his eyes, the code should always look like it was consistently built “just today”, never even hinting that it had looked different years ago. Technical debt was intended to be nothing more than the existence of things we can’t know yet.
Technical debt always implied high-quality clean code – because that is the only way to incorporate tomorrow’s learning in a sustainable way without slowing down.
2. Kaizen (“Continuous Improvement”)
Kaizen is often understood as an approach to getting better at doing things.
While it’s laudable to improve – many improvement initiatives are rather aimless. Especially Scrum teams easily fall victim of such aimless changes when each Retrospective covers a different topic.
Taiichi Ohno, known as the father of the Toyota System which inspired Lean, Six Sigma – and Scrum, stated, “Where there is no standard, there can be no Kaizen“.
Kaizen requires a strategic long-term direction towards which people optimize and improve. Such a standard or direction is often absent in an agile environment – short-term thinking prevails, and people are happy to have done something better.
What this something is, and how important it is in comparison to the strategic direction may elude everyone. And there’s a huge chance that when we consider what we actually want to achieve, our “improvements” might even be a step in the wrong direction.
Have you ever bothered talking about where you’re actually heading – and why?
3. Agile
“Agile” is extremely difficult to pinpoint. It means something different to everyone.
Some think of it as a project management methodology, while others claim “There are no agile projects”.
Some think of a specific set of principles and practices, while others state these are all optional.
Some confuse a framework with agile – some go even as far as thinking that “Agile” can be packaged.
Some are even selling a certain piece of software which allegedly is “Agile”.
Yet everyone seems to forget that the bunch of 17 people meeting at Snowpeak were out to define a new standard for how to better develop software – and couldn’t agree on much more than 6 sentences.
Especially in the light of Kaizen above – What do ‘better ways’ even mean, when no direction and no standard has been defined?
A lot of confusion in the agile community is caused by people standing at different points, heading into different directions (or: not even having a direction) and aiming for different things – and then telling each other what “better” is supposed to mean.
The Agile Manifesto is nothing more than a handful of things that seemed to be consistent across the different perspectives: It answers neither What, How now Why.
To actually make meaning from that, you need to find your own direction and start moving.
blogagility.com 