1. 7
  1.  

  2. 6

    As I wrote a few years ago, now Agile Scrum is the new RUP.

    In a field that is still at stone age (computer science), RUP and Agile (and Scrum, and Lean and… what next?) turned from rational approach to a well defined set problems to marketing segments for consultants and consultancy firms.

    They are tools to sell books, training courses and workshops.

    1. 2

      Eh. I don’t know. I’m not sure why (Agile/Scrum/Lean/etc) can’t be both a rational approach as well as a niche for consultants to market themselves in.

    2. 4

      Retrospective Meeting - This happens when something goes wrong.

      I think that this way of looking at this is really detrimental. I’ve found that it’s often useful to have a debrief meeting to talk about what things went well, what things didn’t go well, and how to improve. If they’re part of the standard process rather than something that happens when “something goes wrong” then they’re much more useful, IMO.

      1. 2

        It’s kind of depressing how many Big Dumb Corp’s I’ve been in that have claimed follow Agile, but only use daily standups, the rest is water fall as usually. Some Big Dumb’s do some of the other ceremonies, like sprint planning and back log grooming, but not many.

        When I find myself leading a team in one of these situations, I use just enough agile to CYA ie cover your ass. Sure I’ll make best effort, but I’m always ready to use the scrum board (it’s always jira agile) to answer the question: “Why didn’t the team get anything done this sprint?” Well, it’s because these items were added during the sprint, and the team wasn’t working on the items that were agreed upon to be a priority, because you (product owners and management) are incapable of prioritizing, scheduling, or managing.

        Some times they get the message, usually they don’t, and things muddle along. I’ve experience this 3 times, currently in the fourth.

        1. 2

          I’m not a huge fan of the title of this article, especially since the article’s answer to the question is “neither.” “Pitfalls of teams struggling with Agile” would be more accurate.

          For me, value of Agile/Scrum/whatever has been identifying that the process of doing work is something that should be continuously improved, just like the work product itself (usually code). Shorter feedback loops for both process and product are often useful, as long as they are applied to appropriate problems. Beyond that, adding excessive formality can harm productivity, but that is not a phenomenon specific to any styles of iterative development.

          There is just as much cargo cutting in the process world as there is in the code world. The authors points about TDD vs TDC, while feeling a bit pedantic, do contain a useful adage: you should understand tools and processes before adopting them.

          Collaboratively writing anything, especially software, is hard. What works for one team depends a lot on who is on that team. Expecting any single process to work for all teams is therefore unrealistic, and that is before getting into differences of industry, company size, project specifics, etc.

          As for the whole consultancy issue, it is a good idea to be suspicious of anyone selling you any form of dogma-driven-development. Should you pay for your team to attend Agile training? Probably not. But having everyone read some articles or a book and then incorporating some of the ideas into your process? Not a bad way to go.

          1. 1

            Well, fortunately no lives depends on our code.
            Would you like to listen this in your operating room:

            Surgeon: “Spackmann Cannula, fast!”
            Assistant: “Here”
            Surgeon: “What’s this?! I want a Spackmann Cannula! NOW!”
            Assistant: “That IS a Cannula! Isn’t it? Don’t be pedantic!”

            The fact that people who don’t use a precise technical language call themselves programmers, is one of the reason why we are still at stone age in our field.

            1. 1

              I’m all for the use of correct technical language, but I do think there is big difference between the names for specific physical medical tools and for programming processes, which are highly variable and depend so much on the people, project, tools, etc. involved. You’re right, no lives depend on my code directly, but this is also the case for much of the code written today.

              I’ve seen and been involved in my share of debates about what the true definition of a programing process is, and they have a tendency to be unproductive due to a focus on definitions instead of effects. If you give all of your attention to what something is, it is easy to miss what it does, which is often more important.

              I’d rather see a team implementing those ideas that are beneficial from a practice and ignoring the rest. For example, a discussion about if components of a project would benefit from upfront or iterative design is useful. Arguing about which option is allowed by a dogmatic programming process is not.

          2. 2

            I’ve worked in both Agile (SCRUM) and “whatever you call what we did before” environments, and to me Agile is definitely an improvement. I don’t think it’s the best of all possible solutions to the problem of developing software, but it’s pretty good at what it does if it’s used properly. One thing that I find it doesn’t do well is give the team enough of a voice into what the product needs. I guess technically the team is one of the stakeholders and so they can negotiate with the PO to get their needs put into the backlog, but… sometimes you want to be able to fix something w/out having to create a backlog item, and then talk to the PO about it, and then groom it, and then get it put into a sprint to be worked on. I’d like to think that at some point a team reaches a state of maturity where the PO is just communicating business goals to the team, and shielding the team from interruption while the team figures out what they need to do to meet the business goals, and then does it.