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

RE: Engineering Practices in Scrum - from RE: Type N Scrum

Expand Messages
  • John Streiff
    Pascal, I think you have hit on a key point, and one to it will be interesting to see the responses. I would concur that any practice needs form underneath,
    Message 1 of 1 , Mar 28, 2006

      I think you have hit on a key point, and one to it will be interesting to see the responses.

      I would concur that any practice needs form underneath, whether it be engineering or otherwise. At the heart of it, without form there is no function. There is no repeatability. Repeatability for example becomes not a certainty but as Doug Henning said so many years ago... "..an ILLUSION...."

      This is a dynamic that has been bothering for some time about agile methods.
      I do believe they work - in fact, I sold technology 20 years ago that promoted concepts remarkably familiar to what I now see in the agile stuff today, including Scrum. But I wonder why they work as they do.

      I revel in the notion that others, here, are potentially equally interested in the same problem. Why does this stuff work at all? There is certainly the human factor to consider - and that is, to me, what is most intriguing about agile methods, whether Scrum, XP or call it what it you will. The agile methodology is really about celebrating what a team can accomplish and empowering them to do so.

      But a team without direction is a team in chaos. Likewise, a methodology without form is a series of loosely-related concepts as opposed to a methodology. There are reasons that the structured stuff worked for so long, although most folks doing structured design (and you know who you are) were in many cases not able to describe why the methodologies actually worked as they did, and that was okay. What they _knew_, and knew very well thank you very much, was the practical application of the methodology of the time.

      The practitioners did not fail, the limits of the methodology did. The only issue was that many did not realize when to jump off the bandwagon since they had no critical metrics by which to measure success. What they did have (and I include myself here, dating myself as well) was artifact indicators: projects running over-budget, unsatisfied customers, products coming out square when they were designed to be round, and the like. Change was needed.

      As should by now be apparent, I am a fan of practices and process. I'm also a fan of reductionism. Ergo, I'm a fan of the agile approach; a marriage of the two, done well. My only concern for practitioners is that Scrum, XP and other agile methods are no safer from running off the methodological rails than earlier methodologies. What these current methodologies do offer however, is the remarkable opportunity to get it wrong, and even do so again and it's still okay. That's revolutionary, worth preserving and worth understanding!

      But in all of that, there needs to be a serious study of _why_ these practices work and _why_ they don't work on occasion. This group is making a great effort at doing precisely that. I believe structured thinking would be in order. I suggest that we bring even more of that type of expertise and discipline to this forum as we all attempt to understand agile methods.

      John Streiff, Technical Product Manager
      Secure Software, Inc


      Date: Tue, 28 Mar 2006 09:20:28 -0500
      From: "Pascal Roy" <pascal_roy_1967@...>
      Subject: Engineering Practices in Scrum - from RE: Type N Scrum

      Question to the community: Do you feel that using Scrum without any of the
      agile engineering practices can yield good results?

      I think the reason Scrum is more popular than XP (I have no knowledge that
      this is actually true, but it does feel like it) is that it involves much
      less changes for the entire development organization. This is thus probably
      much easier to implement Scrum than say, XP. In fact, because the core of
      Scrum is mostly about agile management as I understand it, it can be put in
      place from the top down (which typically doesn't work really well in XP).
      After all, as long as the developers aren't impacted too much in their
      technical practices, they should not care that much. Planning in most
      companies is not their responsibility anyway (they often don't even do their
      own estimates). In my personal experience (YMMV), resistance in XP is
      typically not related to the planning practices which developers seem to
      like, it's when we touch their day to day engineering activities (TDD,
      refactoring, simple design, pair programming...). That's where the proverbial
      shit hits the fence if you permit the language...

      The question I raise (and I shamelessly timed this message with one of
      Ron's that more or less discusses this issue) is whether or not you can do
      iterative development effectively without some of the technical engineering
      practices. For exemple, at the end of the sprint, you might be able to say
      the tasks of the sprint are done by having the customer run the acceptance
      tests manually. But how, would you know you hadn't broken the rest of the
      software which would render your burn down chart completely useless. If 20
      new features work, but 20 others now fail, you're not really going forward.
      Maybe it's a just a little thing, but it could be a costly design error
      requiring lots of time to fix. How would you know where you are at that
      moment?. I would also bet velocity would become completely useless in an
      environment without unit tests that would act as a solid base on which
      developers could count when they invariably need to refactor the design
      (iterative development remember). From experience, without those tests, the
      farther we are down the line, the more complex the software, the more
      chances we screw something without knowing, the longer it takes to add any
      new functionality, the lower the velocity. Planning with declining velocity
      isn't too interesting to most people. Well, technically you could calculate
      the rate of decline and plan with that. Depressing isn't? I'm not saying you
      can't absolutely do Scrum without the engineering practices, but I just
      don't see that the iterative planning nature of Scrum can actually work
      efficiently without having the right data from the team. That meaningful
      data comes from the engineering practices.

      I'm not here to advocate XP over Scrum. In fact, I don't care that much
      (anymore) how to call whatever we do as long as it works. Frankly, I just
      don't think you can do iterative effectively without a minimum of
      engineering practices... If this is true, than teaching Scrum without the
      backing of the engineering practices it needs to get meaningful feedback is
      doing a disservice to the community.

      I don't pretend I have the answer here. I'm just really curious what the
      community thinks of this.

      Pascal Roy, ing./P.Eng., PMP

      Vice-président/Vice President

      Elapse Technologies Inc.

      [url] http://www.elapsetech.com

      [email] pascal.roy@...

      [cell] 514-862-6836
    Your message has been successfully submitted and would be delivered to recipients shortly.