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

Re: New Article: Planning the Project

Expand Messages
  • Matt
    ... People over process simply means that people control the processes not the other way around. Process isn t bad... process that is immutable is bad. ...
    Message 1 of 207 , Dec 4 10:51 AM
    • 0 Attachment
      --- In extremeprogramming@yahoogroups.com, "Simon Jones" <simon@...>
      > I don't think I'm comfortable with the word 'process' in this
      > context.. people over process and all that) then they can raise it
      > there and then and, if collectively it seems reasonable, I can see no
      > great harm in trying it out, there and then (in fact even if everyone
      > doesn't I still think its probably worth a try). If its a 'process'
      > (yuk) change of such large proportions that this isn't possible then
      > yes, it deserves time and attention, discussion and so forth outside
      > of the day to day activities. As I already said in my previous
      > response. This is not the same as a retrospective however.

      People over process simply means that people control the processes not
      the other way around. Process isn't bad... process that is immutable is

      > I'm all for scientific method. If we worked in anything faintly
      > approaching a science I'd agree even more... :)

      > I'd very much doubt whether any signficant portion of XP has been
      > subjected to such scientific validation. Do we really go about making
      > bold assertions and then rigorously attempting to disprove them?
      > (rhetorical).
      > If my team wanted to try a 'process' change I'd let them run with it
      > not ask them to contruct some kind of pseudo-scientific proof..
      > simply don't have the bandwidth, at least not to do it to any degree
      > that approaches 'science'... I'll leave that for the academics who do.
      > But don't misunderstand me. I do agree with the principle you're
      > getting at, but the argument about scientific verification seems
      > somewhat tangential to the discussion about the value of
      > retrospectives.
      > And besides... whats wrong with 'try it, /measure it/ and see?'

      Plan, Do, Check, Act... Hypothesize, Experiment, Analyze, Report.
      Deming wasn't a scientist by trade yet he came up with something
      remarkably similar to "scientific method", perhaps his graduate degrees
      in physics helped with that.

      I am not suggesting formal studies and reports and power-points and
      peer-reviewed journals. I am suggesting that you know what you expect
      from a given change, know why you think the change will help, check to
      make sure the change did what you thought it would and then make the
      change "permanent" (until the next change of course!)

      It seems to me that a retrospective would accomplish the above better
      than just "try this and see if it works" but then... I haven't tried
      that to see if it works! I suspect that you haven't read Mary
      Poppendiecks thoughts on the subject of the scientific method given your
      intepretation of my comments. I should have been more clear with what I
      meant by that.

    • Jim Shore
      While these sorts of tools are useful for distributed teams and can encourage agile adoption, I think many do more harm than good. They enable bad behaviors
      Message 207 of 207 , Dec 7 5:15 AM
      • 0 Attachment
        While these sorts of tools are useful for distributed teams and can
        encourage agile adoption, I think many do more harm than good. They
        enable bad behaviors (just as CI servers enable 4-hour build times).
        They often act as a substitute for face-to-face communication,
        working directly together, and big visible charts. Exactly the
        opposite of what successful agile teams need.

        I've yet to see one that I thought was helpful for a collocated
        team. I've seen plenty of teams that could have been collocated use
        tools like this to avoid rich collaboration, without even realizing it.

        I haven't looked at Mingle yet.


        On Dec 6, 2007, at 4:15 PM, Four Hewes, Caspian Design wrote:

        > Well, what do folks think of the _idea_ of an "Application Lifecycle
        > Management (ALM) solution" such as ResultSpace?
        > Can a many-user software tool support and encourage (maybe even
        > enforce) a group's agile methods? Is the tool overhead worth the
        > gains?
        > Would "People over Tools" dictate that these sorts of automating
        > approaches are wrong-headed?
        > Anyone have experience with ThoughtWorks' Mingle?
        > I am looking at a couple upcoming web app dev projects that I'd like
        > to structure with at least some agile/XP practices. I'm wondering if
        > these sorts of tools may help support the adoption of agile/XP
        > discplines for newcomers. Could be just a crutch though...
        > I'd appreciate insights, comments, etc.
        > Thanks,
        > At 2:34 PM -0500 12/6/07, Edmund Schweppe wrote:
        > Overall, my guess is that this ResultSpace thing isn't what XP folks
        > would consider "agile". It sounds more like a lot of branding being
        > applied to some Sapient internal apps that they want to try and make
        > some money on.
        > 12/6/07, Four wrote:
        > http://www.ResultSpace.com/
        > Sapient's "Renowned Agile Development Methodology"... Anyone know
        > more about their expertise, claims and this new tool? Is it like
        > ThoughtWorks' Migle?
        > --
        > --
        > Four Hewes, Principal
        > Caspian Design | A Hybrid Consultancy
        > four@...
        > To Post a message, send it to: extremeprogramming@...
        > To Unsubscribe, send a blank message to: extremeprogramming-
        > unsubscribe@...
        > ad-free courtesy of objectmentor.com
        > Yahoo! Groups Links

        James Shore, Titanium I.T. LLC
        co-author of The Art of Agile Development--now available!

        voice: 503-267-5490
        email: jshore@...
        blog: http://www.jamesshore.com

        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.