1. 21
  1.  

  2. 1

    This article was surprising great, for such a weak title!

    1. 3

      I guess it’s good that they don’t really present a follow-up methodology, otherwise that would run a real risk of being adopted by a cottage industry of gurus and consultants who mess it up again by making it a process with books, courses, Master Of Crazily Cute Acronym roles, and (expensive) certifications.

      1. 3

        otherwise that would run a real risk of being adopted by a cottage industry of gurus and consultants who mess it up again

        They didn’t mess it up. It’s just the best way to extract money from money-rich ‘enterprise’ is to sell them recipes for ‘the right way to do software’. The right way has always been to use your brain, know the material and adapt to the situation. Since managers do not know the material, only sometimes have brain and don’t like adapting because following the book means so liability, they need somebody to sell them a book.

        1. 4

          The attached article is much better and more subtle than this summary. The situation in the 90s had software engineering orgs positioned as a cost center. Methodologies like Agile designed to reduce cost and better account for customer needs were a major benefit; they’re still important in consulting or agency models. In contrast, many of today’s tech companies are software engineering orgs so the same approach to delivery speed and reliability does not apply.