"You’re Doing It Wrong" - What Does That Mean?

DZone 's Guide to

"You’re Doing It Wrong" - What Does That Mean?

A look at what goes behind determining if something was done the "right" or "wrong" way in the context of agile development.

· Agile Zone ·
Free Resource

Doing it wrong

I didn’t think that my Story Points story would garner such attention. Reactions were divided to two groups: the “Great Post” type, short and supportive. And the “You’re doing it wrong” type, long and argumentative.

I can’t fault people for telling me “You’re doing it wrong” after I used it in that post. It did make me think about that phrase.

Here are examples from real life that reflect how we think about what’s right and wrong.

First there’s the technical side. Unit testing, refactoring, design. When I review tests and code, and I find issues, the reaction is either “yes”, or a “yes but”. Usually the “yes but” doesn’t relate to the code itself. It relates to “we don’t have time”, or “we had to build this on 10 years of legacy code”. Cultural explanations rather than bad coding practices. Rarely, the response is a “no”. It happens when people have enough experience (and gumption) to argue with the almighty consultant. The discussions then are much more interesting, although the “no” eventually wins.

In this type of right vs wrong discussion there’s obviously a bias for the more stubborn side. However, it centers around coding and design “best practices”.

Now, let’s talk about processes. Here we see many more of the “yes but” discussions. But the “no” are a the majority. “It’s not like that in scrum”. Or “you’re not supposed to use story points like that”. The process dogma, once implanted in the inhabitants of the organization seem even more powerful than any “best practice” out there.

It’s seems that technical practices are respected more than the procedural ones, at least as a measuring stick for rightness.

However we measure rightness, it really doesn’t matter.

It Doesn’t Matter If I’m Wrong or Right

 You see, my advice can work for you, or not. I may be right according to my experience, but my advice still won’t work for you. The opposite may be true too. The discussion is irrelevant.

It comes down to effectiveness.

What matters is if that tool or process works for you. If it speeds development up. If it raises quality. If people are free to safely experiment. If they are happy.

Show me how this is not just helping you, or the team, but also how it impacts the bottom line. That’s the most effective way to shut me up.

You can be wrong all you want, but I don’t argue with success.

agile, culture

Published at DZone with permission of Gil Zilberfeld , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}