1. 47
  1.  

  2. 11

    Are teams empowered to change their process based on what they learn?

    If I’d be asking these questions I’d change them to something open (e.g. “how” instead of “are”). This way the agile vs fake-agile becomes a continuous region instead of a binary yes/no.

    I’ve seen many teams that claimed that they’re empowering teams to change the process but when pressed for details in best cases the “empowerment” was minimal and in worst cases they didn’t understand the question (but still answered “yes”) :)

    1. 8

      at first i was all like “this doesn’t look much like a defense industry doc” then i got to the crazy diagram at the top of page 3 and i was all like “ah, there it is - this is a defense industry doc.”

      1. 6

        All of this, especially “simply waterfall . . .development in agile clothing” and everything on the “Key flags that a project is not really agile” list are painfully familiar from my time working on a federal government project. I’m definitely not bought into capital-A Agile, but the basics (get something working quickly, get lots of feedback from users, etc.) just seem like no-brainers for most projects. Instead what we got was slapping the “agile” label on because we worked in two week sprints and used story points on JIRA :(

        1. 3

          Thanks! This will save me a lot of trouble in the future!

          1. 2

            Although I mostly like it, I though it was funny when they replaced Agile buzzword with a slogan about DevSecOps or something. From one hype train to another?

            1. 1

              If the only people who are on the hype train are early adopters who know what they’re doing, then it can almost work as a strategy.

              1. 1

                That’s true for a lot of things. I dont think we should call it a hype train in those cases, though. More like an early adopter advantage.

            2. 1

              Awesome questions to ask a potential employer during a job interview!