Worse Before Better

  • JRuss wrote:

    Jeff Moden wrote:

    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.

  • Doctor Who 2 wrote:

    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.

  • Thank you, Steve, I accept the feedback. We've got to change our approach.

    Rod

Viewing 3 posts - 16 through 18 (of 18 total)

You must be logged in to reply to this topic. Login to reply