December 9, 2021 at 11:29 am
This was removed by the editor as SPAM
December 10, 2021 at 6:10 pm
And a funny thing actually happened along with all that. We were actually able to put code out more quickly than ever because we weren't bogged down with rework.
Reminds me of a concept I learned in grad school: quality is free. In other words, aiming for high quality and doing it right the first time eliminates (or sharply reduces) rework (or .... customer complaints, returns, etc.).
Trying to figure out the world of SQL as marketing consultant for SQL Solutions Group https://sqlsolutionsgroup.com/
December 11, 2021 at 12:51 am
I know I may be beating a dead horse, but I wonder about a related issue. At work we're upgrading a couple of old MS Access apps. (Neither app has anything to do with the other. Each is used by a different user group.) One thing that I'm getting tired of is the users to tell us, "Exactly what we want". Then when we deliver, they go, "Oh, we forgot to mention this, that, the other thing, the other fourth thing...". And I know that my colleagues are getting tired of it, too.
Some of this might be because we've not adopted agile. And aren't likely to. Instead, we tend to be waterfall. However, the users are used to that as well. When we mention MVP (minimum viable product), they go "No, we want MVP - Maximum Viable Product".
Another problem is no matter what we do, they will never test anything. So, when we deliver, they go, "Oh, that isn't what we wanted...". But they refuse to work with us.
How do you all handle that?
Rod
December 11, 2021 at 4:38 pm
wabmaster wrote:And a funny thing actually happened along with all that. We were actually able to put code out more quickly than ever because we weren't bogged down with rework.
Reminds me of a concept I learned in grad school: quality is free. In other words, aiming for high quality and doing it right the first time eliminates (or sharply reduces) rework (or .... customer complaints, returns, etc.).
This is a lot of DevOps. The idea is that you do accept some mistakes, because you know you're not perfect, but you are always aiming to improve. Most teams release fast, but fail to change and improve how they do things. That's the key part.
Quality is only easy when you have the knowledge. Gaining that knowledge takes time, but it has to be a core element of what you do, which far too many in dev work and management fail to grasp. They want speed without changing anything, the factory mentality.
December 11, 2021 at 4:42 pm
I know I may be beating a dead horse, but I wonder about a related issue.
...
Rod, hope I don't upset you, but this is a "you" problem. You are letting them dictate a path of development for you and setting your expectations
What I'd do is expect that things won't be right, or that they will want things changed.
I'd start to deliver a little less, and earlier, expecting that they will give feedback when you deliver and want changes. Once you accept that's the path, then you can work along it.
Agile is a series of fast waterfalls. Rather than a six month project, I'd skeleton out most of what I need and deliver some things, letting them give me feedback. Then fix those things or add others. They might be upset that the entire thing isn't done, but I'd show them, this part is done.
December 11, 2021 at 5:51 pm
Thank you, Steve, I accept the feedback. We've got to change our approach.
Rod
Viewing 6 posts - 16 through 20 (of 20 total)
You must be logged in to reply to this topic. Login to reply