2015-07-05

When does Agile justify fudging?


Tom Breur
5 July 2015


We’ve had enough experience with Agile over the last two decades that most success factors have probably been surfaced. Some stuff works, some doesn’t. Agile has its own set of anti-patterns, and cutting corners (sloppy engineering, omitting documentation, quick and dirty practices, etc.) in the name of “working Agile” is one of those notorious anti-patterns.

The intentions are good. We want to deliver value early. But the temptation of quick and dirty is luring… If you ever get the sense that someone is trying to justify sloppy engineering because “we are working Agile”, then you are probably on to something. A slippery slope…

We don’t work Agile for the sake of converting to the latest and greatest religion. As soon as people refer to “Agile” instead of some genuine business value, preferable bottom-line revenue, be weary. The intriguing question is how you can (best) help your colleague? How do you surface the fallacy in this line of reasoning? Preferably in a non-threatening way. After all, everybody is trying to help. Even if it doesn’t always look like that (as Jerry Weinberg has pointed out).

Some engineers hate documenting. And so do I, for that matter. But if you take pride in your work, you know it is “just” part of the job. Failure to write accompanying documentation accumulates technical debt. In a similar vein, the temptation of “quick and dirty” leaves the team stuck with dirty, long after the quick as been forgotten. Not a healthy dynamic, either. Tricky to deal with.

The single best approach I have learned for reaching out, and attempting to “connect” with a colleague that appears to be falling for this trap, seems acknowledging and appreciating his good intentions. We are all trying to do “the right” thing. Let’s talk about how to get there.


No comments:

Post a Comment