1. 25
  1.  

  2. 8

    Following any proscriptive approach (agile or otherwise) doesn’t work in my experience. People seem to be completely seduced by the idea that there is a magic methodology that works for all development teams. Appopriating models from other industries (Lean Manufacturing, Kaizen) and selling them as cookie cutter solutions..

    It’s a shame the agile manifesto ever became more than an enlightened discussion-starter. Maybe that happens when you set down a manifesto!

    Organizing the work of a typical development team (of 3-8 people) is not that hard when you don’t fixate on process between deliverables - i.e. trusting competent, motivated people to do what they’re good at.

    The “methodology” should not go beyond:

    1. Define what you need to do - one sentence per feature/capability
    2. Roughly size the tasks and choose a deadline
    3. Prioritize
    4. Do it :)
    5. Assess
    6. Go to step 1

    Sorry if this comes across as arrogant and dismissive, not intended as such. I just think a large portion of the software engineering industry is deluded.

    1. 5

      competent, motivated people

      Hints at your unstated step 0:

      1. Find competent motivated people who focus on solving business problems, build pragmatic maintainable systems, and choose technology based on merit, not resume bingo.
      1. 2

        What of a complex product, where domain knowledge is outside of the development team? Consider the outcome of your approach for say a Payroll System?

        Let’s say I want you to write a simple CLI based double-entry general ledger program. I suggest you could not do either steps one or two of your methodology with success.

        1. 2

          I’m not saying to write one sentence to define all that you need to do to build a general ledger program. Defining what you need to do could be a series of conversations with stakeholders, team brainstorms, requirements gathering - getting an shared understanding of the problem in whatever way works best for the project team. My point is that you don’t need to proscribe how that task definition is reached (appreciate the irony of me proscribing it :) You don’t need a mental model to follow for every project.

          Regarding estimation, this falls out of defining the problem as a series of discrete capabilities of the system. In your example, an accountant could help define what the acceptance criteria for the simplest possible application that could be considered a general ledger. From that a team that understands the domain should be able to break it down to features or capabilities that can be easily described. That may result in more than 1 iterations worth of work, but some experienced heads should be able to give estimates within 20% accuracy for each capability.

          Of course, I’m also not implying that everything is simple. I threw out that 1-6 cycle only as a argument against process-heavy methodologies. In a complex system, that cycle could be very short and only cover a fraction of the final product.

          Hell, much of what I’m rabbiting on about is agile stuff, my only point is that I think agile is only useful as a starting point for a team to find their optimal way of working together. As far as success goes, I’d say it’s far more important to have the right people and attitudes within a team than following the 10 Commandments of Agile. A human project team isn’t a machine to be oiled.

      2. 4

        I was interested in what he was saying just up until he said

        Some may even be lucky enough to find themselves doing Extreme Programming, also known as ‘The Scrum That Actually Works’.

        My experience with XP was that it was extremely heavyweight and did not work well at all. It created the greatest developer dissatisfaction of any of the versions of Agile I’ve encountered.

        1. 5

          Couldn’t disagree more – the most successful team I was on was heavily into XP. When people say it’s heavyweight, they’re usually talking about pair programming. I’m not sure what people have against it; I’ve found it’s a great way to train junior developers, awesome for tricky problems, and generally a great way to avoid the problem of, “Oh this PR looks fine but redo it because you misunderstood the requirements.”

            1. 2

              I don’t want to discount your experience, but it sounds like the issues you’ve had with pair programming are more with the odd choices your employer imposed.

              Both people have specialized editor configs? Sure, switch off computers or whatever too; no need to work in an unfamiliar environment.

              And if one person is significantly less experienced than the other, that person should be at the keyboard more often than not – watching the master at work will largely be useless.

          1. 3

            Why I like XP over anything else is the focus on development practices rather than business practices. Pairing, TDD, CI, <10 minute builds, WIP, whole team estimation, etc are all used to produce a better product, faster.

            The weekly retrospective offers a way to adjust practices that aren’t working and bolster those that are.

            1. 2

              Agreed 100%. It turned my head a bit when he thought Agile was too prescriptive, but then was considering an even more prescriptive methodology.

              1. 1

                What was your experience with XP? Also, scrum is heavyweight as well in my experience and doesn’t work excellently in an actually agile environment like a startup. Feels like it could work in corp. though.

              2. 4

                People should stop ranting about agile when they are in fact complaining about scrum. I’ve used scrum and kanban and there’s a big difference in workflow. I feel less stressed by the later and I feel it’s more realistic.

                1. 9

                  The article is significant in that it comes from one of the original signatories of the Manifesto for Agile Software Development. I had a huge knee-jerk reaction when I read the title of the article, “Who the hell are you to tell me that I should abandon Agile?” and yeah it turns out the guy is actually pretty important in the story of “Agile”. Much more than I am, anyway.

                  It’s also not just a rant. I forced myself to read the article before I commented, just to be sure I didn’t just throw random anger at the internet. Author provides tentative solutions to get out of the bad situation of being forced to do “Certified-Agile-as-a-product”, as sold by, well, businesses. I kind of begrudgingly agree with everything in the article, minus everything preachy about XP, of which I have no real-world experience.