Loading ...
Sorry, an error occurred while loading the content.

158246Re: [XP] why do people say agile when they mean waterfall

Expand Messages
  • Phlip
    Nov 12, 2012
      On Sun, Nov 11, 2012 at 11:11 PM, Theresa Jayne Forster
      <theresajayne@...> wrote:

      > So, I just left my last company after only 1 and a half months in the job.

      Woah. That's certainly never (cough) happened to me. I'm going to
      write my latest experience up parallel to yours.

      > I was hired as a Senior Developer Agile C#/VB.NET

      Python + Django (which, by itself, is fall-off-a-log easy). Everyone
      knew better than to call the situation "Agile", but everyone had
      worked very hard - a little TOO hard - to tune and perfect a
      bullet-proof, ultra-high-volume build system. The result worked like


      ... including fun like a 10 minute test run for a very tiny project.

      > So, every day we would have a stand up, where the project manager would
      > hand out tasks and move stuff on the wall (the only person allowed to do and
      > only at the stand up) which would last 15 -30 minutes.

      Right. One point of XP is to provide checks and balances across team &
      individual abilities. And yet even the closest project to XP I ever
      worked screwed up the Planning Game.

      Managers just can't let go of the idea they must dispense orders to
      individual work units. And, of course, managers should inform the work
      units how long they expect each task to take.

      Those attitudes cause unbelievable friction, which some engineers
      handle better than others. Violating the Planning Game, like that,
      divorces Authority from Responsibility.

      > We had to follow a specific predefined way of doing things and create
      > copious documentation including Full technical specs for "iteration 4" that
      > included complete design specifications with full estimates which will be
      > used.

      Right; the burden of producing the specification grows greater than
      actually cutting code. But you are "not allowed" to cut code, because
      you don't have the specification yet. This is another example of
      "illusion of control", where managers think they are helping the code,
      but they are really steeping it in the products of their fears. And,
      of course, some people might be better at coding than e-paperwork.

      In my case, with a recent project, we had a different e-paperwork
      burden. Instead of pair programming, everyone submits code to a
      two-tier system. If everyone reviews the code changes in the first
      tier, it commits to its final home in the second tier.

      If someone dislikes the code in the first tier (or if they just feel
      chatty) they can add notes to it, which email automatically back to
      the author. This review system resembles pairing, except that A> too
      many cooks review the broth, and B> verbal communication is highest

      My specific problem was with a manager who insisted on turning the
      slightest misunderstanding into a cascade of redundant, divergent
      lecturing about everything under the sun. This lead to a very
      disturbing "thread mode" in the review system, and made focusing back
      on a winning code solution extremely hard. And, of course, any
      problems the review system caused were just taken as evidence it was
      working, and preventing wayward programming!

      I spent three months at that job writing about 3 features; I've
      written 3x the amount of code (with review, and unit tests, and
      steadily improving design) in about 3 weeks at my current job.

      > Iteration 4 was just what the company agreed to deliver by the end of the
      > year, and there was no discussion or input from the development team, The
      > only people who were at the meeting with the client was the BA/Project
      > Manager and it sounds like they just nodded their head and did what the
      > client wanted.

      The Planning Game - and everything else - are supposed to alleviate
      these dominance issues.

      > Is there anything that can be done to correctly "agile up" a company that
      > pretends to do agile in this manner?

      Like James Grenning said, hitting the silk is a perfectly reasonable
      strategy. Some teams are, indeed, trying. (Like my former colleagues
      certainly were!) And some teams cater to managers with special needs.

      Could you list any agile practices the team was doing, and how well
      they did them? Stuff like TDD, daily deployment, etc?

    • Show all 8 messages in this topic