1. 29
  1. 23

    I like dunking on Agile as much as the next guy, but this really doesn’t do it for me. It seems more oriented toward PMs and C-suits than programmers. Also it’s completely incoherent.

    Here’s a quiz for you. How does the first line of the Agile Manifesto begin? No peeking. Don’t know? That’s fine. It doesn’t matter. It says, “We are uncovering better ways of developing software….” … But the thing is, when people say that Agile pertains to the whole org, it’s revisionist history. It’s dishonest.

    Good thing we don’t just projects by just their first line! There’s also 12 principles and everything.

    Notice too it begins, “We are uncovering….” It does not say, “We have received from on high….” Don’t you think we’ve learned a thing or two since 2001?

    So if things can change, why can’t the scope of Agile change too? Maybe we uncovered that it can go beyond software!

    So find a good booklist. Follow some good blogs. Here’s a start: If you haven’t read Sense & Respond, Lean Enterprise, A Seat at the Table, and Everyone Is a Change Agent, I suggest you do so pronto. Your leaders too.

    This isn’t an argument, this is just throwing some names out there! Why should I care about these books? Why should I trust you? Why read these and not The New Economy, Out of the Crisis, Making Software, and Data and Reality? I can list books, too.

    Start reading posts by John Cutler, Melissa Perri, Bob Marshall, Allen Holub, Laura Klein, Erika Hall, Neil Killick, and branch out from there.

    Any posts in particular you’re gonna link? No? Guess I have to look myself. Just some random names I picked out:

    • Bob Marshall: Thinks software development is a solved problem.

    • Melissa Perri: Agile coach.

    • Neil Killick: Agile coach.

    • Allen Holub: Agile coach. Also part of the #NoEstimates crowd. (disclaimer I’ve clashed with him a bunch on Twitter)

    You give me four people for “beyond agile”, and three of them are heavy Agile fans.

    Fast Company says the average CEO reads 60 books a year. How many books do your leaders read? And what are they reading? (HBR articles, Gartner reports, and Maeve Binchy novels don’t count.) Because, let’s face it, if your leaders are still trying to grok Scrum, then you’re firmly stuck in the 80s and 90s.

    Seriously, can you link the study? And why should I care that CEOs read a whole lot?

    This needs to be said: Agile is and always has been a local optimization providing little gain to the system. All Agile did was put software development teams unfairly under a microscope.

    You just listed three people who apply Agile to whole organizations.

    Theory vs. practice, remember? We need to be pragmatic. Agile in practice is almost always AINO.

    Are you going to actually back this up? With studies, evidence, arguments, anecdotes, anything?

    There are more important things to learn about anyway, including (but not limited to) Lean UX, Lean Enterprise, Beyond Budgeting, Theory of Constraints, Throughput Accounting, Design Thinking, DevOps, Marshall’s Organizational Therapy, and so forth.

    Another wall of terms that really, really needs to actually link to resources. Like what’s DevOps doing there? It’s completely unrelated to everything else he’s saying.

    Why, you might ask, would Lean UX top the list? Outcomes, that’s why, a concept largely popularized by Lean UX.

    I’m pretty dang sure “Lean UX” did not, in fact, popularize the idea of “outcomes”.

    And while we’re at it, we’ve got to stop treating dev teams like they work in a factory. We’re not making plastic cutlery. We’re creating software. We need to stop acting like we’re running a pizza joint. The same rules do not apply.

    Five bucks says the author doesn’t know how to run a pizza joint. Ten says his stereotyped conception is extremely wrong.

    (I’m tired of this idea that SE and Agile are magical, wholly unique things. Like we can’t learn from other fields.)

    So…what’s the way out? It’s a smart focus on clear outcomes, not output, with roadmapped outcomes replacing planned milestones, with trusted product teams, not project teams, empowered to vet assumptions and discover the minimal path to value.

    How is any of this different from Agile? How is anything he said before different from Agile? Isn’t this all Agile all over again?

    1. 4

      Great summary. These mostly decontextualized “thoughtpieces” that are anecdotal blurbs of one person’s thinking are really tiring. I’m a big fan of “literature review”-type articles disguised as rants, and this article could’ve been a great example of that. However, not putting in the minimum amount of effort to actually give a few links to the literature after this much name-dropping is an insult to the reader. I blame Medium and the modern culture of “personal branding” where producing content is priority #1, and the quality of the content is priority [integer overflow].

      I’ve also made a habit of automatically dismissing anything said by any person who trivially belittles or dismisses other people’s hard work. It’s a sign of utter ignorance at best, and outright malice at worst.

      1. 4

        A rant about something can be useful. You’re doing a rant about something that is a rant about something, and that’s useful too.

        To me, the most important message in the article is that Agile was a single team delivering software movement that became a co-opted brand attempting to solve larger problems. I think that is important for people to know.

        Agile is both a triumph and a failure of marketing depending on how you look at it. Triumph because it became the dominant brand. Failure because a brand that means everything eventually means nothing of substance.

        1. 2

          it’s completely incoherent

          I’m afraid I have to agree with you here. I found it very hard to read, and gave up after a while. It’s a like the author did a teensy bit too much coke before writing the post.

        2. 3

          The funny thing about the waterfall model is that it describes the flow of data, not the flow of time. Like, don’t start writing code until its clear just what exactly a “user story” means. Chances are it’s logically equivalent to “as a user I want to shoot myself in the foot”.

          1. 1

            Interesting point of view. But I missed his experience applying the suggestion he gave with his team or organization.