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

Re: New Article: Planning the Project

Expand Messages
  • Simon Jones
    ... prefer ... to ... formalized I do understand the difference and I don t think I am confusing them at all. If someone feels there s an opportunity for
    Message 1 of 207 , Dec 4, 2007
    • 0 Attachment
      --- In extremeprogramming@yahoogroups.com, "Matt" <maswaffer@...>
      > --- In extremeprogramming@yahoogroups.com, "Simon Jones" <simon@>
      > wrote:
      > > I just don't like organised retro's. I'm not stopping the team
      > > holding them. If they really want to I'll attend... I'd just
      > > an environment where improvements are happening continuously.
      > >
      > > If someone feels we should halt the 'production line' I want them
      > > pull the chain there and then.
      > I think you are confusing "stop the line" for product defects with
      > "kaizen improvements" for process improvement. Kaizen IS a

      I do understand the difference and I don't think I am confusing them
      at all. If someone feels there's an opportunity for improvement (and
      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.

      > process (although not in the traditional sense of formal) for
      > implementing process improvements. That said.. if retrospectives
      > the *only* kaizen-like activities in your organization then that's
      > indicative of a bigger problem.

      We agree on that.

      > IMO retrospectives give an opportunity to present ideas and
      > them in a team environment. Some of the changes that *should* come
      > of a retrospective are ones that shouldn't just be thrown together.

      'Just thrown together '... thats a bit dismissive. If a team of
      educated, experienced professional people think something is worth
      trying I would dispute that its just been 'thrown together'. In fact
      I will, in our pseudo-scientific profession, almost always favour
      the /practioners/ viewpoint.

      I seem to remember Ron saying that on the C3 team if they felt
      something would work they would 'just try it'.

      > Mary Poppendieck provided some insight on this when she mentioned
      > "process improvement" doesn't mean "try this and see if it works" it
      > means using the scientific method to determine whether a process
      > really is a process improvement.

      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?
      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

      And besides... whats wrong with 'try it, /measure it/ and see?'
      > Matt
    • 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, 2007
      • 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.